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
Privileged apps can now be located in the vendor partition. This is
mainly to move SoC-dependent apks to the vendor partition so that the
system partition becomes more generic.
Like existing privileged apps in the system partition, the list of
privileged apps in the vendor partition and the permissions they are
using must be white-listed. The whitelist can be specified via
<privapp-permissions> tags in one of /vendor/etc/permissions/*.xml
files. Note: vendors can only white-list the apps in vendor partition,
but not the apps in system partition.
This change also introduces a new flag 'vendor-privileged' to the
permission protection level. It is used to expose platform-defined
permissions to the privileged vendor apps. If a platform permission does
not have this flag, it is not granted to vendor apps even when the app
is privileged and white-listed.
Bug: 35301609
Test: `mm` under frameworks/base/tests/privapp-permissions
adb sync && adb reboot
adb shell cmd package \
com.android.framework.permission.privapp.tests.vendor
shows that the app is installed.
android.permission.BIND_IMS_SERVICE is in the installed permissions list
android.permission.MANAGE_USE is not in the installed permissions list,
but is in the requested permissions list.
Change-Id: I196375aaaa9ea3a2ba15686ef08cf3f70ade7046
When emitting a method or field, verify that we're able to reference
all mentioned types. This ensures that we don't accidentally
reference undefined classes/interfaces.
Test: manual inspection of API files
Bug: 69791141
Change-Id: I84e0c87fe83daa118661f61dbdf17b58ea5282d4
