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
