On ODPM enabled devices, the total mobile radio power consumption was
being used when reporting the idle/suspended power. This means app
mobile radio power consumption was effectively being double counted.
Bug: 209525694
Test: atest MobileRadioPowerCalculatorTest
Change-Id: Ibc1a504014ac10c285b71273ba50493ba237f6a9
Merged-In: Ibc1a504014ac10c285b71273ba50493ba237f6a9
The isolated uids need to be kept in the map while it is holding a long
partial wakelock.
Bug: 218298973
Test: atest BatteryStatsNoteTest
Change-Id: I86456137e6d6ad47f9974da281defc04d20fb32f
(cherry picked from commit fd48aa6fa6)
Merged-In: I86456137e6d6ad47f9974da281defc04d20fb32f
Also adds unit tests for TimingsTraceAndSlog.
Test: atest FrameworksMockingCoreTests:TimingsTraceLogTest FrameworksMockingServicesTests:TimingsTraceAndSlogTest
Bug: 223642864
Change-Id: I3a2b259fca7c4fbab08bc4212d850fee3ac2f037
One of the optimizations ag/12911059 did was calling
SelectionModifierCursorController.show() before
startActionModeInternal(). The rationale was that if we start the action
mode first, SelectionModifierCursorController.show() would end up
invalidating the action mode twice unnecessarily, once for each handle.
However, with this optimization, we are calling
SelectionModifierCursorController.show() even when onCreateActionMode
returns false.
Reverted this particular optimization to fix the issue.
Added a test which was failing without this fix but passing with it.
Fixes: 199380016
Fixes: 214341747
Test: atest TextViewActivityTest
Merged-In: I793f76a23978cbbbbde2d16e8a522615174bcdd5
Change-Id: I793f76a23978cbbbbde2d16e8a522615174bcdd5
(cherry picked from commit 11bd644822)
It should check if the device supports the managed_users feature.
Test: atest ManagedUserContentResolverTest
Fixes: 215200534
Change-Id: I23f62b4a55a42458cfd59b611ffa80f2d4eee75a
This CL also adds a test to ensure that a pointer source is used by
default when obtaining a MotionEvent, and that offsets are only applied
to pointer sources.
Bug: 207251886
Test: atest MotionEventTests
Change-Id: Id40accc6d1238c940f139a18b26fa277dd6e11f9
New field indicates if ActivityRecord#providesMaxBounds has
calculated that sandboxing of max bounds to match app bounds
should be applied.
Test: manual
Bug: 193514437
Change-Id: I91587ce1e1ded7435038e2d1a7d038be57ff0f2f
Before [1], WindowContext#getDrawable with custom drawable would
lead to app crashes.
This CL adds a test to prevent future regression.
[1]: 09c03ec912
fixes: 203027987
Test: atest WindowContextTest
Change-Id: I46fc81c3e850089b8021053b38e258720023aa68
an inner exception that captures the stacktrace where
Context.startForegroundService() was called last time,
from the same process.
Bug: 124137635
Test: Manual test with a tesapp. 1: when startForegroundService() is called by
the same process:
```
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: FATAL EXCEPTION: main
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: Process: com.google.omakoto.testapp, PID: 9545
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: android.app.RemoteServiceException$ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{e7674af u0 com.google.omakoto.testapp/.MyFgs3}
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.generateForegroundServiceDidNotStartInTimeException(ActivityThread.java:1965)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:1934)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.access$2700(ActivityThread.java:255)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2190)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:201)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.os.Looper.loop(Looper.java:288)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7839)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: Caused by: android.app.StackTrace: Last startServiceCommon() call for this service was made here
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1868)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ContextImpl.startForegroundService(ContextImpl.java:1823)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.content.ContextWrapper.startForegroundService(ContextWrapper.java:779)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.content.ContextWrapper.startForegroundService(ContextWrapper.java:779)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at com.google.omakoto.testapp.MyReceiver.onReceive(MyReceiver.java:53)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.handleReceiver(ActivityThread.java:4345)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread.access$1600(ActivityThread.java:255)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2102)
11-17 17:00:12.483 10241 9545 9545 E AndroidRuntime: ... 7 more
```
Test: Manual test with a tesapp. 1: when startForegroundService() is called by
another process:
```
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: FATAL EXCEPTION: main
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: Process: com.google.omakoto.testapp:second, PID: 9432
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: android.app.RemoteServiceException$ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{dcaa127 u0 com.google.omakoto.testapp/.MyFgs3}
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread.generateForegroundServiceDidNotStartInTimeException(ActivityThread.java:1965)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:1934)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread.access$2700(ActivityThread.java:255)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2190)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:201)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.os.Looper.loop(Looper.java:288)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7839)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
11-17 16:59:34.456 10241 9432 9432 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
```
Change-Id: I2dd8ec76213d53728eaa8fcc3760813d82a328a5
Before this CL, SystemUiContexts were fixed to the Display metrics
when the SystemUiContexts were created. It is the same mechanism
as DisplayContext but applies to SystemUiContexts unexpectedly.
This CL makes SystemUiContexts associate with DisplayContent with
the corresponding display ID. In this way, SystemUiContext would
receive updates when there is a Display property change.
Bug: 194262507
Bug: 191064581
Bug: 205859784
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Test: atest NexusLauncherTests
Change-Id: I64a1614f32d097785915f6105b1813a929e0fe32
When checking whether a notification has a media session, make sure that
the value in the extra is the correct type.
In addition, moves this check inside of
Notification#isMediaNotification for consistency - existing usages either
already checked both or will not be impacted, given that valid MediaStyle
notifications are now shown in the media carousel instead of with other
notifications in the shade.
Fixes: 205570941
Test: atest
Test: manual, repro case in bug
Change-Id: I5d0134d2ce81e9e6a2ed16748f84252bf765a1c9
The root cause of this failure is that we don't specify Configuration#orientation
in test, so #handleActivityConfigurationChanged uses device orientation
instead, which is landscape in the failure case. In this way, TestActivity receives
2 onConfigurationChanged callbacks, one is to make Activity portrait,
the other is to make Activity landscape, which is from process
configuration.
This CL specifies orientation in each propagated Configuration to
prevent orientation overridden by process Configuration.
Bug: 204903019
Test: atest ActivityThreadTest
Change-Id: I4d7720ef1128fc8612381b1a076b06beb765f1b6
Before this CL, SystemUiContexts were fixed to the Display metrics
when the SystemUiContexts were created. It is the same mechanism
as DisplayContext but applies to SystemUiContexts unexpectedly.
This CL makes SystemUiContexts associate with DisplayContent with
the corresponding display ID. In this way, SystemUiContext would
receive updates when there is a Display property change.
Bug: 194262507
Bug: 191064581
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Change-Id: Idd74da965c18bdbf8912bd45e89be21f652dcf93
A deadlock path is found:
- FrameTracker$1.lambda$surfaceDestroyed (held A)
- InteractionJankMonitor.end (held B) -> FrameTracker.end (wait for A)
- FrameTracker.end -> InteractionJankMonitor.handleCujEvents (wait for B)
This cl resolves this by using a single lock among monitor and tracker.
Bug: 197804653
Test: atest InteractionJankMonitorTest --rerun-until-failure 100
Test: atest FrameTrackerTest --rerun-until-failure 100
Change-Id: Ia6aa196370bdb51b8a5c84c74a3d174a3d4b689f
Add screen on and doze timers for multiple displays.
For Battery history, charge/discharge logs and UnsupportedAppUsage, the
legacy screen state timers remain, as well. The legacy timers and
screen state tracking will now track overall screen state of the device.
The current overall screen state is the most "important" state currently
active.
Order of screen state importance is: on, doze, doze suspend, off.
Note: Utilizing per display measured energy will be handled in a follow
up CL.
Bug: 194107383
Test: atest FrameworksCoreTests:BatteryStatsTests
Change-Id: I4ad4f54b6897f406e4ec0f59834dd4762083e0d8
Merged-In: I4ad4f54b6897f406e4ec0f59834dd4762083e0d8
Replaced the display related power constants with new ones that support
multidisply.
The legacy constants are marked as UnsupportedAppUsage, so they have not
been removed yet and they attempting to read them will return the power
constant values for the first display.
Fixes: 200226329
Test: atest com.android.internal.os.PowerProfileTest#testPowerProfile
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryStatsTests
Change-Id: Id181443bd6f553ee37fc4a1647d31644fcad7912
The token was needed because the TaskFragment info may not
sent to the organizer before activity created.
The token is no longer necessary because the TaskFragment
info is now ensured to be updated before activity created.
Bug: 200303250
Test: wm presubmit
Change-Id: I69a42fa35efde4fc7f37ab50334de5de146da90d
If the lists of custom power components do not match, a crash will occur.
Instead of causing a crash, simply skip incompatible snapshots.
Bug: 196040329
Bug: 200511361
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryUsageStatsProviderTest
Change-Id: I87ba605371a5f3119dcff33f6109e94ee46ab57d
(cherry picked from commit a1ea9ecd56)
WindowContext relies on WindowTokenClient#onConfigurationChanged after
calling WMS#attachWindowContextToDisplayArea.
However, it took some time to wait for onConfigurationChanged callback
from the server side so that we may get a stale value right after
creating WindowContext.
This confuses developers especially when the foreground activity is in
size compat mode or freeform because the process config is overridden
by activity's config.
This CL makes #attachWindowContextToDisplayArea return DA's configuration
and applies to WindowContext direcly.
It also benefits WindowProviderService because it can obtain DA's
configuration before onCreate() based on [1] and this CL.
Bug: 190019118
Bug: 190745506
Bug: 198298520
Test: manual - 1. launch an Activity in size compat mode
2. create a WindowContext and verify if WindowMetrics
matches DA bounds.
Test: atest WindowContextTest WindowContextTests
Test: atest WindowContextControllerTest ContextGetDisplayTest
[1]: dd4a748af0
Change-Id: I8dd3987b731662502bc01e9d2ed67e718ada5f46
* changes:
Reduce the color contrast requirements for the emphasized action button fill color.
Refactor the color span code inside Notification.java and add tests.
This reduces the contrast requirement between the notification background and the button fill from 3:1 to 1.3:1
Fixes: 196393060
Test: manual testing using the go/notify2-apk and the CallStyle color customizer
Test: android.app.NotificationTest
Change-Id: I0fc3b7ae1ede7afd28974c59fa2a58d7fea2e9de
* This makes it easy to reduce the contrast requirement between the notification background and the button fill in another review.
* This also fixes a bug where partial-length color spans within the emphasized buttons would be contrast-adjusted only with the notification background color rather than the button fill color.
Bug: 196393060
Fixes: 197572220
Test: manual testing using the go/notify2-apk and the CallStyle color customizer
Test: android.app.NotificationTest
Change-Id: I712e6d6b2da1de89afeacda7bd2fc4ad24632811
Wakelock tracking in BatteryStats relies on the the isolated uid map
when tracking wakelocks from isolated uids. The map needs to keep the
isolated uid while it still has a wakelock.
Bug: 194414351
Test: atest BatteryStatsNoteTest
Change-Id: I5e51f5f90191829d12fb080169520d9827b9906c
(cherry picked from commit 83c0928c34)
Merged-In: I5e51f5f90191829d12fb080169520d9827b9906c
When AChoreographer is the only callback registered with
DisplayManagerGlobal and there are no other display listeners,
DisplayManagerGlobal incorrectly skips callback registration with DMS.
Bug: 193945763
Test: atest DisplayManagerGlobalTest
Change-Id: I4b737fa0a91541fe331edcf3454724200e2db971
