In ContextImpl, we checked the flag "mIsAssociatedWithDisplay" to
identify if a context can access a display or not. The flag wasn't
passed from outer context, and it leads to an issue that context
which created from #createConfigurationContext from display context
failed to obtain display instance.
This CL passes mIsAssociatedWithDisplay from outer context and
also add test to verify the behavior.
fixes: 157719118
Test: atest ContextTest ContextAccessTest
Change-Id: Ibeb2a08c75f90304e12dcf99293c84409c5eea34
Reverts changes 69df963, 0c7c5d59, 6cbef19 and others. These changes
don't revert cleanly because of several refactorings layered on top
of the original changes.
The main objective of these change is to get rid of mUseLayoutForBrowseable
and associated codepaths as we treat choosing between browseables the
same as other choices.
Bug: 157460946
Test: manual
Test: atest ResolverActivityTest
Test: atest ChooserActivityTest
Change-Id: Ibe9f2289289f7f5da3986e6892a2ee4ff65765a0
This can be used to support a 3rd kind of system bar to inset the
applicaiton space.
Bug: 152763889
Test: manual
Change-Id: I3ba75886e94a9fe80a0d1a920749d152dda64031
Currently when a package is installed / updated in a sharedUid the
signatures for the sharedUid are not updated unless the new package
adds a new signer to the lineage; in this case the new lineage is
assigned to the sharedUid without consideration for the existing
lineage. This leads to the following problems:
1. If the current sharedUid lineage is A -> B and the new package has
lineage B -> C then this is used for the sharedUid and A is lost from
the lineage.
2. If the new lineage revokes one or more capabilities from a previous
signer in the lineage these updated capabilities are ignored unless the
lineage added a new signer as well.
3. If the new lineage revokes the sharedUid capability from a previous
signing key in the lineage and another app is installed as part of the
sharedUid and signed with that key the new app's installation is allowed
to proceed.
4. If only a single app is installed as part of a sharedUid, and that
app is updated with a rotated key and a lineage that revokes the
previous signing key's sharedUid capability the update is blocked.
5. If an app is installed as part of the sharedUid and has a diverged
signer in the lineage (ie sharedUid lineage is Y -> A -> B and new app
lineage is Z -> A -> B -> C) the installation is allowed and Y is lost
from the lineage.
Problems 1 and 2 are addressed with the new SigningDetails
mergeLineageWith method that merges common signers between two lineages
and also updates their capabilities to the most restrictive between
the two lineages (capabilities are anded together). Problems 3 is
addressed by checking the signatures of each of the packages in the
sharedUid for any signed with an ancestor for which the sharedUid
capability may have been revoked. Problem 4 is addressed by checking
if the package being updated is the only one in the sharedUid; if so
the update to the new lineage is allowed to proceed. Problem 5 is
addressed by verifying the new app's lineage is the same, a subset, or
a superset of the other.
Bug: 152046935
Test: atest PkgInstallSignatureVerificationTest
Test: atest SigningDetailsTest
Test: atest PackageManagerTests
Test: atest PackageManagerTest
Change-Id: I420c309f522bb47b65ca40ee848024c85cd5804d
The settings app may not be available. In that case, just show the adb
notification without a PendingIntent.
Bug: 156453114
Test: atest AdbNotificationsTest
Test: With USB debugging enabled, install TestDPC, and use it to hide settings app.
Unplug and replug USB. USB debugging notification shows up and clicking
it does nothing.
Change-Id: Ie29d2c425c05bce9371600d76e4eb2eaba692fd7
Change-Id: Ie5f746cbc7b8a32fc280177bf281a9e973c8df12
In the previous implementation a batch of process/activity config
changes would effectively be executed out of order. When the server
would dispatch changes in config in quick succession the config change
items would update the pending configs first through the preexecute()
calls and then apply the activity config before the process config
is applied even though the process config was dispatched before the activity
config change item. See b/148639784 for more detail.
Fixes: 148639784
Test: ActivityThreadTest#testHandleActivityConfigurationChanged_EnsureUpdatesProcessedInOrder
Test: ActivityThreadTest#testHandleActivityConfigurationChanged_SkipWhenNewerConfigurationPending
Change-Id: I3c926076ac8dba73eb0471c7bc91313df519cf92
When there was greater than 2 candidates for app stacking, the prior
targets would get dropped.
Bug: 156220800
Test: atest ChooserActivityTest
Change-Id: Ia8494bb81e95c5415d080148a0c4f98bd243c142
Following the model for dumpsys gfxinfo, this patchset adds a
CacheBinder service that dumps cache state information from each
process.
Bug: 153661880
Test: adb shell dumpsys cacheinfo
Test: adb bugreport
Change-Id: Ie7cce70e56777a200e3e3e92ab895126b6f29032
This CL also removes the assumptions about the new insets mode, because
we are always in the new insets mode now.
Fix: 156311082
Test: atest ViewRootImplTest DisplayPolicyLayoutTests WindowStateTests
Change-Id: I9f6f8824ae364b9cd95f6715dd761026d602c095
- Provide more clear content for single and multiple services are
enabled.
- Avoid non-a11y users accidentally turning shortcut on without
reading this carefully. Hence we put "don't turn on" as the
primary action.
Bug: 155249323
Bug: 138582063
Test: atest AccessibilityShortcutControllerTest
Change-Id: I1c391bb0516bcebfbf6161b94cc0c0b80e0bb72f
* changes:
Send fixed rotation adjustments to the associated client
Add support to override display adjustments by token
Add fixed rotation display adjustments
These new tests verify that all fields defined in UsageStats,
UsageEvents.Event and IntervalStats are known fields. This is to ensure
that when new fields are added to these objects or a refactoring is
done, the fields are accounted for when persisting usage stats.
Bug: 155935953
Test: atest UsageStatsPersistenceTest
Test: atest IntervalStatsTest
Change-Id: Ice65391d0af08b64db4ccaa046e57d9fca299319
So the real information of display can be adjusted according
to the adjustments for the application started with fixed
rotation transform.
The enabling adjustments may be sent in different ways:
- Launch activity
The information is bundled with LaunchActivityItem.
- Resume activity or update non-activity window
Send a standalone FixedRotationAdjustmentsItem.
The disabling adjustments (null) are always sent by
FixedRotationAdjustmentsItem.
Bug: 147213487
Test: AppConfigurationTests#testRotatedInfoWithFixedRotationTransform
TransactionParcelTests#testFixedRotationAdjustments
Change-Id: I5238888a5c8352db83fc12749f4de2bfabf46026
This is the bridge to link customized adjustments to an activity
or window token.
The DisplayAdjustments in ResourcesImpl is associated with
ResourcesKey. The new usage requires to associate with token.
That is why the new field is added in Resources.
Bug: 147213487
Test: atest ResourcesManagerTest#testOverrideDisplayAdjustments
Change-Id: Ie79c331654d564aee7af8c6ce98a4c72dd3132b1
If an activity is launched with fixed rotation transform,
its window layout and configuration will be rotated. But
if it gets real information from the display, the values
(getRotation, getRealSize, getRealMetric, getCutout) are
inconsistent with the actual appearance.
This change provides the basic information to adjust the
returned values.
Bug: 147213487
Test: atest DisplayAdjustmentsTests#testFixedRotationAdjustments
Change-Id: I864d5759f41209d5f93c4a9011b720675c25e765
Otherwise, mRecomputeGlobalAttributes set within the callbacks might be
cleared in the traversal.
This CL also prevents dispatching non-existing insets sources to the
client. For example, if a display doesn't have a navigation bar, the
insets state dispatched by window manager won't contain the navigation
bar source. So that WindowInsets.isVisible(ITYPE_NAVIGATION_BAR) returns
false on such display.
Fix: 155787445
Fix: 155796402
Test: atest WindowInsetsControllerTests InsetsAnimationControlImplTest
Change-Id: I3104191b34c08e14ffb31d7228c832a84629a97b
ag/11054988 updated PackageManager#checkSignatures to support pre-key
rotation behavior when querying by package name; this commit applies
the same logic to the checkSignatures query by uid to check against
the oldest signer in the lineage if either of the requested packages
has been through a key rotation.
Bug: 153910385
Test: atest PackageManagerTests
Test: atest PackageManagerTest
Change-Id: If35c1cdefd06048dc5addc6bbd579d2316ab323b
Uses ParsingPackageImpl to generate the PackageInfo for
PackageManager's getPackageArchiveInfo API.
This keeps the migration to v2 hidden and thus the API can
be shipped for this release and then deprecated entirely
if necessary.
Exempt-From-Owner-Approval: Has approval on previous patchsets,
will need non-logic updates to resolve merge conflict and CP
into rvc-dev properly
Bug: 135203078
Bug: 146575910
Bug: 153880854
Test: atest com.android.server.pm.parsing
Test: atest android.content.pm.PackageManagerTests
Merged-In: Ib21dbbdc556502144df8e3d7a26b7a9d33885cd9
Change-Id: Ib21dbbdc556502144df8e3d7a26b7a9d33885cd9
This metrics now is used for calculating the value reported by
Display#getSize. It could be extended to have more function later.
Also replace getCurrentMetrics usages to make them report
Display#getSize value.
Bug: 148904274
Test: atest WindowMetricsHelperTest
Change-Id: I182b6e63f7c28752eee22839cb9e69f073046c3f
When process configuration was applied on the client side it
accidentally applied an override to display adjustments in resources
for all ResourceImpl objects. This resulted in resources of
activities having incorrect display adjustments and reporting
incorrect display size.
This change fixes the issue by applying the activity's override
configuration on top of the app config before updating the
display adjustments.
Note: This is a slight revert/rework of Ib3ee007bc
Fixes: 148639826
Test: ActivityThreadTest#testHandleConfigurationChanged_DoesntOverrideActivityConfig
Change-Id: I08a5bc29443fbdefbca791240aeaff8f138b8756
Previously, the client won't send the modified insets state to window
manager if the dispatched state and the local state are the same. The
following case can make the requested insets state at the server side
stale:
1. Window A requests an insets source to be invisible while having
the control.
2. Window A loses the control.
3. The new control target requests the insets source to be visible.
4. Window A receives the new insets state from server.
5. Window A also requests the insets source to be visible while not
having the control.
6. Window A gain the control.
7. Window A won't send the new requested state (visible) to window
manager because the local state and the dispatched state are the
same.
8. Window manager keeps assuming that window A is requesting the insets
source to be invisible which is incorrect.
This CL stores what insets state is sent to server, and updates/sends
the state to server while gaining the control if the requested state is
changed.
Fix: 146964271
Test: Manual.
Change-Id: I6ee533d9316c769faef539bfb980197c351ee8d1
We now infer the PIP/MW mode change from the new configuration.
Note also that both
- Activity#isInPictureInPictureMode
- Activity#isInMultiWindowMode
infer the current state from the configuration rather than querying
against the WM.
Also in this CL:
- When in removePinnedStackInSurfaceTransaction, keep the pinned stack
hidden till the windowing mode is set to fullscreen, this is to surpress
the attempt to set the activities to be started in reparenting
- When in ActivityRecord#shouldBeVisible, should take account the force
hidden flag, which is not actually in use before
Bug: 144097203
Bug: 142282126
Bug: 138329093
Test: atest ActivityLifecyclePipTests \
ActivityLifecycleSplitScreenTests \
ActivityLifecycleTopResumedStateTests \
PinnedStackTests \
SplitScreenTests \
ActivityTaskManagerServiceTests \
RecentsAnimationTest \
AssistantStackTests \
StartActivityTests \
ActivityVisibilityTests \
MultiDisplaySecurityTests \
MultiDisplaySystemDecorationTests
Change-Id: Ibe032b5e50ba5c6d6bc44ebb54d07ac974ebe656
