Dumping stack traces can be extremely expensive, and doing so for
background applications often has extremely negative side effects for
foreground applications. This can be exacerbated by resource-intensive
applications, because those may exhibit thermal throttling in the first
place. For such applications, the additional performance hit caused by
stack dumps may be catastrophic.
Instead, don't dump stack traces for background ANRs except for the app
that actually ANR'd.
bug 30112521
Change-Id: I8a05059343254861c436a193690cd1c50a95d674
In some circumstances wallpaper-related files are moved into position,
and must then take proper effect. Make sure that they have the
correct SELinux labels afterwards to avoid preventing some valid
accesses.
Bug 29469965
Change-Id: I6d7c86be63d568fa0ad8841d109a7ff2149fdd54
In extreme cases the list of recent tasks can grow beyond the size
of a single Binder transaction. This change moves over to
ParceledListSlice which handles chunking any large results.
Bug: 29635557
Change-Id: Iaf1227234f5f8c9451f73a6a5c1dc89f2067f05f
In the past, if an app never renders to a SurfaceView, it will be
invisible despite having FLAG_OPAQUE. This means an app could leave a
totally empty SurfaceView (never drawing in to it) on top of a second
SurfaceView, and expect the second one to be visible. This is probably
buggy app behavior because FLAG_OPAQUE means if they ever draw anything at all
in to the top SurfaceView the bottom one will become totally invisible.
However this has worked in the past, so we have to preserve things for
apps. To accomplish this we ensure only the bottom most visible
SurfaceView for a given AppToken will receive a background. We achieve
this by synchronizing through the app token whenever visibility or
layering of a SurfaceView changes.
Bug: 29580298
Change-Id: I0023326323cb961b56404fd49093384e7b72aa54
Since all pending intents are stored on a Set in the Notication object,
there is no need to individually check for specific pending intents.
BUG: 29480440
Change-Id: I27a18bb535a9a4bb6cb4e76bdc189e6c315a684a
It must call updateWhitelistManagerLocked() because the app might have
other services with the whitelistManager set, in which case the process
record should not have whitelistManager reset.
Fixes: 29480440
Change-Id: I268278c646aaa89a352f02178b294c02c3c11d35
We need to make every peniding intent that went in the notification
system to allow special handling of such intents when fired by a
notification listener. If a pending intent from a notification
is sent from a notification listener, we white-list the source app
to run in data saver mode for a short period of time. The problem is
that actions and the notificaion can have extras which bundles may
contain pending intents but the system cannot look into the bundles
as they may contain custom parcelable objects. To address this we
keep a list of all pending intents in the notification allowing
the system to access them without touching the bundle. Currently
the pending intents are written to the parcel twice, once in the
bundle and once as the explicit list. We can come up with a scheme
to optimize this but since pending itents are just a binder pointer
it is not worth the excecise.
bug:29480440
Change-Id: I7328a47017ca226117adf7054900836619f5679b
When removing the ContentObserver wrapper from our internal
bookkeeping we were using the wrong key. That led to future
re-registrations thinking they were reusing a currently-
registered observers, but instead never getting onChange()
notifications.
Change-Id: Id3111db057ae63194049d7d48d45b75be6bb0000
If disabling Bluetooth times out, wait for an additional amount of time
to ensure the process is shut down completely before attempting to restart.
Bug: 29738770
Change-Id: I43dec35a1e03d12cb07863babea97d55baa32528
We can't update this in updateOomAdjLocked(), because we very
deliberately only iterate through services in there as needed.
The correct thing to do is update the process as services/connections
are associated with it, so do that.
Now basically all of the logic for tracking the state is in
ActiveServices, as we bind and unbind services and add and removing
them from process records. It's a little messy because we don't
have a central place for removing them from process records, which
should be cleaned up in the future.
Part of fixes for issue #29480440
Change-Id: Iac96f002a5b4e3b0277df244ff7b90f59a6e8440
While performing ensureActivitiesVisibleLocked we should only
resume activity in focused stack. Otherwise we can get several
resumed activities at the same time.
Bug: 29619461
Change-Id: Id65fe1a29841ee3166694bfb6a8236151b9fc7ec
Work towards better diagnosing b/29501073. Adds logic to ensure that the dropbox
entry generated for ANRs fits at least some part of the logcat before the MAX_DROPBOX_SIZE
mark. Also reduces the MAX_DROPBOX_SIZE to be better match size restrictions.
Bug: 29501073
Change-Id: Ice5599582cbb536b7d81aa0c0340ff753ca86ebf
Currently, an incoming call will not vibrate properly in certain cases
in DND mode. Specifically, if Priority Only mode is set, but Calls from
anyone are allowed. We now get the internal ringer mode to detect if the
incoming call is ringing while in DND mode.
Bug: 29184073
Change-Id: I1e0e7cf384a2bc1df1378043cd3f7e9dec57a94c
When an app is being uninstalled for a specific user, only kill the
app under that user; leave the app running under other users.
Bug: 28875343
Change-Id: Ie60753cfd22df10a2b17d8c3732b6f19d2fe1fb9
A malformed RA could cause the Ra constructor in ApfFilter to
enter an infinite loop while holding the class lock. This blocks
IpManager until reboot and drains the battery.
Bug: 29586253
Change-Id: Idaa46b3bc50371db076630881883807c2fa21674
If the display density change made app restart when it was focused
or we navigate back to it after density change and it makes it
restart - we didn't display unsupported display size dialog.
Bug: 29574686
Change-Id: Ic8fdc8a54df160f947e2d340ab2cb2931bac195d
* Exclude key/value-only backup participants until we have a chance to
augment the archive format with proper handling.
* Don't back up 'stopped' apps, which would un-stop them
* Fix unspecified-user bindService/startActivity invocations
* Teach adb restore about the onRestoreFinished() lifecycle method
* Implement proper app timeout handling in the adb data flows
* Backstop wallpaper backup against rare leftover-state issues
Bug 28056941
Change-Id: Ia59c71a2c74a632a2c2a527b9b7374229c440d46
Changes were discarded if they arrived too quickly in
A11yManagerService. Excuse content change events from
throttling at this level.
Bug: 29355115
Change-Id: Ifd9da07315ce0c18f59c1dad6a621110ad48343b
When primary shared storage is completely missing, catch the thrown
exception and treat as if ejected.
Bug: 29461637
Change-Id: I8eb5cdeb01983efbf26da3d32ab19a6630662156
In getPersistedUriPermissions, use granted userId instead of the calling
userId to look up provider info.
Bug: 29058113
Change-Id: Ia637be414f9ef3b8e9bce13bb56bd335cfb28ac7
Otherwise there is a potential deadlock when an unsolicited event
arrives from vold while we're still waiting for the move operation
to be processed.
The safe fix here is to kick off the move after dropping the lock.
Bug: 29501052
Change-Id: I2160c6a7a19c1d9981c692a2be2b04019352db2e
