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
The main change here is to not allow the dialog to go in to its "focus
on the last app the user selected" when running in voice interaction mode,
instead just always giving a simple list.
This also fixes some problems with cleaning up active commands when
an activity finishes and not forcing the current session to go away
when the screen is turned off.
Also added some debug help, having activity print the state of the
voice interactor.
Change-Id: Ifebee9c74d78398a730a280bb4970f47789dadf5
We weren't correctly handling the root view of the window --
we were just pushing it on to the stack, but that means it got
written at the end. Instead, we now immediately write it
after the window and let things follow from there.
Change-Id: I070c96bd2443f312a7c6f495d1bf72fa19c614d6
