- Events are obfuscated based on whether the app was instant or not at
the time each event was logged.
- UsageStats are obfuscated based on whether each app is instant or
not at the moment.
Bug 38202133
Test: Manual test using UsageStatsTest and instant apps
Change-Id: I3c74309196b88d010d317cb0dd6749bf4624e876
Test: manual verification on Caviar (automated test will be added later)
Test: CtsAutoFillServiceTestCases pass
Bug: 38341498
Fixes: 38323841
Change-Id: I15cc792de87987cc19a229c2ab2dfc317877f7ec
Rearrange how we generate the transition specs, which involves
creating a thumbnail on the mainthread (about 10ms on large
devices): First, we put launching the activity onto a handler
thread (with default priority), to free up the main thread. Then,
we immediately start generating the thumbnail such that when the
future calls us we have the generated spec already handy.
For that we need to be able to supply a specs future into
ActivityOptions, to avoid race conditions. Furthermore we need to
make sure not to call into WM while creating specs, to avoid WM
lock contention.
Test: App -> Recents -> Same app, inspect app transition logs
Test: Double tap recents for quick switching
Bug: 32668632
Change-Id: I6001e29145f8e56deb9c4ead46c53c87c9191436
Merged-In: Ic6ec65c2560f67cade3b5ddde9f79ee13e9ba32c
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I247bd1f095dd27335e671981f9e2d77e149af84f
Merged-In: I247bd1f095dd27335e671981f9e2d77e149af84f
Running cancel after toast is shown and adding some UI stress (or sleep
on UI thread) causes a crash from toast when trying to add the toast
window to the display. The toast must be triggered from app that is
above N MR1 (25).
The steps that crash the app are:
1. Show toast (Toast.makeText(...).show()), window token is created
2. Immediately cancel toast (Toast.cancel()), window token is removed
3. Stall UI thread (Thread.sleep, heavy task), both show and cancel
events are queued to UI thread from window manager
4. Crash trying to add toast but no window token exists
In Toast:handleShow(), the mNextView is required to add the toast to
display, if the mNextView is null before posting to window manager, then
when handleShow() runs later, it will ignore adding the toast to
display. The issue before is that mNextView is set to null after cancel
runs back from window manager in UI thread but the show post will always
happen first. Therefore set mNextView to null at the beginning of
cancel will ignore adding the toast to display and avoid the crash.
Bug: 37606432
Test: manual - write an app to Toast.show(), Toast.cancel(), then
Thread.sleep(), set app's sdk usage above 25 (N MR1) and show the
toast
Change-Id: I352e296c47b1b8776c78b6b0943b1dc809963026
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
Previously the icon was an event icon, but a clock icon is
more appropriate so we are switching to that instead.
Bug: 37351390
Test: Open time picker
Change-Id: I47e6caf3c341c10264168004628288fd00e4601a
In O, graphics drivers are loaded into a new restricted linker
namespace. Drivers built for previous versions of the OS may not work
under those restrictions, so require an updated driver package to
declare compatibility by setting targetSdkVersion >= O.
Bug: 34228255
Test: manually construct packages with and without
targetSdkVersion >= O, confirm driver is used/not-used as
expected.
Change-Id: I4518360433a6de5c6e1e792a6eedddf8c6bf4394
Bug 38277003
The back stack was being moved while executing operations and
then again when the postponed transaction was executed. It should
only be done once.
Test: Ie47e1f2f158325b9cfd6edb5c40c65d764ff9056
Support Lib Change: I3159c2345a7b77fa82f1c602f4639f51b5a47980
Change-Id: I3b7a032e7e8a9aec565157d42dcaa7232b256ae8
- Fix MenuItemImpl setShortcut bug caused when method signature was
changed after API review
- Remove outdated MenuItem coretests and move others to CTS
Bug: 38114634
Test: Run `cts-tradefed run cts-dev -m CtsViewTestCases -t
android.view.cts.MenuTest`
Change-Id: Iebb7e314cbb3f812fcfeb3f95797f1cf1bcfbae2
(cherry picked from commit d70d2e6efc)
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
- Now keep track of the time a job was enqueued, and order
the pending list by that.
- Added configuration constants for rescheduling: maximum
times to reschedule, minimum backoff times.
- Fixed printing of active jobs -- the method to get the current
JobStatus was old and didn't require the caller to hold a
lock, so made a copy, which didn't contain all the data we were
interested in. Now with our simple locking, we can just make
that require the caller hold a lock and return the real
JobStatus object.
- Include oom_adj and procstate when printing information about
processes being killed.
- Expanded documentation of BroadcastReceiver.goAsync().
Test: bit CtsJobSchedulerTestCases:*
Change-Id: I2e45f181e45be9836c74cbff1b844ffdf6e93019
