Floating IME or fullscreen IME won't cause insets (except the area
overlapped with navigation bar). It doesn't make much sense to let
apps move the IME at these cases.
Fix: 157777145
Test: atest InsetsSourceConsumerTest
Change-Id: Ibdf5454843c880d7e726a66a8f1107ca511e5025
This broke in P. Basic support was broken by a simple negation
issue with the logic that checks for the original package.
That, along with the suggestion in the bug to fix the renamed
package association means this should now work as expected,
carrying data over from a previous installed, differently named
package.
Bug: 131355130
Bug: 132749720
Bug: 111967720
Test: atest PackageManagerServiceHostTests
Change-Id: Ifc4c7af47c4b633cd27ba4a40b6baa0e27960d71
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
To mitigate a boot loop with reading a massive
install_sessions.xml file, this restricts the amount of
data that can be written by limiting the size of
unbounded parameters like package name and app label.
This introduces a lowered max session count. 50 for general
applications without the INSTALL_PACKAGES permission, and
the same 1024 for those with the permission.
Also truncates labels read from PackageItemInfo to 1000
characters, which is probably enough.
These changes restrict a malicious third party app to ~0.15 MB
written to disk, and a valid installer to ~3.6 MB, as opposed to
the >1000 MB previously allowed.
These numbers assume no install granted runtime permissions.
Those were not restricted since there's no good way to do so,
but it's assumed that any installer with that permission is
highly privleged and doesn't need to be limited.
Along the same lines, DataLoaderParams are also not restricted.
This will have to be added if that API is ever made public.
However, installer package was restricted, even though the API is
hidden. It was an easy add and may have some effect since the value
is derived from other data and passed through by other system
components.
It's still possible to inflate the file size if a lot of
different apps attempt to install a large number of packages,
but that would require thousands of malicious apps to be installed.
Bug: 157224146
Test: atest android.content.pm.PackageSessionTests
Change-Id: Iec42bee08d19d4ac53b361a92be6bc1401d9efc8
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
If the fulfilled policies change without the contents of the target
and overlay APKs changing, the idmap for the overlay should be
regenerated. This change adds fulfilled policies and enforce
overlayable to the idmap header so that idmap2d can determine if the
polices or enforce overlayable changed from what was used to generate
the idmap.
Bug: 119328308
Test: idmap2_tests
Test: atest RegenerateIdmapTest
Change-Id: I96f970e82b5243be01b205ac2cb6ab249c6100bc
Adds a listener to receive updates to the state of the HDMI CEC volume
control features.
Interested parties can register and unregister to get notified about
state updates which are sent on every change to the value.
Test: atest HdmiControlServiceTest
Bug: 152018314
Change-Id: I342d748114bae99b3c3f236502d73bfeac9e9ac5
Merged-In: I342d748114bae99b3c3f236502d73bfeac9e9ac5
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
When overlays for a target package change, invalidate PackageInfo
caches across all processes. Overlay paths are not persisted in PMS's
settings, so no need to commit to package settings.
Bug: 156743293
Test: presubmit
Change-Id: I193544abe29cff07dda76a75376961d0d51d9c95
The previous implementation of backing up beforehand doesn't handle
the case where the file is created for the first time, and might leave
a corrupted file in case of failure.
This new implementation creates a new file for writing data into, and
renames it into the place of the original file after writing
finished.
Fixes: 151959443
Test: atest android.util.AtomicFileTest
Change-Id: I5c4c438526a2aecdd2af18f71e16b41a05817c61
Merged-In: I5c4c438526a2aecdd2af18f71e16b41a05817c61
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
