Changed word within "Process Lifecycle" section, near bottom of
Activity class overview.
Bug: 24561563
Change-Id: I4c4196a656b6ad3e412ed45382fcefc984fe9892
I think what probably happened is that since we only report an app
going in to the "interaction" state as an interaction event to usage
stats, apps that sit around in that state forever will only see one
interaction at the start and never again. So usage stats could start
thinking they are idle.
Fix this by having the activity manager report an interaction event
for such long running applications at least once a day.
Also, because it is correct and for paranoia by protected us another
way, system uids should never go in to standby.
Change-Id: I8a3805bfca86cbe78560488a649ecd07427da99a
Bug b/24993310 flagged an error in the code sample, and while I had
it open, I revised it to be more like the code snippet in the
permissions training doc (which Svet approved).
See first comment for doc stage location.
bug: 24993310
Change-Id: I65336c70e086b06e28816ba8acc6435640178f9c
Remove the partial fix [it did not work for child fragment managers]
and replace with a more general fix that works with all fragments.
Bug: 23838271
Change-Id: I88b465f6a06a6ad627b9651b9e2eea41fae08972
When we restore a fragment [i.e. on configuration change], we need to
make sure the host is set prior to calling into lifecycle methods
such as onInflate(). These use data contained within the host.
Bug: 22512520
Change-Id: I709365a858cfc555ec5b7fc200629fa8d022faad
When an app doesn't define installLocation, the default behavior
should be to treat it as internal only. This matches all the
published developer documentation.
Without this, apps could be unwittingly be moved to adopted storage
devices.
Bug: 24771264
Change-Id: Iaf38ab45329aad6cb5d6deac81fb1781f680189b
We cannot pull the "retain loader" state from the Activity; an Activity may
not always be hosting a Fragment. Instead, save the "retain loader" state
inside the individual fragments.
Bug: 23838271
Change-Id: I8358183a7689b5a571ea7be03d769186b2812600
Our system themes were based on configurations that were added post-
init of the system theme.
I96e695441543379e4d5fdf3cc6f18d9e6cf953b4 broke this, because there
was a race condition in the code for rebasing themes
If8fecde76d62738a8e55eddf898eafc468afdba2 (the cherry-picked commit)
fixes the race condition and adds the rebasing back in.
This change cherry picks If8fecde76d62738a8e55eddf898eafc468afdba2.
Bug:23387146
Change-Id: I0725028e48599fc6cd9731ae16c71474dd5827e5
This change modifies the Notification.Action constructor
to populate the deprecated "icon" field based on the provided icon.
This field is still used by NotificationCompatApi20
to create a NotificationCompatBase.Action from a Notification.Action.
Bug: 23348968
Bug: 22591778
Change-Id: I3576038384d2baa12c4c75bc4124e3859aacbd13
For each runtime permission we have an app op to toggle the
permission for legacy apps as they cannot handle permission
revocations. We were lacking an app op for get_accounts
which prevented the user from controlling access to accounts
regardelss that they change the state of the permission
toggle in the UI. Even worse the permission UI is written
with the assumption that every runtime permission has an
app op and as a result revoking the contacts group (if the
app requests the get_accounts permission) is reset back to
allowed in the UI.
bug:23854618
Change-Id: I9e3f9bfeb320bed561d718db99ee285915d5701b
The platform grants runtime permissions by default to apps on the
system image that provide core device use cases which a user expects
to work out-of-the-box. We are now adding a test to ensure that
OEMs cannot pregrant premissions on non approved components.
bug:23043018
Change-Id: Id76717cce0ee59678956bd0be347d3c045fe4c51
