We now have a software feature for autofill which can be used
by partners to disable it on low-end devices or form factors
for which autofill doesn't make sense.
bug:35956220
Test: manual (requires a custom build)
Change-Id: I6c06462ed9ca3ae93331700dce38a8c08dfd0722
This reverts commit ba29dbc3b3.
The original commit causes apps such as phone and clock to not wake the
device.
Fixes: 37197491
Change-Id: I1b45cafbcbf12991d8e1e716e4d1751cd077c556
Also:
- Give the session an integer ID as the activityToken is not stable over
restarts of the activity
- Verify that session is only accessed by one UID
- stabilize AccessibilityViewIds over activity lifecycle at least for
the IDs we can do that. This required to split the ID namespace in
"per-app" and "per-activity" views. Only the later ones can be
restored.
- Do not end session when app is killed (as it can be restarted)
Bug: 35484143
Fixes: 36392498
Test: cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases --test=android.autofillservice.cts.SessionLifecycleTest
cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
Change-Id: I229acc1b3ce35fb57262da7d7466b5d4328b49d4
As far as I can tell this has always been broken. We've always had
intermittent reports of buffer-queue-abandoned as well (a recent bug
came with some reports from N). During onStop SurfaceView relies on
onWindowVisibilityChanged, to trigger a visibility change. At this
point SurfaceView will emit the SurfaceDestroyed callback in order to
stop the client from further use of the Surface. The contract we've
been using with ViewRootImpl is at any point following
Activity.performStop returning the WindowManager was free to destroy
the Surfaces. This is why in setWindowsStopped we destroy the hardware
resources for the ViewRoot. However we aren't dispatching anything to
the SurfaceView. The WindowManager will send an app visibility
notification, but that would go through the handler. This means by the
time we return from Stop, there is no guarantee that the
onWindowVisibilityChanged callbacks have been invoked at all. It
seemed most sensible to dispatch the visibility callbacks directly. We
also ensure that getHostVisibility will return false after this point,
so that performTraversals will not reverse our visibility request if
it occurs again prior to the window visibility notification from the
WindowManager. We also guard against emitting a second window
visibility changed callback in the traversals. I don't know at this
point what value the window visibility notification provides but I
don't feel excited about removing it in this CL at this point in
the development cycle.
Test: Put Chrome in PiP. Turn screen off. No Crash!
Bug: 36561071
Change-Id: Id1673561b2299d477b2761b3ac6afa14eabbf7fb
Fix a bug where a malformed Parceled representation
of an AccessibilityNodeInfo could be used to mess with
Bundles as they get reparceled.
Bug: 36491278
Test: Verified that POC no longer works, a11y cts still passes.
Change-Id: I10f24747e3ab87d77cd1deba56db4526e3aa5441
(cherry picked from commit 687bb44b43)
1) Switch AccessibilityButtonChooserActivity to non-exported
2) Update AccessibilityButtonChooserActivity's intent action to
be CTS-compliant
3) Switches to correct permission to validate a click of the
accessibility button originated from the status bar service
Bug: 36866328
Bug: 36976440
Test: Manual / Created app to validate launch protection
Change-Id: Ifcd5e8dbbe683dc99bb900a5870a9ba374fbd5d4
It happened when views provided an Accessibility node that had children.
Bug: 37078783
Fixes: 37009008
Test: LoginActivityTest#testAutoFillWhenViewHasChildAccessibilityNodes
Change-Id: Ie694094afe9129b933096a385eb867baf4550e7f
Also clear this overlay once the data changes. Some views call
notifyValueUpdated even if the value did not change. Hence remeber the
data that was autofilled and check if the data really changed.
Make the autofilledDrawable publicly accessible so that virtual views
can use the same UI.
As the activity is not aware that the views were autofilled the state
has to be explicitly persisted over activity lifecycle events as part
of the view. The lifecyle does not work yet as the AutofillIds are not
stable over activity lifecycle events.
Fixes: 34946006
Test: Autofilled and changed all supported views.
cts-tradefed run cts-dev -m CtsUiRenderingTestCases
Change-Id: I58b105bb221f1b6466dd136dfe5062d3babb5aa8
Moving tests for accessibility manager into the a11y
directory and getting them to use some of the newer
test infrastructure. Minor tweaks to
AccessibilityManager to make it testable.
Deleting the AccessibilityManagerService tests entirely.
This class is difficult to unit test with the current
infrastructure, but is covered in CTS tests to a large
degree. I wasn't able to get these working quickly, and
they rely on timeouts that make them run much slower than
the other tests. They also throw exceptions when their
mock accessibility services receive accessibility events,
which causes the system to blacklist those services, causing
the tests to fail differently until the system is reset.
I think it's better to focus on writing new, more robust
tests than on rewriting these tests to pass.
Bug: 36614219
Test: A11y unit tests now work.
Change-Id: I8effe44f22110d55ebb700dc46f59b7e7a1aa946
(cherry picked from commit 9213d23178)
We need PRIVATE_FLAG_NO_MOVE_ANIMATION to get consistent
results from client initiated window movement in CTS.
Bug: 36865695
Test: Annotations only.
Change-Id: I7850ce3920ba1e89c7759bf9bc25f25731f568a7
In order to clear the measure cache, we need to requestLayout
when updating the child layout params. To see why, consider the case of
a Frame or Linear layout which will measure different heights
depending on the (top/left/right/bottom)Margin parameters of it's
childrens layout params. Now imagine the following sequence of events:
1. We request a layout on the FrameLayout
2. We measure the FrameLayout and place a value in the cache.
3. Now we update the margin parameters on one of the frame layouts
children. Because the parent already has a layout requested
we don't call parent.requestLayout (see View.java#requestLayout),
and thus the parent measure cache isn't cleared.
4. Now we measure the frame layout again and we incorrectly
used the cached value.
Calling to requestLayout when the child layout params
change clears the cache properly. If the child didn't
call request layout from it's own relayout, it must mean that
a layout was already pending (step 1 in the sequence),
and so no more work should be triggered besides clearing the cache.
Bug: 33095565
Bug: 33308065
Bug: 34388764
Test: Manual case in bugs.
Change-Id: I9148f32530588e4dc859297f9658f506b38e72f0
There are two separate overrides for display metrics in DisplayManager
and WindowManager:
- In DM - LogicalDisplay#mOverrideDisplayInfo, in most cases not null.
- In WM - DisplayContent#mBaseDisplayWidth/Height/Density, different
from #mInitialDisplayWidth/Height/Density values when some metrics are
forced.
When display was resized its windows weren't updated because of
two problems: old LogicaDisplay#mOverrideDisplayInfo was preventing
WM from detecting the change and override (base) display metrics were
never updated by resize.
When display size changes:
- Before this CL:
DM receives DISPLAY_CHANGED event, it updates internal values and
WM is notified about them with a message. In most cases there is an
override obtained from WM and WM doesn't get new values from
LogicalDisplay#getDisplayInfoLocked().
- With this CL:
WM will requests real updated values from DM without any overrides
and will decide whether to apply them or not: if there is no override
in WM - it will apply values from WM, otherwise it will keep the
override. Also it will always update initial display metrics if there
is a real change detected.
Bug: 35258051
Bug: 34164473
Bug: 36518752
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testDisplayResize
Test: #testForceDisplayMetrics
Change-Id: I2495c27797f11f9aaee4ea06648a8ccd29ac5b62
With this CL, an @hide method InputMethodManager#showSoftInputUnchecked
is marked to be deprecated and starts showing a warning message in logcat
when it gets called to tell application developers who are still using
old implementation fo android.support.v7.widget.SearchView that they
need to switch to support library ver. 26.0 or later version.
Other than that there is no behavior change in this CL.
Test: Manually verified as follows:
1. Flash an OS image
2. Complete the setup wizard (if any).
3. In N MR-1 AOSP repository
frameworks/support/gradlew -p frameworks/support support-v7-demos:assemble
4. adb install out/host/gradle/frameworks/support/support-v7-demos/build/outputs/apk/support-v7-demos-debug.apk
5. adb logcat -s InputMethodManager
6. adb shell am start -n com.example.android.supportv7/.Support7Demos
7. Tap AppCompat -> Action Bar -> Action Bar Usage
8. Tap the magnifier icon.
9. Make sure that the software keyboard shows up.
10. Make sure that in logcat a warning that showSoftInputUnchecked
is going to be removed is shown.
Fixes: 36015425
Change-Id: If01316a0c2a210f9ea03b53700d0ef651955ba9c
Test: Run window animation, make sure it's smooth
Test: Take systrace, make sure it runs at vsync-tick
Test: Move divider, make sure it's still smooth
Change-Id: I1600618e074be811134fe4ccb1dfbd5034820c71
Fixes: 36583867
The system previously overrode the display size for a specific scope
(task/activity/etc.) by setting the associated Configuration's
screenWidthDp/screenHeightDp. This leads to two issues. First, the
conversion of screen size from pixels to display independent pixels
and then upconverting later on leads to rounding errors. Secondly,
the screenWidthDp and screenHeightDp values account for insets, such
as the status bar. These however are not reflected in the display
size when returned from Display#getMetrics/getSize.
This changelist addresses the issue by adding a Rect value to
Configuration which stores the app display bounds. This is always set
at the display level and overridden as appropriate. As the proper
app insets are accounted for at the root configuration, all overrides
(outside of specific exceptions) are the result of the intersection
between the requested bound and the parent bound.
Change-Id: I2c4fcd0bee92af12aabbca258de05b4ec061d0e1
Fixes: 34338931
Bug: 36812336
Bug: 36676979
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsAppTestCases android.app.cts.AspectRatioTests
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test CtsServicesHostTestCases android.server.cts.ActivityManagerDisplayTests
Test: bit FrameworksServicesTests:com.android.server.wm.AppBoundsTests
Removes @removed methods.
See: I24e86272cf58bf6864505bee3b06978c1c0d46e5
Test: Checked that API is removed.
Change-Id: I93e7f64740671b5ff856f8b38eddc04417f6486e
