Clarified behavior when activity is resized or put in fullscreen
mode, per b/28580007 . Also (per email from o-o) removed misleading
statement about when onStop() might or might not be called.
Both changes can go live now (multiwindow update applies to DP1 & 2,
and onStop() clarification applies to all versions of API), so I'll
submit as soon as this is approved.
See first comment for doc stage location.
bug: 28580007
Change-Id: Ib008f24e5796ec7810b67c91e512e679680d4afd
Improved descriptions of the "name" attribute of the <application>
element, which appears within an Android app's <manifest> element in
its manifest file. Also clarified connection between this attribute
and custom subclasses of the Application class.
Bug: 1232595
Change-Id: I79b6bd31224c7669b5dc509914a01ead84a049dc
Abandoned-Change-Id: Icee66f6b8df55c7fad414b4c19939a483dc7a165
element.
Several files associated with a future CL contain extra whitespace.
I've made a separate CL here to avoid inflating the "changed lines"
count within this future CL.
Change-Id: Ie8199abd2a61b77d0fb349435983050e0e06afc7
Abandoned-Change-Id: I92f75ba0ef08e10210434f824fd99caee3703b5e
Changed word within "Process Lifecycle" section, near bottom of
Activity class overview.
Bug: 24561563
Change-Id: I4c4196a656b6ad3e412ed45382fcefc984fe9892
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
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
... by never rebasing the theme. We don't need to do this unless the
system theme is configuration-dependent, which it is not currently.
Bug: 22943781
Change-Id: I96e695441543379e4d5fdf3cc6f18d9e6cf953b4
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
1. When a permission is revoked we kill the app immediately but do
not do an immediate kill for shared uid processes. This fixes it.
2. Remove system APIs that are used only by the package installer.
bug:22984670
Change-Id: I3d4ae52ea8679f894aa7c5972941263903479183
BUG: 22957980
If a file was present in the backup but excluded on restore,
it can result in the restored data being corrupted.
Ensure that FullBackup.restoreFile is called with a
null destination, which will result in the file not
being written to disk, but still properly pulled
from the socket.
Change-Id: Iac882a961b76e687654535aec352678486a08c39
Add additional information about the intentions of result codes in
device-owner and profile-owner launch intents, in alignment with
changes made in http://ag/732321.
Bug: 21063241
Change-Id: I0e0a931739cee5f46e8fc7622fe1de49e26dcb0a
Add new Activity callback to tell it when its saved state has
been invalidated.
The problem is that delivering the permission result does not go
through a path where the compatibility code can see it first to
mark its fragment manager as no longer having saved state. So this
new callback gives it a place to do that.
Change-Id: I5a4a185d9c746bae1afb5c588aba82c8daccf079
Add new Activity.isVoiceInteractionRoot() API that an activity can use
to determine whether it is the root activity of a voice interaction
session started by the user's designated voice interaction service.
This is a special new API that apps must explicitly check, because as
with visual activities the model behind an activity should usually be
that it accomplishes its task by interacting with the user (implicitly
getting their approval) rather than trusting that whoever invoked it
is telling it to do what the user once. In the voice world, however,
there are some cases where quick interactions want to allow for immediate
execution without further user involvement, so this API allows for that
without opening up security holes from other applications.
Change-Id: Ie02d2458f16cb0b12af825641bcf8beaf086931b
Doing this so we don't break current apps. In the future we should
properly position the activity in the stack (i.e. behind all current
user activity/task) and not change the positioning of stacks.
Bug: 21801163
Bug: 13507605
Bug: 22929608
Change-Id: I979b6288e66f5b2ec2a6f22cb8d416e5c68109bd
The app ops mananger service maintains a mapping from UID to
a list of packages where each package is mapped to a list of
non-default app op states (default states are inferred and
not stored). Hence, specifying the app op state for a UID
requires setting the app op for each package in the shared
UID.
This is problematic when installing new packages if there
is a non-default app op policy set for another already
installed package in the same UID as the app op for the new
package has to be updated to be in sync. The package installer
cannot do this as it is in another process and the app op
update will not be atomic. Therefore, the app ops manager
service has to support specifying app op policy on a per
UID basis.
We now have a UID state object that contains the per package
non-default app op states as well as the per uid non-default
app op states. If there is a UID policy specified then it
takes precedence over the per package one. Even further,
changing the uid policy updates the package policies in this
UID if the state is non-default. Changing a package app op
state also updates the app op state for the whole UID if
the per UID policy for this op is non-default. Clearing the
app op state for a package, clears the policy for the UID
as well.
bug:22802981
Change-Id: I78044906d9fcc6066abf07e706c2c88f3397d293
The methods startUsingNetworkFeature, stopUsingNetworkFeature and
requestRouteToHost were @removed in all the M preview builds, but
internal and external developers have noted that this imposes
additional burden for applications that need to work across
multiple platform versions because it causes compile-time errors.
We switched from @removed back to @deprecated to avoid these
problems. In order to effectively deprecate these methods, which
are error-prone and insecure, make them throw
UnsupportedOperationException if the app's target SDK is M or
above.
Because there are still one or two places in system code that use
these APIs, exempt Process.SYSTEM_UID and the OMA-DM client from
the check for now.
Bug: 22728205
Change-Id: I790bd32f3aa8067cbb625962a209bb9232f4b58c
changes)
AppOpsManager:
Changed the default operating mode for WRITE_SETTINGS to MODE_DEFAULT from
MODE_ALLOWED.
packages/SettingsProvider:
We no longer do static permission checks for WRITE_SETTINGS in early checks and
defer that to app op when MODE_DEFAULT is returned. For some operations,
checking against WRITE_SECURE_SETTINGS is sufficient.
ActivityManagerService & PowerManagerService:
Incorporated app op checks and handled the MODE_DEFAULT case.
provider/Settings:
Added helper function to do checks on whether app ops protected operations
can be performed by a caller. This includes checks for WRITE_SETTINGS and
SYSTEM_ALERT_WINDOW.
Also added a public API (with javadocs) for apps to query if they can modify
system settings.
Changed the javadocs description for ACTION_MANAGE_WRITE_SETTINGS and
ACTION_MANAGE_OVERLAY_PERMISSION.
Added public API (with javadocs) for apps to query whether they can draw overlays or not,
and also javadocs description on how to use that check.
Change-Id: I7b651fe8af836c2074defdbd6acfec3f32acdbe9
RemoteViews now allows Icons as TextView compound
drawables in RemoteViews, but not yet as public API.
Bug: 22600607
Change-Id: I986a0ce3bede09746f0b121884184679f39a79f5
In addition to cleaning up some bare references to the icon
slot, we now apply updates to notification RemoteViews in
the context of the supplying app's package. This ensures we
can find the drawables inside any Icon objects that were
constructed without a proper package name, such as is the
case with Actions (because the builder and constructor are
Context-free and so don't know the package name).
This CL also makes clear what was previously only implied:
Non-resource action icons are not actually supported yet
since they can't be pushed to TextView compound drawables
using today's RemoteViews APIs. That will require an API
change.
Bug: 22600607
Change-Id: Ie6b88aed36e4db05be35f843ea3bc1898d4a5c96
Now that we're relying more heavily on Uri permission grants between
apps, we should always return content:// Uris.
Bug: 22820206
Change-Id: Ie9603da09944dc594ea5dde2db04455f57d6f103
...space causing package manager to fail
Lower the maximum IPC size we use in various places, to keep it
under the threshold of becoming dangerous. Now everything tries
to keep not much more than 64k.
Change-Id: I814013097966a7843179e5d581bfdb254c5ae318
