This is based on developer feedback from Google Calendar. Tweak the API
to take in the calling activity.
Javadoc in ActivityTaskManagerInternal's new method is copied from the
existing method.
Bug: 149677845
Bug: 136249261
Test: atest com.android.cts.devicepolicy.CrossProfileAppsHostSideTest#testStartActivityIntent_sameTaskByDefault
Change-Id: I2f2d4d8fd82febf4916ba70a08de5e71c678a1f4
Context: Tuner system APIs and Tuner HAL are adding to R. Tuner hardware
and HAL implementation are required for these new features.
Test: make;
Bug: 139308734
Change-Id: I89f56ee58cdfae447d33cdcd841e0d556e7f6cab
This will be used by the logic that updates the app bucket state of
cross-profile connected apps that declare the crossProfile manifest
attribute.
Also makes the following changes:
- Fixes CrossProfileAppsServiceImplRoboTest by registering the local
service in a different way.
- Removes some code duplication in CrossProfileAppsServiceImpl.
- Some clean-up.
Robolectric tests will be added later. Right now, there seems to be a
problem causing log messages not to appear, making debugging impossible.
Bug: 140808123
Bug: 136249261
Test: atest com.android.server.pm.CrossProfileAppsServiceImplRoboTest
Change-Id: Iefa6b2a7cb7535d5796d5ca8916c10b29c2e0661
Revert "Fix shared libraries not being reported via Reporter"
Revert submission 1198456-slclc
Reason for revert: Fails on luci:
https://ci.chromium.org/p/art/builders/ci/host-x86_64-cdex-fast/3123
Exempt-From-Owner-Approval: pure revert
Bug: 148494302
Reverted Changes:
I46d8d9105: Fix shared libraries not being reported via Report...
I00357cfe0: [DexLoadReporter] Report classloader contexts dire...
Change-Id: Ib58066e8f059642a11d9eaab02ec0b8b3217e487
Update the javadoc after reviewing the new public-facing Javadoc
implemented for the INTERACT_ACROSS_PROFILES work.
Bug: 136249261
Test: no Java changes
Change-Id: I1a669adea2ff47171dbbcbe6e847a3be0cfa7509
If both BaseBundles are empty, we can infer that without needing to
unparcel any of them.
Test: atest FrameworksCoreTests:android.os.BundleTest
Bug: 146037505
Change-Id: I04c28cdd1293227d9887b0c17e178f61328c1959
Parsed the manifest and included in the relevant PackageManager data
structures.
Test: atest RestrictedPermissionsTest
Test: atest RestrictedStoragePermissionSharedUidTest
Bug: 148944140
Change-Id: I785e707aa4c879ea163c1611c1693fea74f4ac82
Also, extends the client-side timeout to match that
in ActivityManagerService.
Also, fixes an ANR that could occur if getType is called for
an unknown content provider
---------------
Revert "Revert "Prevents an NPE when content provider is slow to start""
This reverts commit 3a54effffd.
Reason for revert: Roll forward of the original CL,
with a fix for the regression it caused
Original commit 140fc2e9c9
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Fixes: 148987678
Change-Id: Ic60acceaabbf6b32c71d0b8bdf831a7d1f13d392
This change enables the app enumeration feature by default. This change
is very likely to break some tests that manually install APKs. The fix
for them is generally easy: add the --force-queryable flag to the shell
command.
This change will also make some apps targetting R unable to see other
apps that are installed or sideloaded on the device.
go/app-visibility-playbook outlines the steps needed to re-gain that
visibility.
Fixes: 136675067
Test: atest AppEnumerationTests AppsFilterTest
Test: atest CtsCalendarProviderTestCases
Test: atest CtsAccountManagerTestCases
Test: atest CtsContentTestCases
Test: atest CtsPermission2TestCases
Test: atest CtsAppSecurityTests
Test: atest CtsAppTestCases
Change-Id: I9db3c0768416dd7ba24108b2a142a24672dab561
UX wants special UI to explain permissions revoked because of auto-revoke,
so we need a way to mark them.
Bug: 146513245
Test: presubmit
Change-Id: Idb753c5036ffe94995773756f329ea26d7c40b64
- Adds "_" in variable name for consistency with feature string
- Adds documentation on what the feature is used for
Bug: 149475852
Test: None
Change-Id: I6eca279df8409de1155cd7014647a705d0d31d6f
At the moment classloader contexts are incorrectly computed in the
PackageManager for secondary dex files. There are two issues:
(1) The wrong computed classLoaderContext will be reported for a secondary
dex file if it was loaded at the same time as a primary dex file
- This is due to the continue statement that doesn't increment
dexPathIndex
(2) If a secondary dex file was loaded with a shared library then that
shared library info isn't passed through the dex load reporting
infrastructure, and thus its classloader context is incorrectly computed
in PackageManager.
In order to fix the issues described above & prevent further classloader
context computation divergences between the package manager and the
runtime, lets compute the classloader context in the runtime at dex load
time and report the expected classloader context directly to
DexLoadReporter (and thus the package manager).
Notes: This is mostly just a refactor (i.e. there are a lot of line
changes, but functionally speaking this set of CLs doesn't do much
except change where the classloader context is computed)
Addendum: The bugs described above could also be fixed by:
- changing DexLoadReporter to report information about shared libraries that
the reported classloaders depend on to PackageManager
- Teach DexoptUtils.processContextForDexLoad about shared libraries
- Fix dexPathIndex calculation in DexManager
I opted for this set of changes instead because this reduces the
possibility of context computation divergence between the framework and the
runtime. Additionally it feels more "solid" that the classloader context
is now computed directly when a dex file is loaded, rather than the
context recreated later on in the PackageManager.
Test: atest com.android.server.pm.dex.DexManagerTests
Test: atest com.android.server.pm.PackageManagerServiceTest
Test: Install app depending on shared library & uses secondary dex
files; adb shell pm bg-dexopt-job; launch app and see odex file
successfully loaded (from smaps/no logcat errors)
Bug: 148494302
Change-Id: I00357cfe086ff149f92c1078c6df6daa713c8f7c
* changes:
Add a TunerResourceManagerService as an Android System Serivce.
Add Lnb related APIs into the TunerResourceManager interface
Add Cas related APIs into the Tuner Resource Manager
Adding ITunerResourceManagerService interface into android.media.tv
Per API council guidance, setLoaders, getLoaders, and clearLoaders
are no longer part of the public API. addLoader and removeLoader
are now consume variadic loaders.
Bug: 142716192
Test: atest FrameworksResourceLoaderTests
Change-Id: If29d47b526ae6acd582b14206b2c6372f3c497be
v4 is a streaming add-on to the existing v2/v3 schemas.
Flow:
- APK is signed with v2/v3 and v4 signature blocks,
- on installation, v4 signature bytes are stored next to the APK in
hidden block,
- on each read from APK, kernel verifies the v4 signature using
fs-verity-like code,
- on parsing/verification, we extract certificates from kernel and
compare them with certificates extracted from v2/v3 signature block.
By doing this we are making sure that v4 signature is produced by developer and original APK bytes are not changed.
Test: atest PkgInstallSignatureVerificationTest
Bug: b/136132412 b/133435829
Change-Id: Ia2a56c82c9864bf65e1338700dfe51abf6800deb
This mean both switch on/off and add/remove profiles.
The broadcasts already exists for registered receivers, this adds them
for manifest receivers with INTERACT_ACROSS_PROFILES permission and
crossProfile attribute.
The MANAGED_PROFILE_REMOVED broadcast is sent to all application with
android:crossProfile="true". Any cross profile app may be impacted, and
there is no possible transfer of information as the account is already
deleted at the time the signal is emitted.
Change-Id: I17fb9a01b70b28845c5d6aacdcdd497a82391474
Fix: 145135525, 145598120
Test: Demo-app using Digital Wellbeing (automated test underway).
Test: atest com.android.cts.devicepolicy.CrossProfileAppsPermissionHostSideTest
Test: atest 'com.android.cts.devicepolicy.QuietModeHostsideTest#testBroadcastManagedProfileAvailable_withCrossProfileAppsOp'
Test: atest 'com.android.cts.devicepolicy.QuietModeHostsideTest#testBroadcastManagedProfileAvailable_withoutCrossProfileAppsOp'
This service is used to interact with TunerHAL interface and the Tuner
framework to manage the Tuner resources currently used on the device.
Tuner framework claims resource from this service. The service will
handle the requests from multiple applications based on their priority.
Sepolicy changes are in https://android-review.googlesource.com/c/platform/system/sepolicy/+/1161873
Test: cuttlefish
Bug:
Change-Id: Ifedc4e6f120e711aadffdf715d8720e0b64fbe16
This is a follow up CL to a CL [1] that added one more state dump from
ApplicationInfo but forgot to take care of prefix handling.
[1]: I11b5d9919e4463cdaf89826360bc12ae68dbd0af
f9b99f5fa1
Bug: 142538125
Bug: 142537267
Test: Ran the following command to see "crossProfile"
is aligned with other outputs from ApplicationInfo.
adb shell dumpsys input_method
Change-Id: I629d4653b0d9109615feb02718d1228cf4f850d7
This is required for the provisioning cross-profile consent screen which
is used to take some apps off INTERACT_ACROSS_USERS.
Hidden API CrossProfileApps#setInteractAcrossProfilesAppOp is changed
from requiring the broad app-op permissions to requiring
CONFIGURE_INTERACT_ACROSS_PROFILES. It then clears identity before
calling into AppOpsManager. For convenience, we also allow apps (such as
Settings) with the broader app-op permissions to continue to call this
method; in that case, we simply don't clear the identity and let
AppOpsManager check the permissions (so we allow AppOpsManager to set
the requirements if you don't have the new
CONFIGURE_INTERACT_ACROSS_PROFILES).
The CL also adds 'withCleanCallingIdentity' support to
CrossProfileAppsServiceImpl and moves over existing calls.
Bug: 136249261
Bug: 140728653
Test: atest --verbose com.android.managedprovisioning.provisioning.crossprofile.CrossProfileConsentActivityRoboTest
Change-Id: Ibd304563dd1ef5f16784e3502be5ef1ec4675b63
