Bug: 187429663
Test: Checked ApplicationInfo.hasRequestForegroundServiceExemption()
of a test app, with and without the new attribute set.
Change-Id: I98342a35a82e44327db896c9820806eb3eda5b4c
Change the usage of global compatibility mode enabled state back to
PackageParser first until the tests are ready to ensure the behavior
is consistent.
Bug: 186592266
Test: atest CtsCompatibilityModeTestCases
Change-Id: Ib57886c095a7b2f6e797ccdaa2890f3ad60f5482
Under specific conditions, parceled list can be written in such a
way that writing of new list starts when destination parcel is
just above MAX_IPC_SIZE. In that case "0" is written to parcel to
indicate that there will be no inline items written and writing of
the list will start with extra items.
When unparcelling such list, listElementClass is not determined and
stays equal to null, because it only can be determined if there
were some inline items read first, before switching to extra.
This leads to random unparcelling failures with the following
error message:
Can't unparcel type <typename> in list of type null.
Test: manually verified
Bug: 186193371
Fix: 151481291
Bug: 156514418
Fix: 169191099
Change-Id: I849bf46158b6d9b109139b19b93a6a1ba16ecc77
Use two separate interfaces for flags and single value. This produces
correct API documentation.
Bug: 160605420
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest PackageManagerServiceTest ChecksumsTest
Change-Id: I9a7eaf86af558d8dcfd1636a4baf6a28e2ee79b1
Separate the internal state of AttributionSource from the
class to make it a simple AIDL we can translate automatically
to native - keeping Java and native parts in sync. This
would allow writing a thin native lib for checking attribution
source permissions which would be used to teach camera and
audio about attributions.
Deinfe an AIDL interface for passing around an attribution
source and opr performing permission checker oprations allowing
native and Java permission checks on attribution chains to be
handled. The Java side permission checker functions are in a dedicated
permisison checker service on top of which sits the PermissionChecker.
We expose similar PermissionChecker native APIs sitting on top
of the same remote interface. The nice thing is that we have
native and Java permisison checkers in sync sharing remoting
code and being close in shape.
For now the PermissionChecker in Java is divorced from the
PermissionManager but in T we will consider how to unify them,
either by an extension object on the PermmissionManager or
APIs on the PermissionManager, or another approach, and then
migrate clients off the PermissionChecker APIs.
Sync app ops were not tracked across multiple binder calls which
prevents moving the permission checks in the system server as
this adds one more hop. Now sync ops are propagated backed the
call stack and only the ops for the package are dispatched to
it and the rest are propagated back to the caller, recursively.
bug: 158792096
Test: atest CtsPermission5TestCases
atest CtsAppOps2TestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
Change-Id: Ia5cbd2eb20a2da172a5960afdddd7e467f4bcb0d
Previously, hasRequestRawExternalStorageAccess would return null if the
app doesn't have requestRawExternalStorageAccess attribute in the
manifest. And, return true/false based on the value specified in
manifest.
Based on API review comments, changed the method to
getRequestRawExternalStorageAccess which returns
* RAW_EXTERNAL_STORAGE_ACCESS_DEFAULT if app didn't specify
requestRawExternalStorageAccess attribute in the manifest.
* RAW_EXTERNAL_STORAGE_ACCESS_REQUESTED if the app requested raw
external storage access.
* RAW_EXTERNAL_STORAGE_ACCESS_NOT_REQUESTED if the app requests to
disable raw external storage access
The API is not guarded with any system level API permissions, hence
changing the API to public API instead of system API. Also added
documentation to ensure apps don't misunderstand this API
Bug: 185484514
Test: atest packages/providers/MediaProvider
Change-Id: Ib7e41ab8ee38389bf44a360e4288d03e58ef44cf
PackageManagerService still set global compatibility mode to the
Deprecated PackageParser. We should migrate the usage to the new
ParingPackageUtils.
Also replacing the usage of PackageParser#generateApplicationInfo
in PackageManagerService since we no longer set the compatibility
mode to PackageParser.
Bug: 186592266
Bug: 174723245
Test: atest -p core/java/android/content/pm \
core/java/com/android/internal/content \
services/core/java/com/android/server/pm \
services/tests/servicestests/src/com/android/server/pm
Change-Id: I3f377273e06bd4adbd9311dd3bdc584af0028c77
We now have two notions of profileable:
* profileable from shell: the user can profile the app using ADB-based
tools (e.g. Android Studio or shell) . This is off unless the app
opts in.
* profileable from platform services: trusted platform services can,
in accordance to the app installer's Terms Of Service profile the
app. This is the default unless the app opts out. This is enforced
by the profilers with information provided by the framework.
A new flag <profileable android:enable="false"/> can be used to opt out
of profiling in general. If this is not given, the app is considered
profilable by the platform, but the data will *not* be exposed to the
user via shell or adb. If profiles of the app should be given to the
user (e.g. for using Android Studio), <profileable
android:shell="true"/> can can still be used.
We write whether the app opted out or not to packages.list, to be
consumed by the profilers.
CTS-Coverage-Bug: 186720347
Test: m
Test: on userdebug: /data/system/packages.list for preinstalled, Play
Store installed app and sideloaded app.
Test: on user: atest CtsPerfettoTestCases.
Bug: 170284829
Change-Id: I8d4bbedc043976fd11a95a511bd95a05c7ced7b9
We have a reason to reference this flag from the base framework. Mark
the flag as @SystemApi so it can be referenced.
Bug: 184962595
Test: atest AutoRevokeTest
Change-Id: Id9cb5d32b4afc9c49b8f97996fdfde2d4c239ca4
Several years ago ParcelFileDescriptor.parseMode() was fixed to match
the behavior of fopen(), since developers expect consistent behavior
between managed and native code. FileUtilsTest.testTranslateMode()
verifies that all these modes are correctly translated.
However, this unintentionally changed the behavior of
ContentResolver.openOutputStream(), which only sends the 'w' mode
to the remote process. Developers expect this API to behave like
the FileOutputStream constructor, which always truncates the file
unless opened with the append mode.
Since some remote providers may not be prepared to handle the 't'
mode, this change carefully uses Os.ftruncate() to restore this
expected behavior in all cases.
For other APIs that return opened files, this strategy is applied
to restore the original behavior, but only when the target SDK of
the app is expecting this truncation to take place. The reason for
this is that moving forward our goal should always enable
ContentInterface APIs to be a transparent conversation between apps
without attempting to alter the behavior. Apps talking with older
providers can apply the Os.ftruncate() logic themselves, if
desired, once they target Android Q or higher.
Bug: 157888856, 180680924
Test: atest CtsContentTestCases:ContentResolverTest
Change-Id: Iacec49164c4ce3891db0270635e9f458dea7becd
PackageParsers is marked as Deprecated so any new change should be
in the alternative. Moving the new activity launch mode definition
to ParsingPackageUtils.
Bug: 174723245
Test: atest IntentTests
Change-Id: I841f9d9d5d5555a78902cc3c126ed811dd2ccfc6
Remove other OWNERS from PackageParser.java to disallow future changes.
No new code should go into PackageParser.java except in extreme outlier
circumstances.
Change-Id: I2f663d2ae527beccbd47402492aa51d0cc6f6c13
To allow apps to know when text classification has been completed
on clipboard clips, ClipboardService will now call any
OnPrimaryClipChangedListeners when the classification status
of the primary clip changes.
This change is made as per API council suggestion.
This CL also ensures that the classification status is set on
any related profiles.
Bug: 185177537
Test: atest ClipboardManagerListenerTest
Test: atest ClipDescriptionTest
Test: atest atest ManagedProfileCrossProfileTest#testCrossProfileCopyPaste
Change-Id: I63c44a051d1e8029b6d56b9af5d1e506355a8466
Revert "Prepare AttributionSource to expose to native - native"
Revert submission 14225527-bug-158792096-04/16/21-1
Reason for revert: b/186467053
Reverted Changes:
I16740cc2d:Prepare AttributionSource to expose to native - na...
I4e050e78b:Prepare AttributionSource to expose to native
Change-Id: I83e4091231241c2211edf5745735f4ee993c6680
1. LAUNCHED_FROM_HISTORY, remove the out of date sentence.
2. NEW_DOCUMENT,add information about documentLaunchMode="never"
3. SINGLE_TOP, refer to launch modes for more information.
Bug: 123083574
Test: build
Change-Id: Id4da7be9993aaf1140c1c709a23ae7ed6d1718f5
Separate the internal state of AttributionSource from the
class to make it a simple AIDL we can translate automatically
to native - keeping Java and native parts in sync. This
would allow writing a thin native lib for checking attribution
source permissions which would be used to teach camera and
audio about attributions.
Deinfe an AIDL interface for passing around an attribution
source and opr performing permission checker oprations allowing
native and Java permission checks on attribution chains to be
handled. The Java side permission checker functions are in a dedicated
permisison checker service on top of which sits the PermissionChecker.
We expose similar PermissionChecker native APIs sitting on top
of the same remote interface. The nice thing is that we have
native and Java permisison checkers in sync sharing remoting
code and being close in shape.
For now the PermissionChecker in Java is divorced from the
PermissionManager but in T we will consider how to unify them,
either by an extension object on the PermmissionManager or
APIs on the PermissionManager, or another approach, and then
migrate clients off the PermissionChecker APIs.
bug: 158792096
Test: atest CtsPermission5TestCases
Change-Id: I4e050e78b2361cbf524cc213802e0fef5b487f67
By default, the SplashScreen uses the manifest theme.
This API allows user to change the theme used for the splashcreen for
the whole application.
Test: atest CtsWindowManagerDeviceTestCases:SplashscreenTests#testOverrideSplashscreenTheme
Bug: 185109768
Change-Id: I64e24910f6529a0ea2867b67d7e5963b971164b4
ShortcutManager#updateShortcutVisiblity was a new api intended for S,
due to the recent rollback of shortcut-appsearch integration, this api
can no longer be backed up AppSearch#VisibilityStore. To minimize the
risk of S release we should removed it from public api as opposed to
creating an alternative implementation.
Bug: 185828535, 185177108
Test: manual
Change-Id: Ic9d18237a25b11975f5859836877b9f77e25cc61
Add an overloaded version of Context.sendBroadcastMultiplePermissions() that can
specify BroadcastOptions, it is called by com.android.bluetooth package.
Bug: 182816627
Test: atest AdapterServiceTest
Test: atest AvrcpControllerStateMachineTest
Test: atest BondStateMachineTest
Test: atest MapClientStateMachineTest
Test: atest RemoteDevicesTest
Change-Id: I8bb2d2ed98ece70ebbe9d3a1b549b966d690de4f
