Retrieve the number of freed bytes from PM and store it in
GlobalLevelState when a package is globally hibernated. Reset the value
when it gets unhibernated and write it to disk to persist across device
reboot.
Bug: 188819665
Test: atest AppHibernationServiceTest
Change-Id: I187ec803776cc76c77a660e1ba2f72c2e77765f9
This is to allow us to verify DisplayArea policy in CTS
Bug: 175840704
Test: atest CtsWindowManagerDeviceTestCases:DisplayAreaTests
Change-Id: I60d9fe1ee68b38e2812feb9a818f9d4a67edc694
Details in design doc go/pip-and-back
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/g8lbXnC8ln0t54ARxfPELo
Bug: 184758170
Test: ensure back stack works for Netflix, see video
Test: atest PinnedStackTests
Test: atest RootWindowContainerTests
Change-Id: I9e2f8d0d50dd107ff30fd7afe6273d8347aac803
Clients can register for listening to changes in procstates and if
they are only interested in knowing if the procstate crosses a certain
threshold, they can specify a "cutpoint" and they will only get
a callback if the procstate crosses that "cutpoint" but clients cannot
use this if they are also interested in changes in capabilities. So,
add a way for clients to use the "cutpoint" facility and also listen
to changes in capabilities.
Bug: 177641226
Test: atest services/tests/servicestests/src/com/android/server/am/ActivityManagerServiceTest.java
Test: atest services/tests/servicestests/src/com/android/server/am/UidObserverControllerTest.java
Test: atest ./tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I1198e602ca81382975500b10f930dacfd16919e3
DisplayGroups may now timeout individually from one another.
Bug: 175764389
Test: manual - check timeout behavior on multi-DisplayGroup device
Change-Id: I842939d3048e1eb16790a131c83e1b2ac1ac4f47
Create a new parcelable RampSegment and introduce
VibrationEffect.startWaveform() method that returns a
WaveformBuilder that allows creating step/ramp waveforms that
changes amplitude and frequency of the effect.
Implementations of VibrationThread and InputManagerService for now just
ignore the new segments and keep existing behavior.
Bug: 167947076
Test: VibrationEffectTest
Change-Id: Ibac895b63196e779457efc297f1f5497a7814ae9
Create a new parcelable VibrationEffectSegment in the new package
android.os.vibrator, together with three concrete implementations for
the segment types: step, prebaked and primitive.
Remove all implementations of VibrationEffect to allow composition of
any effects, represented now by the concrete type VibrationEffect that
holds a list of segments.
Bug: 167947076
Test: VibrationEffectTest
Change-Id: I79c99e29f436ed77558af764f55633bb4636e034
On devices with multiple sensors, lockout should be reset whenever
any strong sensor authenticates.
Bug: 163058911
Test: atest CtsBiometricsTestCases
Change-Id: I4bcdc0279cdaa444e59cf0fac6645d9a67e7d11d
Created a new metrics called mLastTimeComponentUsed in UsageStats.
It is persisted and loaded as other metrics.
Bug: 175829712
Test: core/tests/coretests/src/android/app/usage/UsageStatsTest
Test: cts/UsageStatsTest
Test: UsageStatsDatabaseTest
Test: UsageStatsServiceTest
Test: UsageStatsPersistenceTest
Change-Id: I10cf5c40cf5955246a6a04e96ac0352b4ed29acd
In addition, rename in_size_compat_mode in WindowState proto to
has_compat_scale for clarity.
Test: atest CtsWindowManagerDeviceTestCases:CompatScaleTests
Bug: 181878559
Change-Id: I0d6844be3f138fdc16a22497346e789d93af7396
callingUid is the UID of the app who added the temp-allowlist entry, it
needs to be passed from AMS to DeviceIdleController.
The callingUid will go into Westworld metric
ForegroundServiceStateChanged.
Bug: 171305836
Test: Observe the callingUid while grepping for "tempAllowListReason" in adb logcat, it should be a non-zero value.
BYPASS_INCLUSIVE_LANGUAGE_REASON=Existing public API.
Change-Id: I19f5cf8f72d5fbfb3fd6caefe6978e75d4c1a801
Data stored to disk are extracted into an incident report for timeseries
visualization which shows walltime and may span multiple reboot sessions
so storing walltime is better suited than relative time since device boot.
Bug: 179712445
Tests: atest FrameworksServicesTests:PowerStatsServiceTest
Signed-off-by: Thierry Strudel <tstrudel@google.com>
Change-Id: I5ae8e2fe22f1ab9ea960e5be8fef4e9fb1cc10f0
Since unifying of hierarchy, the configuration of Activity and
windows are updated together. There won't be temporal inconsistent
bounds any more.
History commit: 0429f35
Also remove the update of override config even there are no changes.
Because performDisplayOverrideConfigUpdate was changed to not always
call setNewDisplayOverrideConfiguration for years. So the original
purpose of the change is gone.
History commit: c646717
Bug: 159103089
Bug: 163976519
Test: CtsWindowManagerDeviceTestCases
Change-Id: Ie5711ab4bcff7bf572cf6410df9bc8aaa5688e11
There are four ways a package can be temp allowlisted:
1. Calling BroadcastOptions#setTemporaryAppWhitelistDuration() to
allowlist a BroadcastReceiver, this is a SystemApi.
2. Calling ActivityManagerService#setPendingIntentWhitelistDuration()
to allowlist a PendingIntent, this is not an API, it is an internal method.
3. Calling PowerWhitelistManager#whitelistAppTemporarily() to allowlist
a package, this is a SystemApi.
4. DeviceIdleController.addPowerSaveTempWhitelistApp(), this is an
internal method.
Also the package can be permanently allowlsited in
ActivityManagerService#mDeviceIdleExceptIdleAllowlist.
Move the BG-FGS-launch reasonCode from ActiveService.java to
PowerWhitelistManager.java. Define a list of temp allowlist reasonCode
in addition to the BG-FGS-launch reasonCode. The reasonCode is passed
around in DeviceIdleController and ActivityManagerService, it will be
used in statsd FGS metric.
At FGS start, check all above allowlists and record the reasonCode/reason/duration in
ServiceRecord#mInfoTempAllowListReason field.
If mInfoTempAllowListReason is not null, log the reasonCode/reason/duration in "Background started FGS" log
message, with key "tempAllowListReason".
Bug: 171305836
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java
Reboot device, observe all "tempAllowListReason" listed above in logcat.
BYPASS_INCLUSIVE_LANGUAGE_REASON=existing APIs
Change-Id: Ieb52d95aae3258817a67734c093cb12fc78a81fd
CTS-Coverage-Bug: 181160445
- Move VibratorManagerService to com.android.server.vibrator and make
all other classes there package-private;
- Add some missing haptics-related files to OWNERS files;
- Remove some unused methods;
- Delegate CombinedVibrationEffect to input devices, instead of only
delegating VibrationEffect effects;
- Move vibratorservice.proto to vibrator folder and add missing fields;
- Mark large VibrationThread tests with @LargeTest;
Fix: 131311651
Fix: 177805090
Test: VibratorManagerServiceTest
Change-Id: Ic747190b70b2f45ac7671eb01f8f05cf66d3a96c
Persist hibernation states to disk. This CL persists the user-level
and global hibernation states to disk.
Bug: 175829330
Test: atest AppHibernationServiceTest
Test: atest HibernationStateDiskStoreTest
Change-Id: If58d648d720bed1693b9346c4d0e85074daec931
This flag was only introduced to allow teamfood testing of the change
to use background activity launch blocking instead of delaying app
launches after app switching protection is engaged. The flag has been
on everywhere for 2 weeks (ag/176961146) without problems and is no
longer needed.
This CL went in three stages:
- Change getBalAppSwitchesProtectionEnabled() in
ActivityTaskManagerService to always return true.
- Inline the function (and selected others) into call sites and then
eliminate the resulting dead code - done as a serious of automatic
refactorings to minimise the risk of human error.
- Delete unit tests for code that no longer exists.
Apart from deleting the use of the flag I believe this CL is a pure
refactoring with no new behavior changes.
The end result is we eliminate quite a lot of code - especially
PendingActivityLaunch and all uses of it.
Test: atest BackgroundActivityLauncherTest
Test: atest ActivityStarterTests (both of them)
Test: manual
Bug: 176961146
Bug: 159433730
Change-Id: I01625843f67b00e5901833cff99aec16c1287a0c
Merged-In: I01625843f67b00e5901833cff99aec16c1287a0c
Exempt-From-Owner-Approval: proto change approved on main branch
(cherry picked from commit 5897ecc699)
The root task was created with null intent, but the intent,
resize mode and other information were updated from child tasks,
which sets the split-screen-secondary root task to unresizeable.
Bug: 170801863
Test: presubmit
Change-Id: I57458c05c4c579d78894869c0590788d17912bc3
These changes have to be in this CL together because:
- Code in service-permission depends on IRoleManager in
framework-permission, so the APIs in framework-permission and the code
in service-permission need to be moved together.
- The changes to service-permission build rules doesn't make sense
without the code moved in, so they have to be together as well.
Other details:
- framework-annotations: Several annotations are added into
framework-annoatations. Since the discussion with API council seems to
allow user IDs in system server in-process APIs, @UserIdInt and
@AppIdInt is added. @MainThread and @AnyThread is added since
@WorkerThread is already added. @CallSuper is added since @CheckResult
is also already added and they are similar in terms of category of
functionality.
- framework-permission-s-shared-srcs: 3 classes (and 2 AIDL files)
from framework is copied as shared source files and jarjared for
framework-permission, and an additional 3 is added for
service-permission as service-permission-shared-srcs. Similar to
framework-wifi and service-wifi, the 3 classes in framework-permission
is also available to service-permission by the stub library
framework-permission-pre-jarjar, and the other 3 classes used only for
service-permission is included separately to minimize our impact on
classes loaded into boot classpath. framework-permission and
service-permission shares the same jarjar rules to make sure the
classes remain available, and for the same reason framework-permission
cannot be shrank during any optimization.
- framework-permission-s-shared: A java_library target for
framework-permission-shared-srcs is created to make sure that the
public classes won't be counted as APIs, as it would be if directly
included as srcs for framework-permission
java_sdk_library. service-permission-shared is the same thing for
service-permission.
- framework-permission-s: A new java_sdk_library target created to be
loaded into bootclasspath by Android S+.
- Dumpsys Protobuf: The dumpsys protobuf
file (rolemanagerservice.proto) is moved into the module, and both the
platform (incident.proto) and the module uses protoc-gen-javastream to
generate the Java classes from it. This should be fine since it's a
"source level inclusion", and we jarjar the generated classes in our
module to avoid conflict with platform copies.
Bug: 158736025
Test: manual
Test: device boots, default apps can be changed successfully.
Change-Id: I1914774f631e51d0c587a7e527a1c9bc05ee1595
1) Adds biometrics.proto definition for BaseClientMonitor subtypes
2) Adds BiometricScheduler proto dump
When dumping the scheduler, the caller may request for the recent
operation queue to be cleared after dumping or not.
Note that we don't need BiometricScheduler.Operation#STATE_*
in the dump, since (for now) we just want to know what operations
have been run.
We can always add additional state, success/failure, etc in the
future if needed.
Bug: 159667191
Test: atest com.android.server.biometrics
Test: atest CtsBiometricsTestCases
Change-Id: I7d2350f00aaeef03ab7d74013b476af053240320
1. add a "type" parameter to AMS.updateDeviceIdleTempWhitelist() which is
called by DeviceIdleController.
2. The default temp allowlist type is TEMPORARY_WHITELIST_TYPE_FOREGROUND_SERVICE_ALLOWED
which allows BG-FGS launch.
3. AMS.tempWhitelistUidLocked() already has a type parameter. Other API
to add temp allowlist can also add type parameter other than the
default.
Bug: 175244558.
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java
Change-Id: Ib42c445c15966bd260964782a7254ed2a7ffa405
