The qemu.gles property will be ready after the SurfaceFlinger service is
initializing. Once the all required variable is set, it caches the
result for the future calls.
Bug: 37759781
Test: Test with imx6ul and imx7d pico boards.
Change-Id: Ib9f11a51ec8a0707be854f67fc8591149ab7fd49
Test: 1. AccessibilityNodeInfoTest#testMarshaling
2. Hack the check from the above test to run on each parcel, then turn on
TalkBack and ensure to system crashes and stack traces in logcat
3. A11y CTS: CtsAccessibilityServiceTestCases, CtsAccessibilityTestCases,
CtsUiAutomationTestCases
Bug: 33949542
Change-Id: I2cef9fcef9d6f84334614b0e81c6717484ef3436
Test: manual verification on Caviar (automated test will be added later)
Test: CtsAutoFillServiceTestCases pass
Bug: 38341498
Fixes: 38323841
Change-Id: I15cc792de87987cc19a229c2ab2dfc317877f7ec
In particular we are seeing this in the call sites from performTraversals
in monkey crashes. I don't have exact repro but it seems like a feasible
state to get in to...for example...WindowManagerGlobal#addView can trigger
removal of a dying view immediately without respect for the mIsInTraversal
flag when it calls doDie(). This means we can dispatch detached from window
setting mView == null while performing a traversal. There's some question
about why this doDie is even required but...seems a little nerve wrecking
to change at the moment and it seems best to just guard against null for now.
Test: Monkeys will test.
Bug: 37343098
Change-Id: I94f2569c1ef70819c083f2b2b34b59622e6c6260
We may be stopped, removed from the view hierarchy, and then only
attached again after the activity has been restarted, missing
our WindowStopped callback to set mWindowStopped=false. At this point
we are being added to a visible view, or in ViewRoot#performTraversals
so we can assume we are not stopped.
Test: Manual from bug.
Bug: 37682805
Change-Id: Idf8e061fb7f83b00992a274c7dd704f9e0fcff5f
When the autofill service returns a null FillResponse, the session is marked
"gone" because the service cannot autofill it. But there might be cases where
the view structure change and it's now autofillable, so need to allow users
to manually request autofill again in such cases.
Fixes: 38205945
Test: CtsAutoFillServiceTestCases pass
Test: LoginActivityTest.testAutofillManuallyAfterServiceReturnedNoDatasets()
Test: LoginActivityTest.testAutofillManuallyAndSaveAfterServiceReturnedNoDatasets()
Change-Id: I9b23c255e563dd0646bf266d31ddb10dcc4f7f6d
- Fixed PFLAG3_NOTIFY_AUTOFILL_ENTER_ON_LAYOUT value - it was overlapping with
PFLAG3_ASSIST_BLOCKED.
- Added missing permission on methods called by Shell command.
- Improved debugging.
Bug: 38173625
Test: android.autofillservice.cts.MultipleFragmentLoginTest#loginOnTwoFragments
Change-Id: Ie7880c97d38298e06134709c5c2e9e38fa1bacbb
No good will come from posting that a null View has
changed. Adding a null check so the failure will happen
when the bad call is made, rather than later when we
try to act on it in a handler.
Bug: 38122973
Test: Ran accessibility unit and cts tests.
Change-Id: I1e9aaf2a18180fcdfd0fbc0e5b716eb96446af33
packageManager.resolveActivity(intentWithUppercaseScheme, 0) returns null.
This means we don't find an activity to handle the browser intent.
Create a browser intent with url's scheme in lowercase instead.
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Fixes: 36504599
Change-Id: Idb0c5b73d54cf77d5d6fb4ee0af4478ec11e8b82
Logs:
- Smart selection occured
- TextView menu item activated on smart selection
- Smart selection reset
- Smart selection modified
Test: Manually checked logging happens as per go/tron-howto and verified
nothing is broken in related classes by running:
bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
bit FrameworksCoreTests:android.widget.TextViewActivityTest
Bug: 32572232
Change-Id: Ia9081d92ae9aea50d863455be770eecd0c73be1a
