This shouldn't happen, since there are many places where
invalid icons should already have been either fixed (in the
case where there's an .icon but no .mSmallIcon) or rejected
(if they're both null or invalid). But if a notification
makes it all the way to SystemUI without a valid icon, let's
crash the sender.
Bug: 23011305
Change-Id: Ifaebec57d59baa1defb4520178b5815d47ed5712
This tightens the guarantee that detached stack won't be used. We also
add logging to detecting a situation where a stack not belonging to a
display is being moved on that display.
Bug: 22191609
Change-Id: Ia674bb5960018104a56c5138775ab5216906675b
When starting the runtime from app_process, we only pass JDWP options
if starting zygote. It prevents from opening a JDWP connection in
non-zygote programs while Android apps (forked from zygote) remain
debuggable.
Bug: 23050463
Change-Id: If8ea719063a65db4cdeed69a838b52e87b078b08
We weren't closing the ZipFiles created in WebViewFactory to check
inside APKs - use try-with-resources to get them closed automatically.
Bug: 23072621
Change-Id: I11c6b77e960a7d240d19d22240cac177b6ba27b2
Initialize current network name to correct value from the
SubscriptionInfo until we get a broadcast about its current state.
Bug: 22212693
Change-Id: I17fa4378cc7a540c81268f8c4d5aa6a505f3ee40
The main looper needs to run freely for a moment after disabling
wifi in order for various signals (content observers, broadcast) to
propagate to all the listeners that need to take action for the
wifi stack to shut all the way down. This patch breaks up the
disable-and-rewrite-config sequence of wifi AP restore in to two
distinct operations separated by a moment so as not to block those
necessary messages.
Bug 22979342
Change-Id: I271766cad0e454669a194652fb67f835bb022cd1
...to persist after reboot
We were writing a corrupt settings file, so would always reset back
to the default app ops state after boot...!
Also add new appops service commands to manually write and read
its settings, since that is very useful for testing.
Change-Id: Ia510507764738fd82e45ec0be6db840c6ea30c28
We now have a new whitelist you can put apps in, which
opts them out of the old battery saver mode and new app idle,
but doesn't keep them from going in to doze. This is for a few
special cases that we had previously whitelisted for battery saver,
and inherited to the new modes... ultimately we should figure out
how to get these apps out of the whitelist completely, but this
will help for now.
Apps in this new whitelist are not shown in the UI, because they
are still significantly restricted by not being able to operate
normally in doze. This also means they are still visible in the
list of all apps for the user to be able to put them on/off the
complete whitelist if that is what they really want.
In the course of doing this, I needed to clean up code in the
network policy manager to better separate management of the
two firewall rules that now have different whitelists applied
to them. This also hopefully just generally simplifies and cleans
up that code. Hopefully!
Change-Id: I92e15f2f85899571dd8b049b5e3eb1354f55f353
