Now it's unified with callback FS connector - we are passing the
callback pointer directly to dataloader. This restricts access only
to methods we want and only by someone we want.
Bug: b/153468113
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest
Change-Id: Ib557ebbe7c6c5ce92140eb20534a3626b3ac96d3
Most apps that declare the INTERACT_ACROSS_PROFILES permission do
not have it granted, but get the app-op instead. We do not
normally want platform-signed apps that are actually given the
permission to appear in the user-configurable section in Settings,
so we remove them from the return value of
canUserAttemptToConfigureInteractAcrossProfiles in this CL.
Note that OEM can choose to allow some platform-signed apps to be
user-configurable by including them in their OEM whitelist file.
This CL respects that and allows these apps to be configured by the user,
despite being granted the permission. If the user rejects the app-op,
PermissionChecker correctly returns false.
Bug: 149742043
Test: atest CrossProfileAppsServiceImplRoboTest
Change-Id: I693338507eec9cdc0ba10a3584e994a58d2d113c
There are prebuilts in the tree and perhaps APKs in general
which don't conform to the manifest checks added in R, so the code
that parses the APK to verify v1 vs v2 needs to actually query
PlatformCompat to do the proper targetSdkVersion check and allow
the APK through if it's not updated yet.
A related change to default enabled inside ParsingPackageImpl to
true was also made, as if any malformed APK was allowed through
without an <application> tag, it would never hit the code
where enabled gets assigned to default true.
Any further errors spit out by this test are critical and need to
updated so that their APKs can be installed on R.
Bug: 153058196
Test: manual verify error behavior with broken APK
Test: atest com.android.server.pm.parsing
Change-Id: I2b117f2098d8bd62b92921178a098e838b55b06d
direcly through aidl.
As part of the effort to simplify the implementation of
LauncherAppsService, We create ShortcutQueryWrapper, a parcelable
object that wraps ShortcutQuery and pass it to LauncherAppsService
directly.
Bug: 148104408
Test: atest ShortcutQueryTest
Merged-In: I2e2ccaf38ef6bd558b4b02e647a7e263c7e612a9
Change-Id: I2e2ccaf38ef6bd558b4b02e647a7e263c7e612a9
(cherry picked from commit d043004cee)
* changes:
Add mPackageParserCallback assignment in TestParams constructor
Revert "Revert "Allow overriding the label and icon of a MainCom..."
Revert^2 "Add test constructor to PackageManagerService"
Package parser throws an exception while it's in the onlyCoreApp
state and parsing an non-core app. Catching the parser exception
during scanning apex packages, if the apex is without coreApp
attribute and device is in minimal boot state.
Also, updates package parser to V2 for the staging manager.
Bug: 151296698
Test: atest ApexManagerTest
Test: atest StagedInstallTest
Change-Id: I098e08d4064812465a29086c3fde1a55348bcae5
This changes removes FrameworkResourceLoaderTest from frameworks/base
before it is moved to CTS.
Bug: 152979463
Test: atest CtsResourcesLoaderTest
Change-Id: I4b899564ab93472cb6d2a5ed0917026753c2827f
Revert submission 10921255-revert-10403399-pkg-override-label-icon-DCRMJNYAKW
Reason for revert: Re-submit broken change with included fix.
Reverted Changes:
Ic5c719cbb:Revert "Allow overriding the label and icon of a M...
Id9d37e661:Revert "Add test constructor to PackageManagerServ...
Bug: 113638339
Change-Id: I4f5247f528f62c175bd34f0e4cb16c9456c8afe4
Revert submission 10403399-pkg-override-label-icon
Reason for revert: Droidcop: Potential culprit for Bug 152987173 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted Changes:
I4b20ec294:Add test constructor to PackageManagerService
Id48eda556:Allow overriding the label and icon of a MainCompo...
Change-Id: Ic5c719cbbd904f8cc1c5c6a6d826c7b807f03e39
Two package parsing issues have been promoted to failures in R:
a missing <application>/<instrumentation> tag, and an empty
"android:name" attribute. The latter due to a bug in the parsing
code.
These need to be gated by targetSdkVersion so that APKs built for
previous versions can still scan/install properly. This change
introduces support for this through a framework that leverages
@ChangeId to introduce individually toggle-able errors, in
case a developer needs to install an app that isn't completely
migrated for a new SDK version yet.
The ignoreError method was removed from ParseResult as the errors
it was used for were manually compared to PackageParser and it's
likely they can be hard errors without breaking anything.
This also adds tests for general ParseInput/Result behavior.
Exempt-From-Owner-Approval: AppIntegrity already approved in older PS.
Bug: 150776642
Test: atest android.content.pm.parsing.result.ParseInputAndResultTest
Test: atest com.android.server.pm.parsing.PackageParsingDeferErrorTest
Test: atest com.android.server.integrity.AppIntegrityManagerServiceImplTest
Test: atest com.android.server.pm.parsing
Change-Id: Id53a2e65f6e5e4dee9a41cc77007275b3a220ac3
Normally these attributes are immutable once parsed from the
AndroidManifest.xml of the corresponding app, but there exists
a requirement for a special privileged app to change this
at runtime.
This change allows overriding label/icon of any component
(Activity, Receiver, Provider, Service) that belongs to the
app declared as R.string.config_overrideComponentUiPackage.
This role can only be taken by 1 package, which must be a system
app, and state is stored per-user. Different users with potentially
different requirements can show a different label/icon.
Co-authored-by: Yoshiaki Naka <yoshiaki.naka@sony.com>
Bug: 113638339
Test: manual verify behavior using test app
Test: atest PackageManagerComponentOverrideTests
Change-Id: Id48eda55650ffc88854423498675b001c2500259
Per discussion of go/modularize-rollbackmanager, module code can't use
hidden APIs. Considering CPU and memory impact, we decide to replace
IntArray with List<Integer> to get rid of the use of hidden APIs.
Bug: 150347230
Test: atest RollbackUnitTest
atest RollbackStoreTest
atest AppDataRollbackHelperTest
Change-Id: Ica3b0d3bd0eb930cc6cb89f06a7dd9a89202fcf3
The UserSystemPackageInstaller (USPI) uninstalls system
packages that are not needed, depending on the user type.
When that determination changes (or the feature is disabled)
it can also re-install those packages.
This cl specifies when it is appropriate for USPI to actually
perform the (un)installation.
1.
Introduces uninstallReason: records the reason why a package
was uninstalled from a given user. Right now, the only values
are UNKNOWN and USER_TYPE. The latter indicates that the USPI
system uninstalled the package. If the USPI whitelist changes
(or the USPI feature is disabled), uninstalled packages will
only be installed by USPI if the uninstallReason was USER_TYPE.
Any further uninstalls (e.g. by ManagedProvisioning) will reset
the uninstallReason to UNKNOWN, so USPI will no longer install
such packages in the future.
This prevents USPI from reinstalling system packages that other
mechanisms (such as ManagedProvisioning) uninstalled.
2.
USPI will uninstall a system package if it is blacklisted, but
only if that system package is new, i.e in two circumstances:
a. on first boot
b. on an OTA where the package was not present prior to the OTA
Bug: 143200798
Test: atest UserSystemPackageInstallerTest
Test: Confirmed (un)installations during manually simulated OTAs
Change-Id: Ia0714d1faa8f7c79082f2cc93a92ae36b9a4c918
Merged-In: Ia0714d1faa8f7c79082f2cc93a92ae36b9a4c918
The UserSystemPackageInstaller (USPI) uninstalls system
packages that are not needed, depending on the user type.
When that determination changes (or the feature is disabled)
it can also re-install those packages.
This cl specifies when it is appropriate for USPI to actually
perform the (un)installation.
1.
Introduces uninstallReason: records the reason why a package
was uninstalled from a given user. Right now, the only values
are UNKNOWN and USER_TYPE. The latter indicates that the USPI
system uninstalled the package. If the USPI whitelist changes
(or the USPI feature is disabled), uninstalled packages will
only be installed by USPI if the uninstallReason was USER_TYPE.
Any further uninstalls (e.g. by ManagedProvisioning) will reset
the uninstallReason to UNKNOWN, so USPI will no longer install
such packages in the future.
This prevents USPI from reinstalling system packages that other
mechanisms (such as ManagedProvisioning) uninstalled.
2.
USPI will uninstall a system package if it is blacklisted, but
only if that system package is new, i.e in two circumstances:
a. on first boot
b. on an OTA where the package was not present prior to the OTA
Bug: 143200798
Test: atest UserSystemPackageInstallerTest
Test: Confirmed (un)installations during manually simulated OTAs
Change-Id: Ia0714d1faa8f7c79082f2cc93a92ae36b9a4c918
