As runtime permissions are complex, all runtime permission code is
consolidated into the permission controller app.
Hence the package manager service's permission backup code is now
calling into the PermissionControllerManager which is a interface to the
permission controller app.
Bug: 120907838
Test: Triggered a backup and checked the result via the debugger.
Change-Id: I633162189b728921d902050eee125b4b40b618fd
Regular ...Manager-s connect to the system server hence there is no
problem establishing a permanent connection via
ServiceManager.getServiceOrThrow.
(1)
PermissionControllerManager connects to an app, hence the binding has to
be dynamic. This is done my using the local RemoteService class.
(2)
...Manager-s are per context. Hence when the context goes away all
service connection started for this service are supposed to also be
cleaned up. There is no callback when the context goes away.
(1) and (2) lead to RemoteService connection to still be bound while the
context goes away which causes a service connection leak.
This change emulates the behavior of regular managers by creating a
permanent RemoteService tied to the application context. Of course
interanlly RemoteService itself binds and unbinds dynamically. Still,
now the RemoteService is not bound to a context that goes away and no
connection is leaked.
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
(this test failed before as settings was crashing due to leaked
remote service connections)
Change-Id: I5b8a4c62070fcce6e390897d046c4b28998e3952
As this has already evolved from just presenting data. In the future any
permission related calls to the permission controller will be added here.
As the calls are protected by different permissions the binding will not
require a permission anymore, but each individual call checks the
permission.
Bug: 120221960
Test: Looked at settings UI showing data from this interface
Change-Id: I6b4a5c3b7ee17b145e11e2c1b6e11a8a232bffed
Consolidate all permission related code in a single java package.
Test: atest SettingsLibRoboTests
Looked at Settings AppInfo UI (uses RuntimePermissionPresenter)
Bug: 120221960
Change-Id: If135e984a8273e9bed80cab9fbf2d70f40a05c7f
This needs to be available before package manager service is ready,
hence set it as soon as possible.
In the future we should also allow access to this mapping from other
processes than the system server.
Test: Built
Change-Id: If4240e5522e175ea9b341e4951ce261f17bbaadc
Instead of defining split permissions in Java file, we now move them to XML allowing us define vendor specific split permissions.
Test: Activity recognition is split correctly and auto granted when below split targetSdk.
Bug: 111411340
Change-Id: Ia5b3f47b73c9feea924373268a4eee142f555091
... as requested per API review.
- Sets require iteration via iterators
- Sets are more expensive to construct
- The advantage of sets (faster .contains) is not used
- The system ensures uniqueness of the entires in the list
Test: Built
Bug: 116798569
Change-Id: I2c3b5c6801b78e0bf942073bde1e90299aee39f6
The Permission Controller app (a mainline module) needs to be able to
read the SPLIT_PERMISSIONS. Hence this array needs to be exposed at
least as system-api. We need to make sure that the PackageParser,
PackageManager and Permission Controller app agree on which permissions
are split, hence it is best to define them at a single location.
I think exposing the split permissions to developers is useless and
potentially confusing. The app should never request a permission that
was split. The app should just behave as if split permissions do not
exist. The Permission Controller / Package Manager deal with the
split permissions and add them when needed. Hence I don't think we
should expose this data to 3rd parties.
Bug: 110953302
Test: requested permissions
Change-Id: I6951c52979c89ee5c13a4a14da125e1a01f2e234
