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)
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
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)
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
