PackageManager typically deals with creation of package level
directories via installd. The owners of those storage areas are then
responsible for creating finer grained sub-directories.
SdkSandbox requires per-sdk directories under the sdk package directory
created during package install. This CL opens up a system API via
PackageManagerLocal to enable SdkSandboxManagerService create the
sub-directories on demand.
Bug: 211763739
CTS-Coverage-Bug: 224738104
Test: atest SdkSandboxStorageHostTest
Change-Id: I68259abd16b6767c28093d88e27a52d6c6bdde76
For WebView to run in an sdk sandbox process, Context.getDataDir() needs
to return the shared sandbox storage. This CL sets the value in
LoadedApk while binding the application and modifies bindSdkSandbox API
to take in the client app package name to use in the path.
Test: Manual, check that WebView in sandbox tries to access sandbox
shared storage
Bug: 216284889
Change-Id: I1f8bb7e533d155050710866b80047ec849a98f35
Allow to pass different flags to the API as opposed to setting it to
BIND_AUTO_CREATE by default. The API is renamed to
bindSupplementalProcess accordingly. Additionally, the process name is
allowed to be passed from the caller side.
Test: Manual, install suplemental process test apps and see processes
Bug: 218314884
Bug: 209058402
Change-Id: I0809f824c64d2512feff44e131c40f0ea8bc8ed3
Modify activity manager code to allow for multiple processes to be
spawned for the same service (non-isolated) having different instance
names. A new API is introduced similar to bindService where the app UID
associated with the supplemental process service is used as the instance
name.
The main changes involve distinguishing it from isolated service
processes with instance name, removing a check that allows only isolated
services to have instance names and using distinguishing process names
in the ServiceRecord for the different processes running that service.
Bug: 203670795
Bug: 209058402
Test: Manual, installing two Supplemental client apps and attempting to
load code from each and examining new processes created. Automated tests
are WIP.
Change-Id: I2e349412338e6f0cc9cabaefb77fe2413f5850e0
The services/api/{current,removed,lint-baseline}.txt files used to
contain information for the merged system server stubs. Those files are
now created by the rules in api/Android.bp
('services-system-server-current.txt' and 'services-system-server-removed.txt').
Test: m checkapi
Bug: 177640454
Change-Id: I365be0a45126a6a056d5219e24ef93020c034c87
The statsd ready broadcast needs to be sent from statsd apex with
Intent.FLAG_RECEIVER_INCLUDE_BACKGROUND flag that is @hide and cannot be
promoted to @SystemApi.
In R, this was worked around by getting the list of registered broadcast
receivers and sending them directed broadcasts to wake them up in
ag/10404099.
However, this is inefficient if there are multiple receivers so this
change creates a SystemApi for sending the actual broadcast with the
flag as recommended in ag/10404099 after it was submitted.
Bug: 150746848
Test: m
Test: flash
Test: ensure broadcast is received via logcat
CTS-Coverage-Bug: 184014462
Change-Id: I5103d8c6e87bdb47930cb7457731050da3d8e566
Bug: 174699413
Test: manual - verified that the app receiving onMediaButton()
callback is able to start FGS only when the caller is in a
state to start FGS.
CTS-Coverage-Bug: 174699413
Change-Id: I2dea43b79aa48fde83c6c3da2ad1454b29d60867
Separate out stubs from non-updatable part of the system server. The
ultimate goal is to create system server stubs by merging the
non-updatable stubs and the per-module stubs, instead of generating them
from the combined sources.
Bug: 177640454
Test: m checkapi
Change-Id: Iecb9d51472ae238bbeabe65e1cd782b7c8a4ce59
These changes have to be in this CL together because:
- Code in service-permission depends on IRoleManager in
framework-permission, so the APIs in framework-permission and the code
in service-permission need to be moved together.
- The changes to service-permission build rules doesn't make sense
without the code moved in, so they have to be together as well.
Other details:
- framework-annotations: Several annotations are added into
framework-annoatations. Since the discussion with API council seems to
allow user IDs in system server in-process APIs, @UserIdInt and
@AppIdInt is added. @MainThread and @AnyThread is added since
@WorkerThread is already added. @CallSuper is added since @CheckResult
is also already added and they are similar in terms of category of
functionality.
- framework-permission-s-shared-srcs: 3 classes (and 2 AIDL files)
from framework is copied as shared source files and jarjared for
framework-permission, and an additional 3 is added for
service-permission as service-permission-shared-srcs. Similar to
framework-wifi and service-wifi, the 3 classes in framework-permission
is also available to service-permission by the stub library
framework-permission-pre-jarjar, and the other 3 classes used only for
service-permission is included separately to minimize our impact on
classes loaded into boot classpath. framework-permission and
service-permission shares the same jarjar rules to make sure the
classes remain available, and for the same reason framework-permission
cannot be shrank during any optimization.
- framework-permission-s-shared: A java_library target for
framework-permission-shared-srcs is created to make sure that the
public classes won't be counted as APIs, as it would be if directly
included as srcs for framework-permission
java_sdk_library. service-permission-shared is the same thing for
service-permission.
- framework-permission-s: A new java_sdk_library target created to be
loaded into bootclasspath by Android S+.
- Dumpsys Protobuf: The dumpsys protobuf
file (rolemanagerservice.proto) is moved into the module, and both the
platform (incident.proto) and the module uses protoc-gen-javastream to
generate the Java classes from it. This should be fine since it's a
"source level inclusion", and we jarjar the generated classes in our
module to avoid conflict with platform copies.
Bug: 158736025
Test: manual
Test: device boots, default apps can be changed successfully.
Change-Id: I1914774f631e51d0c587a7e527a1c9bc05ee1595
This is similar to LocalServices, but dedicated to module API in the
same process.
Bug: 158736025
Test: presubmit
Change-Id: Ib9f14070a665ebd8c582376d7ea044d9b945b6b0
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 that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
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 begins defining top-level OWNERS lists,
including a general catch-all for string translations.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: Ie7ac3302d40a717fa048115cca2ea4359de64959
These were previously turned off as there were no previous
releases to compare it to. Check in empty files as comparison.
Whitelist current lint problems for now (filed bugs to follow-up).
Bug: 149818061
Bug: 149818284
Bug: 147559833
Test: m checkapi
Change-Id: Ib4cbc84ac9a826f7b947c951c94f8f5578f4554d
