ag/3340390 changed untrusted value to systemDir while going through
code review, flipping the meaning of the variable, but this was not
reflected in the call site. As a result, systemDir apps are the
only ones being fully verified, which is the opposite of what we want.
Test: Builds, eventually CTS.
Change-Id: I585ac65c957f0d8db6c73f003d3a3eb2b79c8883
After discussion in API council, our new best-practices are to have
developers provide an Executor to dispatch callbacks/listeners on,
instead of the previous guidance of using a Handler.
Define Context.getMainExecutor() to easily obtain an Executor
associated with the main thread of application. This allows new
APIs to require a @NonNull Executor. Also define a new
@CallbackExecutor auto-doc annotation that explains background and
points developers at new Context method above.
Test: cts-tradefed run commandAndExit cts-dev -m CtsContentTestCases -t android.content.cts.ContextTest#testMainLooper
Test: cts-tradefed run commandAndExit cts-dev -m CtsContentTestCases -t android.content.cts.ContextTest#testMainExecutor
Bug: 70348426
Change-Id: I536892bcd80fcfba1bb1ddf67648c08a26d7ddd2
API to allow some classloader control over instantiation of
items from application's manifest. Unlike the first attempt
this does not encourage developers to extend Application, it simply
provides a small surface to allow control over the creation of objects
like Activities, Services, Receivers, and Providers.
Test: manual
Bug: 70623879
Change-Id: Idcab7c60f54ce3f4575ac29dcdcae321cf458bf3
PackageParser shoudln't really need to know the gory details of APK
verification, it should just get back the blobs it needs to do its
job. Move the package verification into its own class which is
*almost* exclusively responsible for verifying app signatures. This
is in preparation for adding APK signature scheme v3, which will add
yet another way to do this.
Bug: 64686581
Test: Builds 'n' boots without issue.
Test: android.appsecurity.cts.PkgInstallSignatureVerificationTest passes.
Change-Id: Ieb76b2353bd44ffdb83e7b894e5ad720d1697dc7
As part of deprecation policy enforcement for android apps, minimum
supported targetSdkVersion will be 17. Apks targeting values lower that
one set in PLATFORM_MIN_SUPPORTED_TARGET_SDK_VERSION will fail to install.
PLATFORM_MIN_SUPPORTED_TARGET_SDK_VERSION is currently set to 0 and
will be set to 17 in a following cl.
Installation of deprecated apks can be forced using adb install
--force-sdk flag.
More details in http://go/android-platform-deprecation-policy.
Test: tests are in complementary Cts cl.
Bug: 63926630
Change-Id: I8e55bdebf1fb2cfd951e2c6703ccc87b8d4e9a09
Behaves pretty much the same as @IntDef, but now supports "suffix"
in addition to "prefix" when matching constants.
Test: manual docs output looks sane
Bug: 70406696
Change-Id: I35064b0f9f36f1f13ccdb40302d818a004014f15
The flag is used in CTS.
Bug: 70332172
Test: cts-tradefed run commandAndExit cts-dev -m CtsPermission2TestCases
-t
android.permission2.cts.PermissionPolicyTest#testPlatformPermissionPolicyUnaltered
Change-Id: Iba4ce1475991249980cc6a403037f4dd7bf722e5
Change to a sensible name which doesn't conflict with legacy RTT
service.
Bug: 65108607
Test: unit test, integration test
Change-Id: I54855635061c09e8d4bd2e97bac049f2893de123
This change introduces a metadata Bundle to the InstantAppResolveInfo
type to be passed along to the Instant App installer in the case of
resolution. This can be used by the resolver and installer to improve
launch by avoiding IPC to fetch needed data that lives in the resolver.
Change-Id: I0b9c168dd8803f5398d222384ebd436c787e1a48
Fixes: 68223794
Test: manual - modified resolver to populate data, verified in installer
Historically, if a service returns null from onBind(), the binding app
gets no information about the outcome: the ServiceConnection is never
invoked. We now introduce a new connection callback, onNullBinding(),
for apps that need to detect this situation. When the service rejects
the binding by returning null, the onNullBinding() callback in the
associated ServiceConnection is invoked instead of onServiceConnected().
onNullBinding() has an empty default implementation, so there is no
binary-compatibility impact of this new interface method.
Bug: 67377345
Test: atest android.app.cts.ServiceTest
Change-Id: I224512c118f7d6e5c1c2bb69eca1902882e73594
This change adds the action being resolved to an installing Instant
App to the installer so it may increase friction for untrusted or
potentially dangerous sources (NFC, nearby, etc.)
Change-Id: If6c47a219e4ddf453fb406e2b212b024aa24ade6
Fixes: 63102749
Test: manual - debugged the ephemeral installer to ensure extra
The API allows a system apps which acquired
{@code android.permission.READ_RUNTIME_PROFILE} to snapshot the runtime
profiles of installed packages.
The API is implemented in a new service class (AndroidRuntimeManager)
accessible from the context using
context().getPackageManager().getAndroidRuntimeManager().
The main functionality is exposed as a one way call into the
AndroidRuntimeManager with the result being posted on a callback. The
profile is available to the caller as a read-only ParcelFileDescriptor.
This CL only adds the API interfaces and validation. It does not fully
implement the functionality.
oneway void snapshotRuntimeProfile(in String packageName,
in String codePath, in ISnapshotRuntimeProfileCallback callback)
Bug: 30934496
Test: gts-tradefed -m GtsAndroidRuntimeManagerHostTestCases
Change-Id: Iaa6be4715840f24508acba3162ea9c1ab725bd38
It turns the version code into almost a 64-bit integer, with the
new major part being the upper 32 bits.
The only tricky part about this is the backup manager, since it
stored 32-bit version codes in its backup data sets. This is dealt
with by, when the major version code is not 0, writing MIN_INT as
the version code and following that by the full long version code,
which we can detect when reading. Note that this makes backup sets
containing apps with major version codes incompatible with older
versions of the platform.
Bug: 64459786
Test: Added in Change-Id: Iab8a682b62103babd6c16a56b8dc1e97d7078658
Change-Id: Ibfffe235bbfcf358b3741abd3f7197fdb063d3f3
Leave the resource retrieval part in client side to avoid passing
drawable across process boundary which should be bad for performance.
The verification part is done in client side, so in theory, apps can work
around the verification. That said, the strings and drawables
are not secret anyway, they are just a generic icon / label to represent
the user. Also, they can always retrieve them by using getDrawable
anyway.
BUG: 67765768
Test: bit FrameworksCoreTests:android.content.pm.crossprofile.CrossProfileAppsTest
Change-Id: I44a7ba17ecc81d0d366184b2d411caa7a82de3ef
