Suggest getAvailableBlocksLong() instead of the now-deprecated
getAvailableBlocks() method.
Bug: 174799449
Test: m offline-sdk-docs
Change-Id: I34a36e00c3d1a16898b0a6f0a21e4cab9feb0d02
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
The puller for the atom frequently fails. We believe it is due to the
size of the pulled atoms. No metric can be correctly build from this
atom.
To reduce the size, we apply transformations that we would likely
perform when analyzing this data. We combine times for all shared app
gids together and combine times for the same apps. We also exclude
isolated uids which are frequently recycled and removed from the
underlying data source.
If these optimization do not help, we will need to introduce different
atoms.
Bug: 157535126
Test: cmd stats pull-source 10010
Change-Id: I0d9a18c78f456e1b0f9d7ad322f15354ead9f02b
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
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 is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
We introduce a new profile type for testing purposes.
It can be used for testing non-managed profiles, which
currently only have partial support.
It is only available on debuggable (userdebug/eng).
Bug: 170249807
Test: manual (adb shell pm create-user --user-type android.os.usertype.profile.TEST Name)
Change-Id: I37f593bbcaa9059f3afdc8668c2065bc623aa125
If the user enables this, then that means that we will respect user's
choices for all the preferences, i.e. we will not update the preferences
based on the updates from server.
On the other hand, if it's disabled, then the rest of the preferences
would not be considered. And we'd decide their values based on the
values from the DeviceConfig (which in turn come from the server).
Also, renaming the set prop key for enabling-transcode to match the one
in DeviceConfig - transcode_enabled.
Also, the "transcode_enable_all" controller now enables (instead of
disabling) the global level transcoding.
BUG:169327180
Test: manual testing.
Change-Id: I183b3b5496b647943be377c02c8c9e2a0df71752
This parcelable will replace the separated methods hasAmplitudeControl,
areEffectsSupported and arePrimitiveSupported from VibratorService.
VibratorManagerService will return this single parcelable, per vibator
id, to represent the HAL profile of that individual vibrator and be used
by Vibrator.java to explose some of that to the public API.
Bug: 167946816
Test: atest VibratorInfoTest
atest VibratorManagerServiceTest
Change-Id: I09c191dd15a3cf38122ec6dc87b2d73f46c8cde6
This implementation supports synced CombinedVibrationEffect instances
with prebaked effects only.
This implementation adds some vibration checks from VibratorService to
VibratorManager, and wires the implementation of VibratorController
native service to IVibratorManager.
Bug: 167946816
Bug: 131311651
Test: atest FrameworksServiceTests:VibratorManagerServiceTest
Change-Id: I8da10c7903e91bba30b11fe46515121858fb5211
