- Extract the battery saver mode transition logic to BatterySaverController.
This now also supports running different code when screen turns on and off.
- BatterySaverPolicy now takes a "per-device configuration" from config.xml,
which can be overwritten via a global setting. We'll use this to set up
max CPU frequencies.
- The actual part to write max CPU frequencies is not finished yet.
Test: atest BatterySaverPolicyTest
Bug: 68769804
Change-Id: Ife38c2cd94ac9902911b005dbbca8b0d0a62e6d7
It's not used by anything yet, but will eventually be used to query
feature override from different data sources (such as Settings.Global)
Bug: 36222960
Test: atest
Change-Id: Ie32f7c59b4a27199da72d8c9fbfdd1aeee6c0b34
This API will primarily be used by GmsCore to send updated configs.
Also, sending a config will implicitly notify the StatsD that this
client wants to know when it should request data for this config.
We send a broadcast so that all interested subscribers can know if
data needs to be pulled.
Test: Manually tested that sending broadcast works via new adb
command added in StatsService.
Change-Id: I23cdd1df706036e14b32c3d01af30c3d4af819fa
The current JobInfo.NETWORK_TYPE values offer basic network selection
ability, but more precise requirements continue to come up. Instead
of creating more NETWORK_TYPE constants, add support for the existing
NetworkRequest object, which is the idiomatic way for an app to
express the type of network they'd like to use.
Move the implementation details of NETWORK_TYPE constants to use this
new NetworkRequest functionality. Deprecate NETWORK_TYPE_METERED,
since the lack of the NOT_METERED capability doesn't imply that the
connection is metered. (Apps using this API to get to a cellular
network should use TRANSPORT_CELLULAR instead.)
Add new SystemClock APIs that return java.time.Clock instances for
various Android-specific clocks. This gives us a clean interface
(with negligible overhead) for swapping in artificial clocks for
testing purposes.
Improve JobStoreTest to validate new NetworkRequest features, and
add one last sanity check to assertTasksEqual() to compare raw
bits-on-wire, to catch people who forget to check new fields. Watch
for IoThread to go idle to run tests faster.
Test: bit FrameworksServicesTests:com.android.server.job.
Bug: 67040695
Change-Id: I189e7602132a0ec26d2f0cc6dadc188664961a47
Test: with CPU locked to low freq, verification time of a 400 MB apk is
reduced from about 2528 ms to 1942 ms, vs 915 ms of the old
algorithm. Writing directly into ByteBuffer's backing array saves
around 100 ms but it does not work for DirectByteBuffer, thus I
didn't implement this optimization.
Bug: 30972906
Change-Id: I00cf782e18a8351569eaf4593188c1ce6796a634
Test: Locally add some code in PackageManagerService to generate the
verity tree. Root hash and the tree is consistent with the output
of apksig.
Test: With local mod, with apk size of 400/100/20/5 MB, verification
time is about the same for the existing algorithm before and after
the refactoring.
Test: With local mod, with a 400 MB apk, verification time of the new
algorithm is slower (2s) than the 1MB-based algorithm (600ms).
Bug: 30972906
Change-Id: Ie429cf9b80884e56a8e0882e1c125c8a3f8feab4
It is very unlikely the protobuf changes the value in descriptor.h,
and if defines an extra mapping, there are several places to maintain:
1. java-stream,
2. cpp-stream,
3. ProtoOutputStream.java
4. ProtoOutputStream.cpp
5. Privacy.h (GetFieldId)
6. StatsLog to generate field id (type << 32 + field number)
Therefore use the current value in descriptor.h seems reasonable unless
they change that, very very unlikely, they probably will just add new
types, and deprect the existing ones like Group.
Test: test output of dumpsys proto
Change-Id: I6e150ab427851dd3b5dd55d3b273deeed7a0963c
Test: This merge conflict was automatically resolved by meld.
The automatic resolution of the same merge conflict by meld
from cherrypicking this CL into internal-master has passed
Treehugger (and was already submitted).
Exempt-From-Owner-Approval: Resolving merge conflicts with no deltas
Change-Id: I61f15aeb79c1ad26cc7c51be2af59ecb7b672a7b
android.util is the only package shared between libcore and
framework, with only the Mutable* classes living in libcore.
This CL topic moves most of these classes to framework.
After this CL topic, only MutableInt and MutableLong remain
in libcore. This prevents future libcore dependencies on
android.util; it is a first step towards removing the package
overlap between libcore and framework.
Test: Treehugger
Bug: 67901714
Change-Id: Id466181cb0db747da17f38ddb0b99c3e522add16
This is a pure refactoring with no a behavior change other than
that these calls now go through android.system.Os, which immediately
delegates to Libcore.os.
This is a first step towards separating framework (via
android.system.Os) vs. libcore (via Libcore.os) clients of these
low level APIs. Separating these is a prerequisite towards moving
the API parts of android.system into framework, and moving the
rest into a different package in libcore.
Test: Treehugger
Bug: 67901714
Change-Id: Ifd8349ec5416e5693f40dba48fdf2bef651b7d81
Merged-In: Ifd8349ec5416e5693f40dba48fdf2bef651b7d81
This is a pure refactoring with no a behavior change other than
that these calls now go through android.system.Os, which immediately
delegates to Libcore.os.
This is a first step towards separating framework (via
android.system.Os) vs. libcore (via Libcore.os) clients of these
low level APIs. Separating these is a prerequisite towards moving
the API parts of android.system into framework, and moving the
rest into a different package in libcore.
Test: Treehugger
Bug: 67901714
Change-Id: Ifd8349ec5416e5693f40dba48fdf2bef651b7d81
Both native and java bindings.
TODOs:
- Finish WorkSources.
- Clean up the package names for the protos.
- Put the protos in a more suitable location.
Test: stats-log-api-gen-test
Change-Id: Idf4022225e2be05106dbcf7de8e97a3337fc63e2
To avoid issues with late initialization, let the holder be
initialized in the zygote.
(cherry picked from commit 61a3e8c23a)
Bug: 65927416
Test: m
Merged-In: I6f454df46d4c64d295e1f2510793d5087b74fb74
Change-Id: I6f454df46d4c64d295e1f2510793d5087b74fb74
To avoid issues with late initialization, let the holder be
initialized in the zygote.
Bug: 65927416
Test: m
Change-Id: I6f454df46d4c64d295e1f2510793d5087b74fb74
This is aimed at making MagnificationGestureHandler easier to understand
and reason about
Test: provided unit test + manual magnification test
Change-Id: I958ef0bdd2e6f857a2fab24962b1a06480685732
In several places we compute the sha256 of the app's signing certificate
(instant cookie storage, backup account permission grants, static shared
lib matching). It is possible that an app is singed with multiple certs
which unfortunately can appear in a random order. We were using only the
first certificate to compute the hash which may be problematic for apps
signed with multiple certs which are later reordered. If an app update's
certs are reordered for cookie storage the app would not be able to
access the cookie, for account grants the app would not get the grant,
and for shared libs the app would fail to install due to a missing lib.
Test: all cookie CTS tests pass
all static shared lib CTS tests pass
added test that cookie data not lost on sha256 computation change
added test that lib install works when specifying
multiple certs
bug:64270295
Change-Id: Ib6b55f25da735ff5c2762faf6e9b5888e749041d
Email auto linking used to accept either a single char or more than 2
chars in the local part. Updated the regular expression to accept 1 or
more chars.
Test: added test to cts.LinkifyTest
Test: bit -t CtsTextTestCases:android.text.util.cts.LinkifyTest
Test: bit -t FrameworksCoreTests:android.util.PatternsTest
Test: bit -t FrameworksCoreTests:android.text.util.LinkifyTest
Test: bit -t CtsWidgetTestCases:android.widget.cts.TextViewTest
Bug: 64467661
Change-Id: I4e28a344ff1bc50da353b9490eaaec99a751bffb
(cherry picked from commit e17c5b478e)
Renamed BootTimingsTraceLog to TimingsTraceLog. It is now used for
boot and shutdown logging.
Added measurements for main stages of shutdown in the system server:
ShutdownTiming: SendShutdownBroadcast took to complete: 734ms
ShutdownTiming: ShutdownActivityManager took to complete: 203ms
ShutdownTiming: ShutdownPackageManager took to complete: 17ms
ShutdownTiming: ShutdownBt took to complete: 533ms
ShutdownTiming: ShutdownRadio took to complete: 534ms
ShutdownTiming: ShutdownNfc took to complete: 1536ms
ShutdownTiming: ShutdownRadios took to complete: 1538ms
ShutdownTiming: ShutdownStorageManager took to complete: 906ms
ShutdownTiming: SystemServerShutdown took to complete: 3918ms
Bug: 64569080
Test: shutdown/reboot and check logs
Change-Id: I636c045852cd1ed6be1c58af6608f70e95756389
Devices routinely boot in a state where the RTC is wildly incorrect
in the past (2009, 1999, or even at Unix epoch zero). When we have
persistent jobs to be scheduled at boot, this presents a problem: when
should those jobs run, given that our idea of "now" is incorrect?
The previous implementation fell back to rescheduling these jobs
"from scratch" in this situation, as though they were newly-introduced,
but this turns out to have some emergent pathologies when the jobs
were intended to become runnable after long initial delays: the
rescheduling behavior could wind up starving jobs out entirely,
never running them regardless of how much real uptime the device
had, given the "wrong" pattern of reboots.
We now preserve the original nominal schedule, but recognize when we
have booted in a pathological situation, and correct the schedule for
these jobs when the system clock becomes sensible.
Bug 63817592
Test: JobScheduler test suite plus manual bogus-boot-time repro
Change-Id: Ia36fc5298b68db74e4e07e973b68e68e66206b43
