Revert before releasing
Let the apps built with pre-release Tiramisu SDK parse
+ fix a test that didn't expect REL builds to throw
when checking for lettered versions
Test: build
Bug: 225745567
Bug: 231407096
Change-Id: I965c01b4453289c3e9a930180804728be0b5b045
Repurpose the legacy BIND_VISIBLE to this new flag, as the BIND_VISIBLE
was actually never implemented.
This new flag is for use by the system or persistent processes,
the process state of the service process will be bumped to
the PROCESS_STATE_FOREGROUND_SERVICE, with oom adj score "visible".
Bug: 230897753
Test: atest MockingOomAdjusterTests
Change-Id: If86ec9281ec482a0916c78338ae88cf2199256e4
We currently close the IME by having the target application forward KEYCODE_BACK to the IME process through InputMethodManager#dispatchInputEvent and having the IME handle the keycode in InputMethodService#onKeyDown. When apps opt in to OnBackInvokedDispatcher API, we will not dispatch KEYCODE_BACK to apps anymore. Thus we need to migrate IME to the new API for it to close on back invocation.
This implementation forwards OnBackInvokedCallbacks from the IME process
to the app process. This is necessary because all callbacks need to
exist in the app process for them to be considered by hardware back keys. While back gestures go through WM to resolve callbacks from the focused window, hw keys are directly sent to the focused window's ViewRootImpl, bypassing server side back nav logic.
Bug: 228358882
Test: atest CtsInputMethodTestCases:KeyboardVisibilityControlTest
Test: atest CtsInputMethodTestCases:InputMethodServiceTest
Test: atest CtsInputMethodTestCases
Change-Id: Ie207b63b11a56c9b2173f26b734a27b13ebccc60
A user can be created with an explicitly null name, as happens in tests.
But getUserName claims to never return null. So we must do a null-check
here to prevent it.
Bug: 227624966
Test: atest UserManagerTest
Change-Id: Iea0e7b6292c6dd49df1bebc5467091a82ddaedb5
Not caught in unit tests because this is more an integration failure
(detected when writing e2e tests).
Bug: 208239394
Test: the actual e2e test will be published when this is submitted
Test: m ApkInApexTest
Change-Id: I8b62e473e2b3613cf290ff05963a47ba86140d99
The remaining tests have a low flakiness rate and a total runtime < 30mins.
BUG: 140252512
Test: n/a
Change-Id: Ic7631db5fd4e3c28a7b7cbe464bf46be93c4c05c
This reverts commit 4df2de8380.
There was a bug in the CL. Rather than fixing it forward, let's revert
it and fix it in a follow-up CL, so we'll only have to back-port
a single CL.
Bug: 203229608
Test: N/A, a follow-up CL will redo this change with a Test: line.
Change-Id: I5fddf283ace09996a2e5cfc272f8e9fd8168a114
When APK key rotation was initially introduced in P, an update to the
capabilities of a previous signer in the sharedUserId lineage only
took effect when the signing key of the package being updated was
changed. Android R addressed this by always merging the lineage of
a package being installed / updated in the sharedUserId with the
existing sharedUserId lineage; however, this approach always used
the most restrictive capabilities in the lineage, so once a
capability was revoked from a previous signer, it could not be
restored. This commit allows a capability to be restored by
initially applying the capabilities of the package being installed
with those in the sharedUserId; if a change in the signers or
capabilities is detected, then the most restrictive capabilities
from all packages in the sharedUserId are used to update the shared
lineage. This allows a package to restore a previously revoked
capability if no other packages have revoked the capability; however,
if a package in the sharedUserId has revoked a capability and a newly
installed package restores this capability, the restrictive rule will
ensure the capability is still revoked.
Bug: 227823594
Test: atest PkgInstallSignatureVerificationTest
Test: atest SigningDetailsTest
Change-Id: Id53a2cd235c7a557822b9a1bfc2f431801d415e4
+ Use hostside test class for SplitTest
+ Remove duplicated PackageParserTest
BUG: 140252512
Test: manual
Change-Id: I73bdceb0c5b333041b96cd777790c0ba0cece0e0
Since we're no longer planning on enforcing the flag requirement for
exported/not exported in T, we should update the compat change so that
it's disabled, which will allow developers to still test it, change the
error message so it doesn't reference Android T, and remove the
additional system property that enabled stricter enforcement.
Test: atest ContextText
Bug: 225057637
Change-Id: Ibdc079ef7e92954422ddde715b3a4ae358f552e3
This is currently a recurring issue every new Android release as a few of
our apps will be targeting new platforms and they also get installed on
devices running older SDKs.
This change only changes behaviour for APK in apexes.
Test: atest com.android.server.pm.parsing.PackageParserLegacyCoreTest
Bug: 208239394
Merged-In: If1195c8ec39ac88a605e25dfb1c78d49a5aa3e7c
Change-Id: If1195c8ec39ac88a605e25dfb1c78d49a5aa3e7c
This extra enables applications to mark ClipData items as sensitive,
indicating that the data within should not ordinarily be displayed.
Applications (e.g. IMEs that store clipboard history) can use
this flag to prevent sensitive data from being unintentionally
displayed on screen.
Bug: 195554988
Test: N/A
Change-Id: Ibccd3944842a40d3e5afec2dd99f32eb7a3564db
If this feature is not supported,
1. Settings should hide window magnification settings.
2. Magnification mode settings should fallback to.
full-screen settings.
Bug: 225086379
Test: none
Change-Id: I3248034d25eb88136bda1874092319d4702be455
In Android R, the platform began enforcing a requirement that apps
targeting this release or later must be signed with at least the V2
signature scheme. Initially, this requirement was applied to system
apps, but due to the build system stripping V2+ signatures due to
compressed dex and library files, the requirement had to be relaxed
for system apps; since then, the system apps have been updated with
uncompressed dex and library files to prevent the signature stripping
by the build system. This commit restores the requirement that
system apps targeting SDK version 30+ must be signed with at least
the V2 signature scheme.
Bug: 215046612
Test: Manually verified fix properly identified system app without
V2+ signature
Change-Id: I5b482931a99ea8c2308d516912317ff0828153e2
