Prior logic only counted the number of grouped items. This could
result in the a-z list not being shown even though there were
additional targets. For instance, if 1 group had 9 targets, a-z
would've been hidden even though only 4 targets were present in the
ranked app row, resulting in 5 targets being inaccessible.
Fixes: 158017940
Test: atest ChooserActivityTest#fourOptionsStackedIntoOneTarget
Change-Id: I58e262e40f3064ce8a091e44d6b00163c8f4e4f3
When we notify insets changed, legacy behavior forces us to force
a new measure on the entire hierarchy. However, this can cause
jank in various scenarios.
Make sure that we don't report an insets change if non-observable
state changes.
Test: InsetsStateTest
Test: Swipe up to home while IME open
Bug: 157123435
Change-Id: I9c51066c6489888720b307240d03054cc18c4172
Fixes an issue where the mPendingFrame was not properly cleared
if we re-applied the current frame.
Fixes: 156762386
Test: InsetsSourceConsumerTest
Change-Id: I9f0ebfafac44e1b4b87ea9d3408e64ba34bca2ec
IMS handles configuration and display changes from the server side
and render views to inteact with users. Thus IMS should be marked as
an UI context
fixes: 157027563
Test: atest ContextTest
Change-Id: I0a2307c4764acf8b9fc0254a9ee2fc8a344bb7ef
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
