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
The FontFamily will be removed if none of font files exist on the
device.
Bug: 192479819
Test: atest FontListParserTest
Change-Id: I36f6476fe37bc04ec8737936747385c63908d651
(cherry picked from commit 691cfe8818)
Changes included:
* 74e6d6f: Handle the switch in datatype in DeleteByQueryResultProto#stats from DeleteStatsProto to DeleteByQueryStatsProto
* 40f6974: Return Native StorageInfo from AppSearchImpl
* c1bcc04: Bring back the checkSuccess() method in AppSearchBatchResult.
* 4222618: Logging stats for SetSchema.
* 89e1c33: Use the user-defined logger in SearchResultsImpl
* 3bc2616: Log the stats for SearchResults.getNextPage()
Bug: 173532925
Bug: 194118423
Bug: 194309308
Test: Presubmit
Change-Id: I3c06c937c8f59bcfada4cd36d61cba83d72f80b2
- Each layer having separate a lock and making calls to other layers
while holding lock leads into deadlock.
- Change all of them to use a single lock from the service to avoid
deadlock.
- Performance impact should be minimal as there are not that many
players for radio (one app, HAL, and system server) and the amount
of calls are not that frequent.
Bug: 194818704
Test: atest BroadcastRadioTests
Change-Id: I5f51c0e0a04ae10428f721be508d5579dc1dd837
(cherry picked from commit 2cdb566acb)
Merged-In: I5f51c0e0a04ae10428f721be508d5579dc1dd837
Currently, an activity is relaunched from a resize only if
the activity does not handle SCREEN_SIZE config changes and
the new activity size crosses a width, height, or smallest
width resource qualifier. A change in activity size may also
change an activity’s screen layout. However, an activity
is relaunched from a screen layout change if it does not
handle SCREEN_LAYOUT config changes even if the screen layout
did not cross a screen layout resource qualifier.
This CL does three things:
(1) Propogates screen layout qualifiers through the same
path as width, height, and smallest width qualifiers
in the AssetManager to make it available to the
WindowManager.
(2) Prevents an activity relaunch if the screen layout
has been changed but does not cross a screen layout
qualifier.
(3) Adds tests for SizeConfigurationBuckets for the new
screen layout logic as well as for existing logic.
Test: atest FrameworksMockingCoreTests:SizeConfigurationBucketsTest
Bug: b/192369163 b/187529743
Change-Id: I41d28e6492b76c4284c4dca2c1f3f5904fc5e91a
Currently the <cloud-backup> section in android:dataExtractionRules is
ignored unless it contains rules. Instead, we should interpret it as
'everything other than cache and no-backup dirs is eligible for cloud
backup'.
Bug: 195095045
Test: 1. atest BackupEligibilityHostSideTest
2. Use a test app with empty <cloud-backup> section to manually
test:
2.1. Empty section - everything is backed up
2.2. Empty section but "disableIfNoEncryptionCapabilitites"
set to "true" - data only backed up if the transport supports
encryption.
Change-Id: Ic8066721a46bda688f9211c51a0f2497e9caf93b
Activity#onCreate is called before receiving the TaskFragment
appeared event in the client process. So, the client split
controller created another split and resulted in unexpected
behaviors.
Bug: 194860679
Test: start activity to side
Test: wm presubmit
Change-Id: Iac34bd39376940c5c0224c8687ad9858a4190e20
The original code is based on /proc/locks manpage. Unfortunately, that
manpage is never correctly updated to include the new field for blocked
locks. The new code detects the extra field. As StringTokenizer is too
heavy, ProcFileReader is used for better performance.
Bug: 194756340
Test: FrameworksUtilTests com.android.internal.util.ProcFileReaderTest
Test: FrameworksCoreTests com.android.internal.os.ProcLocksReaderTest
Test: No /proc/locks parsing exception with blocked locks
Change-Id: I4c9763f9d3091f7d84d2e4b672d7e5cb78b33f59
The flakewas fixed by ag/15353756, so remove the annotation.
Bug: 194242735
Test: atest ActivityThreadTest
Change-Id: Ia6e3eda250a0b54a2027d16f6e51887c85ac8f95
InsetsState contains much more information than visibilities, such as
display frame, display cutout, rounded corners, privacy indicator
bounds, and frames of of insets sources. The control target only needs
to send the requested visibilities to WMS, so it can be too heavy to use
InsetsState.
This CL introduces an new class, InsetsVisibilities, which only contains
which type has which visibility. So it uses less memory, and it is more
efficient on copying and checking the equality.
Fix: 194186241
Test: atest InsetsVisibilitiesTest WindowAddRemovePerfTest
InsetsControllerTest RegisterStatusBarResultTest
CommandQueueTest LightsOutNotifControllerTest
ActivityRecordTests DisplayContentTests
DisplayPolicyLayoutTests InsetsPolicyTest
InsetsSourceProviderTest InsetsStateControllerTest
WindowFrameTests WindowManagerServiceTests WindowStateTests
Change-Id: I86c1b26b4383bfa3b924726d580e5706e13ba735
