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
ICU's TimeZone.toString() prints out too much information. Only the ID
is useful.
Bug: 149014708
Test: build only
Change-Id: I7d633f7946f82696e13dbc39749b6f9f44f83fa3
To avoid a @Nullable Boolean one method has been split into two. After
some changes in the last release this also removes an optional parameter
from the two new methods as it is now always null.
Bug: 148450671
Test: treehugger
Change-Id: I83be9647943c16ae30af4f8d032db428af1ad5fc
Behavioral change to remove the possibility of null from getTimeZone().
The rest are naming and documentation improvements.
Bug: 148450671
Test: treehugger
Change-Id: I412046ce343e76463bf27d8dc5fea46adfd85b0d
Tidy up the libcore.timezone APIs to make them as close as possible to
android.timezone. In future, these classes should be repackages to be
the actual android.timezone classes, so the APIs need to be in sync.
Bug: 148086409
Test: treehugger
Change-Id: Ia520abcf00e691f4a1b5549dafec44b76075e31a
Several android.timezone classes have already been exposed for the
telephony module work, so these tests provide coverage for those.
Additional APIs have been exposed for MTS testing, i.e. to provide
greater confidence that the tzdata module data is correct / is
being read correctly.
Also, small changes to existing code to make them consistent with new
classes. Small docs improvements.
Bug: 147884233
Test: see system/timezone change
Change-Id: I047b29f17a41993f859947a6d6c3685896fe4cb6
Introduce classes that exist to give the telephony module something
stable to call for in-process utilities: libcore cannot directly expose
System APIs today and the package names are internal. The APIs are the
subset of internal libcore.timezone APIs used by telephony code
currently.
Bug: 139091367
Test: See associated frameworks/opt/telephony commit
Merged-In: I6109aef77171346ecb103c190526b7b9b81012b2
Change-Id: I6109aef77171346ecb103c190526b7b9b81012b2
(cherry picked from commit 944aeffa85)
