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
Merged-In: I5103d8c6e87bdb47930cb7457731050da3d8e566
This is similar to LocalServices, but dedicated to module API in the
same process.
Bug: 158736025
Test: presubmit
Merged-In: Ib9f14070a665ebd8c582376d7ea044d9b945b6b0
Change-Id: Ib9f14070a665ebd8c582376d7ea044d9b945b6b0
This is a change analogous to https://r.android.com/1432681 for system
server stubs; it feeds into metalava the stubs for the non-updatable
system server api stubs and the individual mainline module system server
stubs to generate a merged .txt file that will eventually replace the
monolithic one in frameworks/base/services/api/current.txt .
Bug: 177640454
Test: diff frameworks/base/services/api/current.txt \
out/soong/.intermediates/frameworks/base/api/services-system-server-current.txt/gen/system-server-current.txt
Change-Id: I021f59bb91572d28798a97ab8aa687b684599d6c
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
Merged-In: Iecb9d51472ae238bbeabe65e1cd782b7c8a4ce59
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
