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
It requires a permission which we can't force apps to take to
maintain backwards compatibility. We also arguably cannot because
it leaks visibility, although only for debuggable apps/non-release
builds.
Instead, there's a new static method for getting the raw targetSdk
to gate against and the check is done manually, ignoring
enabled/disabled state. This will cause a mismatch between certain
apps and some system services like AppIntegrityManager, but the
effects should be minimal if we assume that most people ship
valid APKs. At worse the integrity check will pass an APK that
PM will fail, which doesn't break the feature.
Bug: 156356591
Bug: 156778241
Test: manual device boots
Change-Id: I877a5061476b86b9d63c34e75f16b38be8c3e1c2
Since as of R, apps can no longer query other apps by default,
deprecate the isUserAGoat API's undocumented behavior and
always return false.
Fixes: 156543788
Test: atest CtsMultiUserTestCases
Change-Id: I9743d87b762aabb01dc010ba6d5a6c01643a1f92
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
- Apps that have sent incomplete conversations only are allowed
into the conversation section, but not allowed to have full controls.
Users can also demote these apps entirely from the converstion space
- Once an app starts using complete notifications, it can no longer
be fully demoted out of the conversation space, it's only demoted on
a per conversation basis.
- If an app has sent full conversation notifications, and then sends
an incomplete one, the incomplete notification will not be shown in
the conversation space.
Test: atest
Bug: 155276427
Change-Id: Iba9b01c53949632b6db2834511165e3571387ac9
This change treats any filter with a mimegroup as if it matches all or
no mime types when matching for the purpose of app enumeration.
Fixes: 155379839
Test: atest IntentFilterTest
Change-Id: I358872082524a4001179bb145053d006622898a7
This change ensures that we don't take port into account when matching
queries tags against intent filters as port is not a supported value in
a queries intent tag. Adding support for this in a future release will
just limit the scope of the queries tag on thos releases; it will still
be ignored in this release.
Bug: 151638510
Test: atest IntentFilterTest
Change-Id: I69d77ae6bebf3984bfe8e8a0f6c2e9e91ee69298
The referenced object could be destroyed and result in native crash when
mCallback is used.
Bug: 156536687
Test: manual test with registering a section from an app
Change-Id: Ie36c0e6e64be1246539f12999f037c24377686dd
- Haven't been able to repro, but we shouldn't crash system server
Bug: 154382448
Test: Just adding a destroyed check
Change-Id: I412ab1703602723511a6bd3c598d34b6ade68db7
Merged-In: I412ab1703602723511a6bd3c598d34b6ade68db7
A windowless SurfaceControl could grant input via
IWindowSession.grantInputChannel, but other window may receive the
obscured events because of the type value of input window is always 0.
The obscured or partially obscured flag indicates that the window
received this motion event is wholly or partially obscured by another
visible window above it.
We have to filter out the trusted overlap so the motion event could
properly dispatch to the view if it is a security sensitive application.
Bug: 156063505
Test: enter split window mode and check the motion event
Change-Id: I10f63ea131a70ee8cc7d5c4b3e5ca4e5f06fdbad
This reverts commit 0df8812486.
The original CL is trying to reduce the dependency of PownerManager to
finish input when screen off by using display state.
However, it doesn't fully fix the original Bug 26851566 since we only
finish input connection but didn't callback onFinishInput callback for
IME client.
Also, for some scenarios, the window / view focus may not change
during screen turns off / on:
- Focusing timing when disable keyguard, then quickly screen off / on.
- Using P-sensor to turning screen off / on.
When the above scenario happens, makes input connection cannot re-start
and soft-keyboard can't be shown.
(The recovery is manually focus on next window or activity.)
As the above reason, we need to re-consider the lifecycle of
input connection, window / view focus when not only screen state but also
device inactive state when always-on-display.
Fix: 156045961
Fix: 154605805
Bug: 26851566
Bug: 156215187
Test: atest CtsInputMethodTestCases
Change-Id: If06daf71160aa44a4254ac125561974ecbdef4f2
* Imagine this event sequence:
1) the IME tries to re-attach an inline suggestion view to the
window (e.g. because IME layout changes), it calls into the system
server which causes recreating the backing view because it was
destroyed earlier due to 0 ref-count (this happens under the hood
without IME knowing it happens, so the view is still attached to
the window).
2) the IME receives a new inline suggestion pointing to the same
backing view (perhaps due to filtering kicks in).
3) the recreation from step 1 finishes, but now it will callback
to the new inline suggestion, therefore the old view doesn't receive
the new SurfacePackage. See RemoteInlineSuggestionUi for why.
4) the view in step 1 is detached from window, since it never
receives a SurfacePackage from the remote view, its detach shouldn't
cause a reference count down on the remote view.
Test: atest android.autofillservice.cts.inline (sanity test)
Bug: 154683107
Change-Id: I2e6814ef3889de603f6e170efcb795b69ec9febe
positionLost can be called from CanvasContext::destroyHardwareResources
which runs asynchronously to the UI thread. This means we could be
simultaneously executing releaseSurfaces on the UI thread. We need
to expand the scope of mSurfaceControl lock in positionLost. While
we are here we add a block comment explaining the previously
undocumented locking strategy.
Bug: 156264048
Test: Existing tests pass
Change-Id: I9cdb6a0f7aeffd878f1755f240e8896f0fb8bf01
Add a package manager flag so that apps can programmatically query
whether the device have system interface to support the Controls API
Bug: 156096063
Test: manual
Change-Id: I2dab2ecb762b59308c51615137f89733ff42caeb
Pre-R, the screenshot window was used just for screenshot animation. In
R, the window is also hosting tappable screenshot actions, which require
focus.
This change modifies TYPE_SCREENSHOT to no longer force it to be
unfocusable.
Test: Verify that screenshot window UI elements can work with talkback
and accessibility scanner.
Bug: 153517161
Bug: 152583784
Change-Id: If81d9f94dff801c3483a2d834e692b4c77d80d7b
Fix documentation to clearly indicate that the default behavior is to
show WebView's own default dialog.
Also, change some wording to avoid confusion.
Bug: 154014645
Test: m -j offline-sdk-docs seems unbroken
Change-Id: I3f6676094e5472aa99bb014cf2b489f59133d094
This CL reverts ag/10267783 effectively.
ag/10267783 makes tab key insert \t character on multiline text fields,
however, it broke the existing apps which depends on the previous
behavior.
Bug: 154290658
Test: manual - Tab key on multiline text fields advance focus
Test: atest TextViewTest#testKeyNavigation
Change-Id: I9836ce29321ca789bce6636514ce9a8dbf923ada
Anecdotally this should cover typical messaging first screens
whereas 100 events seems to be small.
Test: make -j
Test: Manually start WhatsApp - check for lost events
Bug: 154777879
Change-Id: I3090584ec03714656948045189e0e0c068740c82
