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
Extend the installd profile interface to take the profile name as
argument. This shifts the responsibility for choosing the names of
profiles for primary apks completely to PackageManager. Each of the
application code paths will get an unique profile name based on their
split name.
All the profile operations will now work on a specific profile name rather
than assuming a default global name.
Also, move dumpProfiles and clearProfiles functionality to the
ArtManagerService so that we can re-use profileName computations easier.
Test: manual (dexopt apps, merge profiles, clear profiles)
gts GtsAndroidRuntimeManagerHostTestCases
Bug: 30934496
Change-Id: Ie65d45eed7de0844edf4b7af918d7eaa74ec1f2c
Allows a uid that uploads a statsd config to additionally
register a BroadcastSubscriber with statsd. If statsd
detects an anomaly (according to the config's Alert),
statsd can inform a BroadcastSubscriber provided in the config.
The config uses a subscriberId (just an int) to identify the
BroadcastSubscriber. It then uses StatsManager.setBroadcastSubscriber
to associate that subscriberId with a given PendingIntent.
Then, when the anomaly is detected, statsd sends a broadcast
using that PendingIntent, alerting whoever was specified by
the config/setBroadcastSubscriber.
Bug: 70356901
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.alert.BroadcastSubscriberTests
Change-Id: I4d9ea9a6c8a85e61fadfd99c1513c55abbadd5e9
Now requires permission if targeting P.
Note that this is a separate permission from the existing one
that is required for instant apps to use foreground services. The
reason for this is that their semantics are different (the instant
apps permission is associated with an app op for control over what
the app is allowed, while the regular app permission is just a
normal permission that is always granted and only there for
auditing of apps), and there are probably going to be cases where
a developer will want to use a foreground service in the full
version of their app but not as an instant app.
Bug: 72116995
Test: atest CtsAppTestCases
Change-Id: If5a79e7ed5ab9e0edc77410315eb4d2df8ac850b
Currently the slider represents a gamma adjustment to the brightness
curve when auto brightness is enabled and the absolute screen brightness
when it's not. This is a fairly confusing behavior to most people, so
this consolidates them to a single behavior: the slider always
represents the current brightness and auto-brightness will automatically
adjust it.
This also moves a bunch of the brightness methods from PowerManager over
to DisplayManager, since it's really the DisplayPowerController that's
responsible for determining and setting the display brightness.
Test: atest com.android.server.display.BrightnessMappingStrategyTest
Bug: 69406898
Change-Id: I73b5982809a94cd50d563426a72d7965e923c994
The change is slightly more involved than similar changes in this area
because GnssLocationProvider doesn't treat WorkSources as opaque, it
tries to compute diffs between them (using the only call to
WorkSource.setReturningDiffs in the platform). It also uses WorkSources
tags to make calls to AppOps.
Some of this can be improved generally, but this change is narrower in
scope and only tries to improve battery related attribution.
Test: BatteryStatsTests
Bug: 62390666
Change-Id: Ie28bc91d74d3a0c3b6aaef6ba7c59fc58633efb1
shipping API version:
For devices shipped before Android P nothing changes, data
is stored under /data/system/users/<user-id>/fpdata/...
Devices shipped from now on will instead store
fingerprint data under /data/vendor_de/<user-id>/fpdata.
Support for /data/vendor_de and /data/vendor_ce has been added to vold.
Bug: 36997597
Change-Id: Ib500ede221db6a3cb18595162c412c52dce5c931
Test: manually
Turned out !UserHandle.isApp() doesn't mean "is system" because of isolated UIDs.
Bug: 72174012
Test: atest $ANDROID_BUILD_TOP/frameworks/base/services/tests/servicestests/src/com/android/server/ForceAppStandbyTrackerTest.java
Change-Id: Ibf6175d550ecc74677877c74db2473bf3f30132d
Fixes: b/69307379
Test: Ensure attached bug no longer reproduces.
Ensure magnification using a11y button otherwise works as expected
Change-Id: Ie4e966eb8cfcc9d3f37ae7252b951381ef1fb7c7
