When AutofillManagerService try to trigger AugmentedAutofill, it uses
AutofillId.withoutSession() to get the AutollId without session. It
will return invalid "parentId:NO_ID" if the virtual AutofillId is
created with FLAG_IS_VIRTUAL_INT. The virtual AutofillId flag should
be FLAG_IS_VIRTUAL_INT or FLAG_IS_VIRTUAL_LONG, we should get
mVirtualIntId for FLAG_IS_VIRTUAL_INT or mVirtualLongId for
FLAG_IS_VIRTUAL_LONG.
Bug: 156408900
Test: atest android.autofillservice.cts.augmented
Test: atest android.view.autofill.AutofillIdTest#\
testVirtual_Long_withoutSession
Test: atest android.view.autofill.AutofillIdTest#\
testVirtual_Int_withoutSession
Test: Manual. Write a simple cts test for webview and check the
focused AutofillId is correct while switching between the field.
Change-Id: I7ebb4d7cfb6d6f383724b798dae69269ae3a27be
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
