As the wakelock version number is defined as static to provide
consistent versioning across objects, class level static lock should be
implemented to prevent racing conditions.
To trigger the racing condition, update statsd's stats pulling logic
locally to repeatably requesting wakelock stats then wakeup the phone
to trigger BatteryStats update routine. The racing condition is 100%
reproducible under the setup. The patch has been verified with the
setup, and the racing is no longer seen. See more reproduce details in
the linked bug.
Bug: 173539101
Test: manual
Change-Id: I386afa2f2ecd8678e71ece978da4a9950b21ca4d
It helps remove it from the @CorePlatformApi
Bug: 154796679
Test: ArrayUtilsTest
Merged-In: I0c8f194a74a16b2cc46f9eea4571d5fb674fbc28
Change-Id: I0c8f194a74a16b2cc46f9eea4571d5fb674fbc28
Iteration based on areas of tree where detailed ownership was found
to be missing during routine code reviews.
Also add more detailed examples to OWNERS.md.
Bug: 174932174
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I46ccef33b34594181ae8dc62973d68020f827d6b
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
NetworkUtils is planned to move to a dedicated JAR for connectivity
classes, while NetworkUtilsInternal would stay in the
frameworks-minus-apex JAR, in the com.android.internal.net package.
Bug: 171540887
Test: m, boots, wifi working
atest FrameworksNetTests
Change-Id: I3d38d72ad23a4bf84af823c7baeb6fed25c0665f
The screen brightness float setting initially did not exist when
upgrading the device software. This change ensures the float and int
values are synchronised on the system start-up.
Bug: 174508435
Test: manual - set autobrightness off, upgrade from Q to R, and check
brightness value in settings.
Change-Id: I2a3b996c8747e3c5f1d181bbdd438c70bf23d08b
Merged-In: I2a3b996c8747e3c5f1d181bbdd438c70bf23d08b
(cherry picked from commit 96f43f21b3a3021762c2d213d8958590127cae36)
The service target row was sometimes overfull - with more targets in
the list than were displayed - when we used each row's offset
to calculate which target was selected to launch.
This fix makes sure we are not overfilling.
Test: ChooserActivityTest & manual repro -- use targets from
alphabetical section, make sure you have at least one old-API target
available
Fixes: 170518649, 165944833
Change-Id: I8a554197c01f4eadbeac43742984e4c86ca49601
(cherry picked from commit 6f015708fb)
They mistakenly were tagged as flags, which is not applicable for either
of them.
Test: m
Bug: 174237593
Change-Id: I982ddc53839f13255ea68c9852fd20c3fe5a8433
