Turns out there was another path in to the activity manager
to trigger a PendingIntent, which needs to be modified to
now also pass in the whitelist token of that pending intent.
Test: manual
Change-Id: I755ff87db1b782fa6974d404dcb490786053c5e0
We instead just want to leave it floating, and let
it's lifetime be controlled by the parent surface. This way it can
take part in animations. Normally the WindowManager handles this by
calling detachChildren but it seems sometimes stop arrives before
the window manager is even clued in. Rather than bringing ActivityManager
in to the detach children dance...this seemed more appropriate and very similar
to the behavior before SV->SurfaceControl port.
Bug: 37922210
Test: Manual from bug + Launch chrome a bunch
Change-Id: Iee4fb0078a6e8dfd4c7acdb0107f8edd3a995634
- Add check for keyguard drawn before stopping boot animation.
Otherwise blank screen can happen.
- Bind to keyguard service when sysui is launched to reduce waiting
time later.
- Increase keyguard timeout to 5 secs if it is not boot completed.
Otherwise (= normal screen on), keep the current 1 sec.
This timeout can still lead into blank screen so use bigger timeout
during boot-up to prevent such case.
bug: 37867510
Test: many reboots
Change-Id: Ibfdc42d295bb1d3f5b4ea316fe5aca9ab875e4be
Since we can't take a snapshot when screen is turned off, we need
to snapshot before we are turning the screen off. For this, we
- Add a callback from DisplayPowerController to give policy a
chance to do something before display will be turned off.
- Implement this callback by taking snapshots of all visible
tasks.
Test: Inspect logs/traces about screen off blocking to make sure
callback is working correctly.
Test: Insert artificial 500ms delay in onScreenTurningOff and make
sure we are unblocking screen off when turning on screen in the
meantime.
Test: Open Maps, go to recents, open maps again, scroll to another
location, toggle power button, make sure the old location isn't
shown during unlock.
Change-Id: I489f31358f838d418f894f996495946084f136a4
Fixes: 37107783
Previously, onDragEvent() tried to set the anchor even if
the text was not Spannable. Now we check to make sure it is
Spannable before trying to set the selection.
Test: cts-tradefed run cts-dev --module CtsTextTestCases
Change-Id: I835bf3d6024bf3c85e1d248458829eef496ad93d
Fixes: 37261326
In the case that a user has been removed but their jobs still exist on
disk, the JobSchedulerService will remove all jobs not associated with
current users on boot.
Exposed UserManagerService#getUserIds() via UserManagerInternal for
quick user id retrieval.
Fixes: 38261977
Test: manual
Change-Id: Id4b3c0a4142b4818fcd875eef18ea03f3c45ca40
Signed-off-by: Michael Wachenschwanz <mwachens@google.com>
...can't hide themselves
Propagate to notification manager the apps that are causing
the "running in background" notification to be shown.
Also hopefully this time fix the problem with the notification
being stuck. (We were mixing elapsed time in the state management
with uptime in the message scheduling.)
Test: manual
Change-Id: I9e38bff5fe69fa75b418e34c84d4e704ef70f460
Currently, the time for each partial wakelock was tracked. If one
wants the total time that a uid held partial wakelocks (over all of its
wakelocks), they could sum over all the uid's partial wakelock
totalTimes, but this would underestimate the value because totalTimes
are pooled amongst all uids. Alternatively, they could sum over all the
uid's partial wakelock totalDurations, but this would overestimate the
value because totalDurations are not pooled within the uid (so there
will be double-counting if two wakelocks are held simultaneously). This
cl adds a new timer that specifically tracks the actual total time that
the uid spent holding wakelocks, and also provides the ability to see
how much time the uid was in the background when doing so.
Bug: 38198272
Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java
Change-Id: I20ea3546338c44ffdf06859bc840d9059fb18321
- 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
Developer can specify android:fontFamily with three ways, pre-defined
font family name, e.g. "sans-serif", path to the font file in resource
directory, e.g. "res/fonts/Roboto-Regular.ttf", or path to the XML font
family file, e.g. "res/fonts/Roboto.xml".
Resources.getFont treats font files and XML files but pre-defined family
name is handled by TextView. Thus, we can early exit if the passed value
is not likely resource path.
This improves the inflation performance.
The score without this patch:
gfx-avg-frame-time-50: 6.9
gfx-avg-frame-time-90: 9.4
gfx-avg-frame-time-95: 10.4
gfx-avg-frame-time-99: 16.7
The score with this patch:
gfx-avg-frame-time-50: 7.0
gfx-avg-frame-time-90: 8.9
gfx-avg-frame-time-95: 9.7
gfx-avg-frame-time-99: 16.5
Measured on bullhead-userdebug.
The APCT perf test improves from
String FontFamily: 200,086 -> 132,561
File FontFamily : 199,256 -> 161,843
XML FontFamily : 203,681 -> 158,553
Measured on angler-userdebug.
Bug: 38232467
Test: UiBenchmark
Change-Id: Ia601ae7207ae8c60848c9efdbb9396267a57257c
The onRemoved() callback from fingerprint daemon provides a "remaining"
parameter which contains the number of fingerprint templates yet to be
removed in the current removal operation. This is especially useful when
a group is removed, as remaining == 0 indicates the end of the group
removal.
In this CL, we wire up FingerprintManager so that the "remaining"
parameter gets passed to RemovalCallback#onRemovalSucceeded(). This
would allow clients like Settings to make use of the information.
Bug: 37938345
Test: manual, both with and without work profile
Change-Id: Idf46ef42e1d178cd3dc267aaf4219f03e27be766
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
