- wireless charging animation plays on aod + lockscreen
- timing changes on animation based on design spec
- charging feedback only given if phone is not just booted
Test: manual
Bug: 67598445
Change-Id: I009ff6016141bcdfe9f0392bb9a1c220ea88dfe5
Previously, statsd would inform interested listeners that it's time
to collect data via a protected broadcast. However, the preferred
solution is to pass a PendingIntent via a separate setter. Whenever
statsd wants the listener to call getData, StatsCompanionService
will trigger the pending intent.
Test: Tested in marlin-eng that functionality works as expected with
dogfood app.
Bug: 72562867
Change-Id: Ibcfcd5072a1a78947f8a7cbcd0bc429b54351da3
A flag in historian is added to identify time periods where the
cellular radio is transmitting at the highest power level.
BUG:38354995
Change-Id: Ib89a505636c1d5aa66f8c19690742dde9d40fe61
transaction start: this is interface dependent
flags: part of kernel ABI, unused here
Bug: 72877008
Test: N/A
Change-Id: Ic0f268cd0483edaf3cea7de90b5743e84292f427
Use existing API instead of creating new method.
Bug: 64140119
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.MixedDeviceOwnerTest#testPrintingPolicy
Change-Id: I9ff94f4d73824e7bf9aedbb64811ad60fccf9779
- Adds a new DEFAULT priority for services which is treated the same as NORMAL priority but dumpsys does not send "--dump-priority" arguments to the service.
Bug: 27429130
Test: Manually generate bugrepot (default version) and check for any issues
Test: Load bugreport on ABT
Test: mmm -j56 frameworks/native/cmds/dumpstate && \
adb shell /data/nativetest64/dumpstate_smoke_test/dumpstate_smoke_test && \
printf "\n\n#### ALL TESTS PASSED ####\n"
Change-Id: Ia90ae16d56d0144e679cf39ebfbf4473dd21f167
The majority of Manager-style classes already use Context.getUserId()
when making calls into the OS, so clean up the remaining callers to
unify behind this strategy.
This gives @SystemApi developers a nice clean interface to interact
across user boundaries, instead of manually adding "AsUser" or
"ForUser" method variants, which would quickly become unsustainable.
Test: builds, boots
Bug: 72863821
Exempt-From-Owner-Approval: trivial changes
Change-Id: Ib772ec4438e57a2ad4950821b9432f9842998451
Also extend API to accept a "count" argument of exactly how many
bytes to copy, and return the actual number of copied bytes.
Improve docs.
Test: bit FrameworksCoreTests:android.os.FileUtilsTest
Test: vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/FileUtilsBenchmark.java
Bug: 71932978
Change-Id: I8d255e4f97462838c02a8ecb6d2d221188c4eff0
This can easily be reverted if we uncover any trouble.
Test: bit FrameworksCoreTests:android.os.FileUtilsTest
Test: vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/FileUtilsBenchmark.java
Bug: 71932978
Change-Id: Iac97c342948074c4f373e5f2ae70e563b308a11e
There are several places across the OS where Java code is simply
copying data between two points, which requires bringing that data
out into userspace before going back into the kernel. (That's pretty
lame.) The patches for the recent Meltdown/Spectre security issues
have made this overhead even worse, so it's finally time to move this
copying directly into the kernel.
This change adds a couple new FileUtils.copy() methods which inspect
the given streams/FDs, and attempt to do as much optimization as
possible before falling back to a slower userspace-based copy.
Benchmarks are showing typical improvements of 44% for 32KB files,
50% for 32MB files, and 35% for 32MB pipes.
Plenty of tests are included, and there's a simple kill-switch that
can be used to enable/disable the feature if it starts causing any
trouble. (A future CL will enable the optimizations.)
Test: bit FrameworksCoreTests:android.os.FileUtilsTest
Test: vogar --mode app_process --benchmark frameworks/base/core/tests/benchmarks/src/android/os/FileUtilsBenchmark.java
Bug: 71932978
Change-Id: I52518d529da5d961610998b9f61399064d8025cd
... and print in dumpsys power.
Bug: 72229630
Test: manual test with dumpsys power, etc
Test: atest $ANDROID_BUILD_TOP/frameworks/base/services/tests/servicestests/src/com/android/server/power/batterysaver/BatterySavingStatsTest.java
Change-Id: I43949129ff03c1e0b0fa3aa603e0678b728538ee
Tuned rates that we collect PSS, to reduce how much we do
that heavy operation. Added a new way to determine
whether a process has changed to a state for the
"first" time -- now this is when it has gone to that
state for the first time since it was in a lower state.
This will reduce the amount of time we consider a
process to be first to only when it has previously
gone into a higher state than it had before.
Keep track of more fine-grained information about why we
collect a PSS sample (not just internal, but for a single
process, all processes because of a mem state change, all
processes because of a poll).
Started collecting RSS in various places, so we can start
looking at that w.r.t. PSS and see about transitioning to
it is a new primary metric.
Added logging for many of the places where the system
writes its configuration files, so we can more easily
see any bad behavior going on in those areas.
Added some currently disabled code to read smaps directly
instead of using fgets(). Probably won't help, but want
tot test.
Bug: 70859548
Test: atest CtsAppTestCases
Change-Id: I400dba0f3ae9c024df51c946cfa592561028b598
Status: Ready for review.
Note: This is a Javadoc only change.
Changes:
* Replaced "guide/developing/tools/traceview.html/ with
"studio/profile/traceview.html"
Test: * Build with "make ds-docs -j16"
* Staged content at go/dac-stage/reference/android/os/Debug.html
* Ran linkchecker against staged content
Bug: 37640935
Change-Id: I0446c44a78ae7d1d9193e2fe08e059cdc90cac7a
Created an enums.proto that contains the device idle modes,
which is referenced by batterystats.
Note that, currently, batterystats is the origin of these
constants in the java code, and I have kept that as is.
Thus, batterystats references the enum.
Nevertheless, because the actual control of device idle
mode is DeviceIdleController.java, where these constants
will likely one day be moved, I have put the constants
in server/enums.proto (since DeviceIdleController is
in server, not os like BatteryStats).
Bug: 69478930
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.HostAtomTests#testDeviceIdleModeStateChangedAtom
Change-Id: I6e66801ae8256aab423067f9a4b852a194564a8d
Context:
Updated the API according to API council feedback. Marked it as
@Removed and keep it for a while for Launcher. But now Launcher
prebuilt is updated, we are safe to remove it.
Test: Build
BUG: 71818127
Change-Id: I33fec12addf7031bfbcd86bce9e636c31d0ea4d3
A couple methods of Java classes which became SystemApis
but were used are still @hide.
Bug: 72480743
Test: hidl_test_java
Change-Id: I0cb82384932ab1758fa7576b2125825c48a4a6c9
For frameworks constants that don't have intrinsic meaning (i.e. their actual
value and order don't matter), so that it is unlikely that their values
will be changed:
This cl introduces proto enums representing some constants found in
the Android codebase, and connects the two.
By using the Proto enum as the source-of-truth, it means that Java and
proto can be kept in sync. Otherwise, when the Java frameworks code
changes, it silently breaks the protos from working properly, since the enums
are wrong. By having the Java code reference the proto enums, it ensures
that everything is in sync. The values of the constants are unchanged.
But future changes to these constants will need to be done in the proto
file, which the Java file merely references.
The protos are necessary for incidentd and statsd and, in the future,
possibly dumpsys. In this way, the logging mechanism is much less likely
to get broken when new constants are added, and we can be ensured that
the logging accurately reflects the underlying codebase.
Bug: 69478930
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases
Test: cts-tradefed run cts-dev -m CtsIncidentHostTestCases
Change-Id: If79032c34b2799db1e3e70cb47b1312fd72092b9
Renaming this method with a semantic meaning which
better explains its purpose without caring about
its implementation details.
Bug: 72480743
Test: hidl_test_java
Change-Id: I4b0577b3f61180ecfd66ae146973fa5cc2a3b244
Controller by a feature flag, which this change also introduces.
Bug: 62390666
Bug: 70892390
Test: manual, via JobSchedulerTestApp
Test: CtsJobSchedulerTestCases
Change-Id: Ic7dfb7861f7987a1b6eeb4cf3851193e9ad7da84
This CL will support the followings.
- installing a RRO package for framework from /product/overlay
- installing apps from /product/app
- installing priv-apps from /product/priv-app
- installing permissions from
/product/etc/[default-permissions|permissions|sysconfig]
Bug: 64195575
Test: `mm` under frameworks/base/tests/[libs|privapp]-permissions
adb sync && adb reboot
adb shell cmd package list libraries
=> confirmed com.android.test.libs.product library
adb shell cmd package dump \
com.android.framework.permission.privapp.tests.product
=> confirmed that the package is a priv-app
And I moved vendor/overlay/framework-res__auto_generated_rro.apk into
system/product/overlay/ on sailfish, and I confirmed that the RRO was
installed properly.
Change-Id: I16175933cebd9ec665d190cc5d564b5414a91827
This patch adds two distinct vibration control settings: one for
notifications and ringtones, and one for haptic feedback. Since we don't
always have the exact intent of a given vibration, VibratorService will
do its best to classify each VibrationEffect into one of these two
categories and then scale the vibration accordingly based on the
intensity setting.
Bug: 64185329
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.VibratorTest
cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.VibrationEffectTest
Change-Id: If16237f4782281aaab33e4a0f55c29f1a30ac493
