Shell needs to have this permission in order for the deviceidle
tempwhitelist shell command to exist.
Bug 34715096
Test: cts-tradefed run cts -m CtsAppTestCases \
-t android.app.cts.ActivityManagerTest#testBackgroundCheckService
Change-Id: Ic1fdd87b6020649705ba0c9349dd00dd096037f3
Caused b/35926593 because ExternalStorageProvider needs raw
access to underlying devices that aren't mounted visibly, like
USB mass storage devices.
This reverts commit 53d64fc839ad79be28d783f0f14082310a647dd9.
BluetoothManagerService for some reason leaks the Android's Bluetooth
MAC address via Settings.Secure which is normally readable by all
apps. This lets apps bypass the restriction on access to Bluetooth MAC
address from apps.
This commit fixes the issue by restricting access to bluetooth_address
secure setting (Settings.Secure). Only packages which hold the
android.permission.LOCAL_MAC_ADDRESS permission retain access.
This commit accordingly grants LOCAL_MAC_ADDRESS permission to the
system Shell app because a number of scripts (including Android CTS)
use "adb shell settings get secure bluetooth_address" as a convenient
way to query the device's Bluetooth MAC address over ADB. This is
acceptable because the user of the device can see the Bluetooth MAC
address and thus it's fine for shell to be able to see the address as
well.
Test: See CTS test added in the cts project in this topic.
Test: "adb shell settings get secure bluetooth_address" returns the
Bluetooth MAC address of the Android.
Test: "adb shell settings list secure | grep bluetooth_address"
returns the Bluetooth MAC address of the Android.
Test: Bluetooth works (toggling off/on, pairing, file transfer)
Bug: 33701414
Change-Id: I17b110b96eb3794b25c1661e93d29a7a003e3c9a
The Shell application needs access to change which overlays are
enabled in OverlayManagerService.
Test: Manual: invoke adb exec-out cmd overlay enable some.package.name
when shell is not root (adb unroot on eng builds).
Change-Id: I1849f68e244cfc9b1e13eb0e673dde7be03cba6d
The new sdcardfs filesystem requires that we have stricter access
controls around /data/media style locations. Start by taking away
the "media_rw" GID from apps requesting the WRITE_MEDIA_STORAGE
permission.
Common use-cases like music playback appear to continue working fine,
as clients should only be attempting to use /data/media paths after
calling maybeTranslateEmulatedPathToInternal().
Test: builds, boots, music playback works
Bug: 35447080
Change-Id: Iba9f3ef41d3277c75497f675a1fe6d3406cf4542
...when using device on mobile data
Whitelist CellBroadcastReceiver, this is a core OS component anyway
so this probably makes sense.
Test: manual
Change-Id: I1560093640e81064ad123ff0bbcb307583fc47c6
This shouldn't properly be emplaced as a side-effect of partner-
specific configurations; so now we don't do that any more.
Bug 35151478
Test: verify whitelist contents with 'bmgr whitelist'
Change-Id: I854ddfdbcec1def882b24f5ea7955b28d4789806
Camera service will need to a way to query
the process state and oom score.
BUG: 34701266
Test: Manual testing + cts-tradefd run cts -m Camera --abi armeabi-v7a --disable-reboot
Change-Id: I4df704817d2fc728d421daeffbbbcee2e61d8c3b
Adds android.permission.BIND_IMS_SERVICE to the permissions
whitelist xml file.
Bug: 34813244
Test: Manual
Change-Id: I7a7ad1a361c9d2dcc51769bc74a436878ad4adc5
Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Icc19b2fbc05f40dcf8c3fc4abf718c373dc8d4f6
Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Ib444829a2d222125f64ff19e8218823fa78373f9
Added support for privapp-permissions config element. It allows to explicitly
control what privileged permissions applications should be granted.
Feature is controlled by ro.control_privapp_permissions property.
Possible values:
- 0/false, the feature is completely disabled - signature|privileged
permissions are granted automatically without logging. *Default behavior*
- 1/true, enforce that only whitelisted permissions are granted. Only
devices with ro.control_privapp_permission=1 will pass CTS tests.
Test: Manual
Bug:31008485
Change-Id: I93a8c2782cc72b3953f32c237086d08d82ac0d5b
DownloadProvider is now based completely on JobScheduler, and deep
inside the platform we allow foreground
downloads (FLAG_WILL_BE_FOREGROUND) to run even while the device is in
doze, so it doesn't need to be temporarily whitelisted anymore.
BUG: 29056149
Change-Id: I3658bb42aeeee5d5528f91ec990d6e1bc54257b6
These are permissions that were mapped to gids but we need
to keep them listed event though they are no longer mapped
to gis until an upgrade from L to the current version is to
be supported. These permissions are built-in and in L were
not stored in packages.xml as a result if they are not defined
in the platform.xml while parsing packages.xml we would
ignore these permissions being granted to apps and not
propagate the granted state.
From N we are storing the built-in permissions in packages.xml
as the saved storage is negligible (one tag with the permission)
compared to the fragility as one can remove a built-in permission
which no longer needs to be mapped to gids and break grant
propagation.
bug:27185272
Change-Id: I65e05c4f7edd9a934888b4d0974100aa4e9a9453
* Added GID "wakelock" (3010) to the list of groups the System Server
belongs to.
* Added GID "wakelock" to the list of assigned groups for the
"android.permission.BLUETOOTH_STACK" Android permission.
* Grant CAP_BLOCK_SUSPEND to processes that belong to GID "wakelock"
Bug: 25864142
Change-Id: I8a9a5f11e4a9ecd1abf2d4f4b90ec89b3101332e
For the system user, enable apps based on the following conditions:
- app has no launcher icons or has INTERACT_ACROSS_USER_FULL permission
- app is whitelisted
- app is not in the blacklist
Bug: 23283899
Change-Id: I90fa266e8cfb28d002e5f792998fdddb6a1e6969
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
Typical apps are restricted so they can only view shared storage
belonging to the user they're running as. However, a handful of
system components need access to shared storage across all users,
such as DefaultContainerService and SystemUI.
Since WRITE_MEDIA_STORAGE already offers this functionality by
bypassing any FUSE emulation, reuse it to grant the "sdcard_rw" GID
which is no longer handed out to third-party apps. Then we change
the FUSE daemon to allow the "sdcard_rw" GID to see shared storage
of all users.
Bug: 19995822
Change-Id: I504c2a179ba74f142ed0d32da5baa69f4212cd82
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
Bug: 21858077
Change-Id: I62fb25d126dd815aea699b33d580e3afb90f8fd2
This will eventually allow us to have a single unified filesystem
instead of requiring zygote to use bind mounts.
Change-Id: I29b819ab51498b4bab874e0367b1ab4165f84025
We continue to compile external/apache-http into ext.jar. This contains
a few changes apart fom the classes moving around :
- Makefile changes to build docs and api-stubs for now. A future change
will revert these changes and remove these classes from stubs and
docs.
- Hardcode event IDs in legacyerrorstrings to avoid a dependency between
the frameworks and apache. These strings are on their way out and will
never change anyway.
- Remove imports due to {@link} tags and use {@code} instead.
- Remove an accidental(?) dependency on apache commons code that's a
part of apache-http.
bug: 18027885
Change-Id: I51cd038d846ec7d02c283a4541b10a6a9cf62ecf
Add FM permission like KK to support FM radio app.
Change-Id: Ifb76f63e3136a5f88306903fd28e9abbb01e69c9
Signed-off-by: Benson Huang <benson.huang@mediatek.com>
Conflicts:
data/etc/platform.xml
Some system apps doing hotword training need low-level access to
audio hardware, beyond what the existing HAL offers. For now, give
them the audio GID.
Bug: 17763721
Change-Id: I8025c3abacae13a6ffec4e10e4976a67ab505bdf
The network policy manager now monitors battery save mode and,
when in battery save, uses its facility to block access to metered
networks to block access to all networks. That is, it tells the
network management service that all networks have an (infinite)
quota, and puts various app uids to be restricted under quota
interfaces as appropriate.
This new network blocking needs a new facility to be able to white
list apps, such as GmsCore. To do this, I refactored the package
manager's permission configuration stuff into a separate SystemConfig
class that can be used by others, and it now has a new tag to
specify package names that should be white-listed for power save
mode. These are retrieved by the network policy manager and used
to build a whitelist of uids.
The new general config files can now go in system/etc/config,
though currently everything still remains in the permissions dir.
Still left to be done is changing the semantics of what uids are
allowed in this mode, to include all perceptable uids. (So that we
can still do things like background music playback.) This will be
done in a follow-on CL.
Change-Id: I9bb7029f61dae62e6236da5ca60765439f8d76d2
Write supplementary GIDs to packages.list for lower-level system
components to parse.
WRITE_EXTERNAL_STORAGE also implies sdcard_r GID. Switch to always
enforce READ_EXTERNAL_STORAGE permission. Update permission docs to
mention new behavior.
Change-Id: I316ba4b21beebb387ac05c80980ae9b38235b37d
This gid is not needed by camera-using apps, since all camera access
is mediated by the camera service, which does not depend on gid for
permission checks.
Bug: 9904186
Change-Id: I859e6cabc905af9d98e2b09f5bbad086b5eb2b26
