To make sure that the proto definitions stay in sync across branches,
we merge them to master even though the logic for this does not exist
here.
Bug: 111062294
Test: make droid
Change-Id: I2521cfde6cdc04644666eff753226d6d008d378f
In the Service layer, this change is pretty much the same as ag/4340638.
FingerprintService already extends BiometricService which contains all
of the common code. FaceService now does the same after this change.
Updated the Manager layer to use the infrastructure added in P, namely
- Private APIs for BiometricPrompt
- Removed FaceManager#CryptoObject, use biometrics/CryptoObject directly
- Few other BiometricAuthenticator things
Bug: 110387294
Test: enrolling FP still works
Test: removing FP still works
Test: changing FP name persists across reboots
Test: enumerating still works (extra framework fp, extra hw fp)
Test: keyguard still receives lockout reset callbacks
Change-Id: I2195b08e28d024a120df56fe87b0dd4f9b96505a
This would be use to determine the right activity state during CTS
test for products that have windowSwipeToDismiss set.
Also, dump ActivityRecord.fullscreen to proto for the same reason.
Bug: 76207986
Bug: 79167358
Test: atest CtsActivityManagerDeviceTestCases:ActivityLifecycleTests
Test: atest CtsActivityManagerDeviceTestCases:ActivityManagerAssistantStackTests
Change-Id: Iadc088e9129be088b8a083ebbafd8d20fe26b673
Due to earlier refactorings, now allow-in-power-save-except-idle apps
are getting the flag ALLOW_WHILE_IDLE_UNRESTRICTED, which should not
happen. Restricting to user whitelisted app ids as was the case in O.
Test: atest com.android.server.AppStateTrackerTest
atest android.alarmmanager.cts.AppStandbyTests
Also, manually,
adb shell cmd deviceidle whitelist +<package-name>
Then verify the app id appears in App state tracker dump in
adb shell dumpsys alarm
Bug: 74773710
Change-Id: I6fdce33446e1374c6672ce98769aa8b5844effa9
Note: It is currently only safe to renumber the fields because we have
not started using them yet.
* animationadapter: added in http://ag/3709688, but was not following
the indentation policy or the unit naming policy. The durations that
have documentation in
frameworks/base/services/core/java/com/android/server/wm/ state that
they're in milliseconds. These durations didn't have documentation, but
I'm assuming they're in the same units.
* batterystats: was not following the indentation policy
* jobscheduler: AppIdleController was removed in http://ag/3699210 and
the proto was only partially updated
* powermanagerservice: BatterySaverStateMachineProto added in
http://ag/3763026 but was not privacy tagged and the indentation was off
* surfaceanimator: was not following the indentation policy
* remote_animation_target: was not following the indentation policy
* others: weren't following the indentation policy
Bug: 74975371
Test: flash device and run 'test CtsIncidentHostTestCases'
Change-Id: Id012f4690b1d58816fef096523e1a0ea2bccadb0
- When the PIP is dismissed offscreen, the pinned stack can receive
onConfigurationChanged (when its windowing mode is set back to
fullscreen) after the stack is hidden. In this case, the saved snap
fraction will be incorrect leading to a wrong animation on the next
PiP animation. We don't expect the snap fraction to be saved in this
case since the user is not expanding the PiP.
- Also add the animating-bounds state to the proto for use in the cts
tests.
Bug: 73775460
Test: atest CtsActivityManagerDeviceTestCases:ActivityManagerPinnedStackTests
Change-Id: I30398ecf11de045d11a95282b8203e4d2d344ae9
None of the existing animation really work with transitions in
which a translucent app is appearing/disappearing. Add a separate
animation for that and change all existing transitions to these
new transition types in case we detect that only translucent
activities are appearing/disappearing.
Test: Sharesheet animations
Test: go/wm-smoke
Change-Id: Iffe57b7664dddf647d723c91d115ade60c12ad33
Fixes: 37953606
Fixes: 70730519
Fixes: 72649981
Fixes: 72686618
- When battery saver is enabled manually (i.e. via PM.setPowerSaveMode()),
it'll stick, and we'll re-enable battery saver even after a reboot
or a charge.
- Extracted all battery saver state transition logic into a separate
class.
Fix: 75033216
Bug: 74120126
Test: Manual test with "dumpsys battery set ...."
Test: atest $ANDROID_BUILD_TOP/frameworks/base/services/tests/servicestests/src/com/android/server/power/batterysaver/BatterySaverStateMachineTest.java
Change-Id: If020cd48f341b339783fe09dd35bc7199e737a52
Test: dumpsys power
Test: incident_report power
Test: atest CtsBatterySavingTestCases
a failure since it is used to signal EOF.
Additionally tag this message as auto so user_id won't become explicit.
Bug: 75017304
Test: atest incidentd_test
Change-Id: I151bab5a72a532e7c9f54ae0686561001730bdeb
1. Remove unnecessary hex_hashs.
2. Make intent extras LOCAL
3. Make mnc EXPLICIT
4. Make diskstats error AUTO since it is only IOException.
It is safe to modify proto numbers since they are not used yet.
Bug: 74837756
Test: flash the changes and call incident -d, also updated go/irpf
Change-Id: Idee0e927515e737c9a42a1dc29cb3c05e6d91ca9
Along the way we turn down the "app idle" tracking in the
jbo scheduler: it's now redundant with standby bookkeeping,
and was muddying the waters.
Bug: 74017233
Test: atest CtsJobSchedulerTestCases
Change-Id: I3220e6ef97f153b3f718e267a0dc4fbd3b926316
When Sidekick is controlling the display, any draw wake lock can cause a
sequence of endDisplayControl/setDisplayPowerState/beginDisplayControl
twice, because of DOZE_SUSPEND -> DOZE -> DOZE_SUSPEND transitions.
We can avoid that by telling power manager that display is controlled by
Sidekick, and draw wake locks shouldn't change the display power state.
Bug: 70574675
Test: build, flash Sardine, run Stopwatch, observe logcat
Change-Id: Ie4dac76606e45f0d3b62bc5890841f4f24d454d7
Ignoring Wallpaper Offsets, the WindowStateAnimator is now
always positioned at (0,0), so we don't need to calculate or store this. For
Wallpaper Offsets we can manipulate the position of the WindowStateAnimator surface
directly. This seems to be a nice level to model the concept of scrolling a buffer
larger than the "Window" to which it is assigned.
Everything on top of WSA can ignore the offsets by only interacting with the WS and above.
Seamless rotation may mess with the position so we need to be sure to reset it to 0,0.
Test: Manual. go/wm-smoke
Bug: 72038766
Change-Id: I961d190d1f1ee71faaede095617092a0ad32e16f
All the other dumpsys use XXXServiceDumpProto or XXXDumpProto other
than ones modified here.
The name convention is if the proto describes the top level output of dumpsys,
it should contain `Dump`. This makes the consumer easy to understand the proto
is from dumpsys of a certain service, not data structure of
the service, e.g. WindowManagerServiceProto ->
WindowManagerServiceDumpProto.
Another change here is ActivityManagerService has 4 sub dump protos, so
the top level for each one should be a DumpProto instead of its internal
data struture, e.g. ActivityStackSupervisorProto will just be a field of
AmServiceDumpActivitiesProto, which `dumpsys --proto activities` used to
output ActivityStackSupervisorProto directly.
Bug: 72474563
Test: manual and CTS tests
Change-Id: I1e1ac032d27591083bb5b1b19aac82804215472a
- Update the minimized state when docking an app from home to ensure that
the animation of the docked task goes to the right bounds
- Temporarily block the invocation of the old recents activity when showing
recents as a part of setting the windowing mode of another task (this is
fine right now because quickstep only allows docking via the UI and not
from the nav bar while another task is open).
- Add proto field so we can determine whether to check the recents activity
from the split screen CTS tests
- Also fix issue with invisible docked task due to wrong bounds calculated
due to launcher not notifying the divider of the first docked frame
Bug: 73118672
Test: go/wm-smoke
Test: atest CtsActivityManagerDeviceTestCases:ActivityManagerSplitScreenTests
Test: atest CtsActivityManagerDeviceTestCases:ActivityManagerTransitionSelectionTests
Change-Id: Ib1208501c311de009a9e706103134865c521cb63
Avoid overflow across the end of time when calculating window endpoints, and
clamp recurrence periods at something workable but too long to be plausible.
Bug: 70536740
Bug: 72658919
Test: manual
Test: atest CtsAppTestCases:AlarmManagerTest
Change-Id: Icb7a571802b722499df09833522d1d3f28607621
We keep the sane default values of 50% through a job window for
delaying on congested networks and promoting prefetch jobs, but now
allow experiments to override these values.
There's only ever one of each controller, so just create it tied to
the JobSchedulerService that owns it. (People that need hooks for
testing can provide a mock JSS, instead of doing extra constructor
overloads.)
Use IndentingPrintWriter for dumping constants.
Test: bit FrameworksServicesTests:com.android.server.job.
Bug: 72353440, 73019091
Change-Id: Icdb40ee3b0bb22a20ed821888b42b87f33eb49ec
The value was removed from AlarmManagerService in http://ag/3486273.
The CTS test is already broken. I will update it outside of this topic.
Test: flash device and check incident.proto output
Change-Id: Ic3781a14bf14a70d5f7b2c615d7e762278e875b7
The fields were removed from PowerManagerService in http://ag/3464790.
The CTS test is already broken at this point. I'll update them outside
of this topic.
Bug: 72660343
Test: flash device and check incident.proto output
Change-Id: Ia2c5872d7ddc70b4e021ff45db3a5a6754c57d31
Ignoring Wallpaper Offsets, the WindowStateAnimator is now
always positioned at (0,0), so we don't need to calculate or store this. For
Wallpaper Offsets we can manipulate the position of the WindowStateAnimator surface
directly. This seems to be a nice level to model the concept of scrolling a buffer
larger than the "Window" to which it is assigned.
Everything on top of WSA can ignore the offsets by only interacting with the WS and above.
Test: Manual. go/wm-smoke
Change-Id: I631ad97bb07b092e795c9530ca34139ccc3e0af7
Use the long whileidle timeout for apps in the background.
Test: Manual test with a test app (I9d0c0ed4b6a0)
Test: atest $ANDROID_BUILD_TOP/frameworks/base/services/tests/servicestests/src/com/android/server/ForceAppStandbyTrackerTest.java
Test: atest $ANDROID_BUILD_TOP/cts/tests/tests/batterysaving/src/android/os/cts/batterysaving/BatterySaverAlarmTest.java
Bug: 72124522
Change-Id: Ibd0a46e573604f7f2d1ec51a60ea87c163233003
I left out the protos that aren't officially used in incident.proto in any way.
The notification captions are set in NotificationManagerService and
ConditionProviders. They're not set by the app at all.
Bug: 72393215
Test: flash device and check incident.proto output
Change-Id: I4b36e066740fa1e6755eb946e2bcfa4959d9f9db
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
