As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
This was newly added to a now deprecated service. we can just
remove it and not provide backwards compatibility
Test: Built
Bug: 123221743
Change-Id: Ic7ff6674d3eafd98cd00f3a3e1d92c8161ba3f16
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
And check parameters at trust boundaries
Test: Looked at AppInfo in Settings (uses RuntimePermissionPresenterService)
Change-Id: Ie70f64c1bc5435e1d284c37cc6fec208468b3a0a
The PermissonController is going to become a mainline module, hence it
has to compile against @SystemApi. Hence all APIs needed have to be
upgraded.
Bug: 110953302
Test: Built
Change-Id: I329e062040bdb6dc20fd65baf71e025338d01c4e
For packages:
android.permissionpresenterservice
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: If94e49a237e553f62af888cc01282b5152f26b2d
The PackageInstaller app manages side-loading apps as well
as permission management. It should be updatable, hence
should rely on system APIs to talk to the platform. This
is the first step of defining an API boundary.
Change-Id: I9814eafd0b22ae03b4b847a7007cdbf14c9e5466
