This change adds a mechanism for restricting permissions (only runtime
for now), so that an app cannot hold the permission if it is not white
listed. The whitelisting can happen at install or at any later point.
There are three whitelists: system: OS managed with default grants
and role holders being on it; upgrade: only OS puts on this list
apps when upgrading from a pre to post restriction permission database
version and OS and installer on record can remove; installer: only
the installer on record can add and remove (and the system of course).
Added a permission policy service that sits on top of permissions
and app ops and is responsible to sync between permissions and app
ops when there is an interdependecy in any direction.
Added versioning to the runtime permissions database to allow operations
that need to be done once on upgrade such as adding all permissions held
by apps pre upgrade to the upgrade whitelist if the new permisison version
inctroduces a new restricted permission. The upgrade logic is in the
permission controller and we will eventually put the default grants there.
NOTE: This change is reacting to a VP feedback for how we would handle
SMS/CallLog restriction as we pivoted from role based approach to roles
for things the user would understand plus whitelist for everything else.
This would also help us roll out softly the storage permisison as there
is too much churm coming from developer feedback.
Exempt-From-Owner-Approval: trivial change due to APi adjustment
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
Test: atest CtsPermissionTestCases
Test: atest CtsPermission2TestCases
Test: atest RoleManagerTestCases
bug:124769181
Change-Id: Ic48e3c728387ecf02f89d517ba1fe785ab9c75fd
Add Shell permission for new CTS tests to test the multi-display
functionality in WallpaperService/WallpaperManagerService.
Bug: 123707989
Test: atest WallpaperManagerMultiDisplayTests
Test: atest ActivityManagerMultiDisplayTests
Change-Id: Id97db050a0b9d1940c2dfaa793fbe526df578105
Allow app to control the thread where ServiceConnection methods are
called on.
Bug: 111434506
Test: Used new bindContext method in chrome and checked callbacks
are on the correct thread.
Change-Id: I480e5bd6773a530fb9e8e73e3a2a2a88b76569ec
Fixes up the android.test.legacy target to stop using sources directly
now that the issue with android.test.runner-minus-junit not being able
to be built against the SDK has been resolved.
Also, fixes a couple of comments.
This reverts commit 7d7af10dc9.
Reason for revert: When this was originally applied it broke the
pi-dev-plus-aosp branch as it contained references to these targets.
Those references have now been removed.
Bug: 63127064
Change-Id: I619e92faf4cc38f8fd4f053bde832e9a76a2a2bf
Test: make checkbuild
For testing we often need to run shell commands. This can be done
today via running a shell command from an instrumentation test
started from the shell. However, this requires adding shell commands
which are not in the API contract, involve boilerplate code, require
string parsing, etc.
This change allows an instrumentation started from the shell to
adopt the shell UID permission state. As a result one can call APIs
protected by permissions normal apps cannot get by are granted to
the shell. This enables adding dedicated test APIs protected by
signatures permissions granted to the shell.
Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases
-t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions
bug:80415658
Merged-In: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
tests need to make sure the flags are set correctly.
Bug: 116738135
Test: atest CtsBackupTestCases:android.backup.cts.PermissionTest#testRestorePermReviewed
Change-Id: Ia1000de3594e910c3345e205679bee37be898d17
Fixes up the android.test.legacy target to stop using sources directly
now that the issue with android.test.runner-minus-junit not being able
to be built against the SDK has been resolved.
Also, fixes a couple of comments.
Bug: 63127064
Test: make checkbuild
Change-Id: If38fa0d87b36343896e97efb2269ac070810db84
Changes to the various api directories will run the
tests which make use of the API specification in those directories.
Could not include CtsSystemApiSignatureTestCases as it is broken on
git_master because of bug 116632058.
Bug: 123254057
Test: atest
Change-Id: I1fe4ca498cbd0393aba7cf4c1386a6325ace7937
The new format is described in tools/metalava/FORMAT.md.
Fixes: 116589402 Switch signature files over to the v2 format
Fixes: 112626813 Drop "synchronized" modifier from the signature format
Fixes: 122358225 Omit overriding methods that only differ in final [...]
Fixes: 73088715 API Review: Need doclava to output nullability
Fixes: 79739773 API Review: Metalava enforcing constants are constant
Exempt-From-Owner-Approval: Large-scale tooling change
Test: make sdk, make update-api, make checkapi
Change-Id: Ia248aece5250e84e47c815c601133b698bf644c2
The new format is described in tools/metalava/FORMAT.md.
Fixes: 116589402 Switch signature files over to the v2 format
Fixes: 112626813 Drop "synchronized" modifier from the signature format
Fixes: 122358225 Omit overriding methods that only differ in final [...]
Fixes: 73088715 API Review: Need doclava to output nullability
Fixes: 79739773 API Review: Metalava enforcing constants are constant
Exempt-From-Owner-Approval: Large-scale tooling change
Test: make sdk, make update-api, make checkapi
Change-Id: I8314f4e7099fa92e4f8ed7d283ccf836cc9a84a0
Merged-In: Ia248aece5250e84e47c815c601133b698bf644c2
The impl lib name of java_sdk_library is changed to {module_name}.jar
instead of {module_name}.impl.jar
android.test.mock.impl is removed from stubs_defaults.
RepetitiveTest class is added to public API in android.test.base
Bug: 110404779
Test: m -j
Change-Id: I5dd7f3a28bc22136b4e921de3eb5a3e77e5fc75f
Merged-In: I5dd7f3a28bc22136b4e921de3eb5a3e77e5fc75f
(cherry picked from commit b7540bf1a3)
The impl lib name of java_sdk_library is changed to {module_name}.jar
instead of {module_name}.impl.jar
android.test.mock.impl is removed from stubs_defaults.
RepetitiveTest class is added to public API in android.test.base
Bug: 110404779
Test: m -j
Change-Id: I5dd7f3a28bc22136b4e921de3eb5a3e77e5fc75f
android.test.mock, com.android.location.provider and
com.android.mediadrm.signer libraries are change to using metalava
instead of doclava.
Test: m -j
Bug: 117127012
Change-Id: I82e838ab60110698e1c0ea8e567467a1b32707ce
Entries from DownloadProvider are added to MediaStore Downloads
collection. COLUMN_MEDIASTORE_URI will be used to track corresponding
entries in MediaProvider. We can't re-use COLUMN_MEDIAPROVIDER_URI
for this purpose because it is updateable by apps.
Bug: 120876251
Test: atest DownloadProviderTests
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ifd252c54f4ee739a31be2866896efac6696a088e
This change adds RollbackManagerService as a new system service for
managing apk level rollbacks.
To work properly this requires additional selinux policy changes. Fails
gracefully in case of selinux denials, until we have a chance to sort
out the proper selinux policy.
Bug: 112431924
Bug: 116512606
Test: atest RollbackTest, with selinux enforcement off.
Test: atest CtsPermission2TestCases:PermissionPolicyTest
Change-Id: Id72aae9c4d8da9aaab3922ec9233ba335bc0198f
Existing APIs that accept a ContentResolver are too restrictive when
the caller has their own ContentProviderClient already bound and
configured, so we're in the market for a solution to open those
existing APIs to accept a wider range of inputs.
The solution we've come up with is to introduce a super-interface
which contains the common ContentProvider APIs, and then make
ContentProvider, ContentResolver, and ContentProviderClient all
implement that interface for consistency.
After this change lands, we can then safely relax existing APIs to
accept this new ContentInterface, offering a clean path to solving
the problem outlined above.
Bug: 117635768
Test: atest android.content.cts
Test: atest android.provider.cts
Change-Id: Ic5ae08107f7dd3dd23dcaec2df40c16543e0d86e
Exempted-From-Owner-Approval: keep tests working
This will allow apps to better manage many isolated processes,
telling the system how they are grouped together (so should be
managed as one related entity within the LRU cache) and fine-tune
the ordering within that group.
The API is not yet tested... though in theory it is implemented.
But the implementation done for that also fixes a *lot* of problems
with activity LRU management that, even without groups, should
make the ordering of processes in the LRU list much more consistently
match how recently the user has interacted with it.
Also clean up some of the new dumpsys output in the activity manager:
move the new sections to before the process output (so it is still
easy to see the process state at the end of the output), and add and
document the command line options for controlling them. And add a
new "lru" section that gives a clear view of what is going on with
the raw LRU list.
An upcoming change will add tests for the new grouping functionality,
and probably some fixes resulting from that.
Test: atest CtsAppTestCases:ServiceTest
Bug: 111434506
Change-Id: I1f6b6b9de66ccde1573e1a0e9615e8c5f8e6c0d7
This allows clients to run multiple instances of the same
manifest service declaration. It only works for isolated
services, to avoid too much abuse temptation. This is part
of the "Chrome site isolation" work, to allow chrome to have
many more render processes running and help it manage them.
Bug: 111434506
Test: atest CtsAppTestCases:ServiceTest
Change-Id: I22e65758678a07075ed32ed6463082ddf846d3a4
ContextImpl has an internal rule that when ContextImpl#mDisplay is
null the Context is associated with the default display. The problem
is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is
null ContextImpl#getDisplay() tries to get some non-null Display
object by making an IPC to the system server, which is redundant when
the display ID is the only thing that the caller wants to know.
By having an @hide method Context.getDisplayId(), we can ensure that
display ID can be obtained without any IPC. This enables us to
re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM)
for each display but then got reverted due to a performance regression
(Bug 117434607).
There should be no developer-observable behavior change.
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Fix: 117712745
Test: atest FrameworksCoreTests:android.content.ContextTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/tests/coretests/src/android/content/ContextTest.java
Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
The suspending app has more context about why a particular app was
suspended by the user, but we do not want to delegate the interception
of the suspended activity out of the system.
Hence allowing it further customizations to the dialog to make
it clearer.
Test: atest com.android.server.pm.SuspendDialogInfoTest \
com.android.server.pm.SuspendPackagesTest \
com.android.server.pm.PackageUserStateTest \
com.android.server.pm.PackageManagerSettingsTests \
com.android.server.am.ActivityStartInterceptorTest
atest GtsSuspendAppsPermissionTestCases GtsSuspendAppsTestCases
Bug: 112486945
Bug: 113150060
Change-Id: If9f4d14587a2b75bb572e7984a90e300a2c72d16
The new property is added for supporting metalava. But some sdk library
cannot use metalava. So "metalava_enabled: false" is added to these
modules.
Test: make -j
Test: checkapi
Bug: 117127012
Merged-In: Ib65f3cd73dac0ac6ed64afeca6546d99739e4424
Change-Id: Ib65f3cd73dac0ac6ed64afeca6546d99739e4424
(cherry picked from commit 558e702be0)
The new property is added for supporting metalava. But some sdk library
cannot use metalava. So "metalava_enabled: false" is added to these
modules.
Test: make -j
Test: checkapi
Bug: 117127012
Change-Id: Ib65f3cd73dac0ac6ed64afeca6546d99739e4424
The PermissonController is going to become a mainline module, hence it
has to compile against @SystemApi.
PackageManager#arePermissionsIndividuallyControlled controls how certain
permissions are presented in the UI, hence Permission controller needs
to read it. The value of this API comes from a config option.
Bug: 110953302
Test: Built
Change-Id: If78b1bb594af0c85e92abf70ae8315e7ba3f31fa
android.test.* are built with java_sdk_library and api files are added
by running "make update-api".
android.test.base_static is created for allowing to use
android.test.base as a static library.
Bug:77577799
Test: make -j
Test: make checkapi
Test: make checkapi fails with a random change in the txt file
Test: adb shell cmd package list libraries |\
grep android.test.*
And check the android.test.* libraries
Merged-In: Ia27612657532e50b077a9c55dbef59ee3ec04b8a
Change-Id: Ia27612657532e50b077a9c55dbef59ee3ec04b8a
android.test.* are built with java_sdk_library and api files are added
by running "make update-api".
android.test.base_static is created for allowing to use
android.test.base as a static library.
Bug:77577799
Test: make -j
Test: make checkapi
Test: make checkapi fails with a random change in the txt file
Test: adb shell cmd package list libraries |\
grep android.test.*
And check the android.test.* libraries
Change-Id: Ia27612657532e50b077a9c55dbef59ee3ec04b8a
This splits the
- review permissions
- individually control permissions
- consent to manage wireleess (wifi + bluetooth)
properties.
Almost all code cares only for the first and it is now always true.
Hence a lot of code can be simplified.
Bug: 110431654
Test: atest PermissionsHostTest
started pre-M app
Change-Id: I733cd476ccd0bf5eaa59e9a9506db34f57c6baee
Adjust the build rules of android.test.*.stubs packages to also
produce a jar with dex files. This will be used by the `hiddenapi`
tool to categorize the boot class path equivalents as public API.
Bug: 79409988
Test: m android.test.base.stubs ; check javalib.jar contains dex
Merged-In: I1d0850b18044c559ea4b9893d929dc45884b32c3
Change-Id: Ief28cd5e6d0cdd58f22fab751e0173ccf8c69a0c
Adjust the build rules of android.test.*.stubs packages to also
produce a jar with dex files. This will be used by the `hiddenapi`
tool to categorize the boot class path equivalents as public API.
Bug: 79409988
Test: m android.test.base.stubs ; check javalib.jar contains dex
Change-Id: I1d0850b18044c559ea4b9893d929dc45884b32c3
Most jars don't need to be installed on the device. Instead of
using java_library and java_library_static to distinguish between
them make java_library and java_library_static identical and use
installable: true to identify the few jars that need to be dexed
and installed on the device.
Bug: 110885583
Test: m checkbuild
Change-Id: I579da7c1a712ec4fb49e288e7f3ab369cb75baf4
Incoming and outgoing call phone numbers are visible in the phone state
broadcast and via the PhoneStateListener. To enhance user privacy, change
to require the READ_CALL_LOG permission in order to receive the call
phone numbers.
This means to see phone numbers:
1. android.intent.action.PHONE_STATE - requires READ_PHONE_STATE and
READ_CALL_LOG permission.
2. PhoneStateListener#onCallStateChanged - now required READ_CALL_LOG
permission.
To support this new behavior, added sendBroadcastAsUserMultiplePermissions
method to context to allow sending the broadcast to all users while
requiring the two permissions.
Bug: 78650469
Test: Created PHONE_STATE broadcast receiver in test app and verified that
when no permissions are granted, the phone number is empty for incoming
and outgoing calls.
Test: Granted Phone state permission to test app and verified that phone
number is not populated.
Test: Granted test app read call log permission and verified that phone
number is populated.
Test: Created PhoneStateListener in test app and verified that when no
permissions are granted, phone number is empty for incoming and outgoing.
calls.
Test: Granted read call log permission to test app and verified that both
the incoming and outgoing numbers are populated.
Change-Id: I857ea00cc58a0abbb77960643f361dd6dd9c8b56
Incoming and outgoing call phone numbers are visible in the phone state
broadcast and via the PhoneStateListener. To enhance user privacy, change
to require the READ_CALL_LOG permission in order to receive the call
phone numbers.
This means to see phone numbers:
1. android.intent.action.PHONE_STATE - requires READ_PHONE_STATE and
READ_CALL_LOG permission.
2. PhoneStateListener#onCallStateChanged - now required READ_CALL_LOG
permission.
To support this new behavior, added sendBroadcastAsUserMultiplePermissions
method to context to allow sending the broadcast to all users while
requiring the two permissions.
Bug: 78650469
Test: Created PHONE_STATE broadcast receiver in test app and verified that
when no permissions are granted, the phone number is empty for incoming
and outgoing calls.
Test: Granted Phone state permission to test app and verified that phone
number is not populated.
Test: Granted test app read call log permission and verified that phone
number is populated.
Test: Created PhoneStateListener in test app and verified that when no
permissions are granted, phone number is empty for incoming and outgoing.
calls.
Test: Granted read call log permission to test app and verified that both
the incoming and outgoing numbers are populated.
Change-Id: I857ea00cc58a0abbb77960643f361dd6dd9c8b56
