Bug: 144166111
Test: manual, ./external/chromium-trace/systrace.py camera -o
/tmp/mytrace.html (after changing tracing tag to "camera" since it isn't
used for anything else in automotive)
Change-Id: I082888daee17c671ba9ab5c8cf1ae486e683ab16
am: fead6f705d -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 09843a687b is in history
Change-Id: I70bd239e00bc10f394c88c49fb266c9ce23d03a6
am: 13be3108cb -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 3b8c4743f6 is in history
Change-Id: I6d39b885aff0624f983e7290b83a88eeb6c92518
am: 663d3d7991 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 3b8c4743f6 is in history
Change-Id: I74620297e68c2bfd6664ed903f912e5e25d575be
am: 3692a6d231 -s ours
am skip reason: change_id I0680034ed9315aa2c05282524d48faaed066ebd0 with SHA1 3b8c4743f6 is in history
Change-Id: I575817ba777d7212391d75a6163c28e75c7ccbc4
It's possible for a service to do a start/stop foreground and cause a
couple of things to happen:
NotificationManagerService will enqueue a EnqueueNotificationRunnable,
post a PostNotificationRunnable (for the startForeground), and then also
enqueue a CancelNotificationRunnable. There is some racy behavior here
in that the cancel runnable can get triggered in between enqueue and
post runnables. If the cancel happens first, then
NotificationListenerServices will never get the message.
This behavior is technically allowed, however for foreground services we
want to ensure that there is a minmum amount of time that notification
listeners are aware of the foreground service so that (for instance) the
FGS notification can be shown.
This CL does two things to mitigate this problem:
1. Introduce checking in the CancelNotificationRunnable such that it
will not cancel until after PostNotificationRunnable has finished
executing.
2. Introduce a NotificationLifetimeExtender method that will allow a
lifetime extender to manage the lifetime of a notification that has been
enqueued but not inflated yet.
Bug: 119041698
Test: atest NotificationManagerServiceTest
Test: atest ForegroundServiceLifetimeExtenderTest
Change-Id: I0680034ed9315aa2c05282524d48faaed066ebd0
Merged-In: I0680034ed9315aa2c05282524d48faaed066ebd0
- Notification posting is done as calling app
- make some only callable by shell
Test: atest
Test: sample app; make sure posted notification is from app itself
Test: sample app; make sure some commands fail
Test: make sure all modified commands still work from shell
Fixes: 143339775
Change-Id: I50ee768e792266ad2091f1913168e89d5d1463ed
(cherry picked from commit 1c943a2670)
When a User is pre-created with that flag, its CE & DE keys are not persisted on storage. Hence,
when that pre-creatd user is converted to full-user, the expected keys don't exist and the user
doesn't boot properly.
This change fix the issue by making the pre-created user non-ephemeral, and changing it to
ephemeral when it's converted to a "real" user.
Test: manual verification on Automotive by creating a new user than deleting it using the UI -
that creates and switches to a new guest user (which was pre-created); without this change,
that user would be hanging with a "Android is starting..." message
Bug: 143092698
Fixes: 143553590
Change-Id: If595b29356b5b50c812f2888cda6e636f18a0d4b
A progress dialog is shown and quickly disappear caused the UI jank.
The progress dialog should be shown only when erase external SD card
is needed because WipeDataTask only wipe SD card in it background
task. Other factory reset function is done in Thread thr.
Fixes: 140594314
Test: manual
Change-Id: I71ab1577165ceab79704b359c47c3f752d9dfc79
(cherry picked from commit d5b1510994)
When deleting an unused static shared library on Q, the user manager was
fetched via mContext.getSystemService. At this time during boot, the
service wasn't registered and so null was returned. This has already
been addressed in R with a move to injecting dependencies in the
PackageManagerService constructor.
Bug: 142083996
Bug: 141413692
Test: manual; remove static dependency on eng Q build and reboot
Change-Id: I8ae4e331d09b4734c54cdc6887b273705dce88b1
1. Prevent UserManager from destroying storage for precreated users.
2. Modify UMS.getUserIds to exclude precreated users.
3. Remove pre-created users if the system has upgraded.
4. Read permissions during conversion to a "real" user. Permissions should have been granted during the pre-creation. If we cannot read permissions, re-grant them for the user.
Fixes: 143464654
Fixes: 143463955
Test: Repeated subsequent boots; observing logs; boot systrace; applied OTA, verified user cleanup
Change-Id: I75b031105b2622a8a28e84cf2394e43ec93e4174
Fixed the incorrect warning area coordinate decoding
when data length is greater than 127 bytes.
Bug: 143762197
Test: unit test
Change-Id: I498ccd0933f31898d531dcea307e160ae94653e8
Previously the entire set of notifications was "leaked" until
the next call to getNotificationsForCurrentUser(), which
currently only happens for certain configuration changes
(UiMode, density, fontscale).
Bug: 143461605
Test: atest SystemUITests
Test: sanity check: boot and switch night mode
Change-Id: I39f2c96f848ab92a050aa4bda3ae203fbf99d915
(cherry picked from commit c0c6edee7f)
Since we can't guarantee apps won't call back into us while calling
getInterfaceDescriptor() (even though that's a *really* bad idea),
don't hold any locks while doing so, to protect us from deadlocks.
Bug: 140603195
Test: adb shell am dump binder-proxies
Change-Id: I6289c799aa7027f80792cb751fe1dc437552ea58
If user executed startLocalOnlyHotspot(), then reservation.close()
garbage collector still keeps reservation object until drain.
If user executed startLocalOnlyHotspot second time during
application life cycle, garbage collector can delete previously
allocated reservation object. In this case finalize() of old
reservation object will be executed, then close(), then
stopLocalOnlyHotspot(). As result, new started LocalOnlyHostpot
can be immediatly stopped by old reservation object delete.
Steps to reproduce: execute startLocalOnlyHostpot() and
reservation.close() multiple times during application life cycle,
check if hotspot up couple of seconds after start.
This fix prevents stopping of local hotspot if reservation
was previously closed.
Test: manual
Bug: 139074896
Bug: 143653311
Change-Id: I86c10b577dbab8cad2d5f7e19805511a93bcb668
Merged-In: I86c10b577dbab8cad2d5f7e19805511a93bcb668
(cherry-picked from ee7b0a6ab2)
"Swipe up to unlock" should only be visible when the screen is
interactive, even though it would last for 5sec otherwise.
Test: manual
Test: atest KeyguardIndicationControllerTest
Fixes: 139400542
Change-Id: If7290459a3ae28f689cf4c9e2311398e5f6bcf13
Merged-In: If7290459a3ae28f689cf4c9e2311398e5f6bcf13
