Also make these configurable so we have the flexibility to change it if
necessary.
Setting the policy inside ActivityManagerService is not ideal, as that
means that AMS is the only place where the policy in ApplicationInfo is
correct. It should really be set inside PackageManagerService. However,
if it's set there, it would get out of date when the settings change, and
we'd have to update inside AMS anyway. So putting it only here seems ok
for now.
Test: $ adb shell settings put global hidden_api_policy_pre_p_apps 2
Test: $ adb shell settings put global hidden_api_policy_p_apps 2
Bug: 64382372
Change-Id: Ic4cbbb1e6464623e90c17ae08c0b6cbbe0dfa125
Earlier setPackagesSuspended ignored the rest of the paramters when
suspend state did not change. This was a problem because then there was
no good way to update the other parameters without unsuspending the app,
which is not desirable.
Removed setSuspendedPackageAppExtras as now they can be update with this
api.
Also sending broadcasts when packages get unsuspended due to suspending
package removed.
Test: Existing tests pass:
atest com.android.server.pm.PackageUserStateTest
atest com.android.server.pm.SuspendPackagesTest
atest com.android.server.pm.PackageManagerSettingsTests
Bug: 77522553
Change-Id: I72a3c228d3d65c430e242da97b2bc6997ec6a135
Prior to this change there was a chance that an updating app would not
exist in mPackages and cause a permission check for that app to fail.
This change moves all permission checks to use mSettings and the cached
package it contains to do the checks.
Change-Id: I0717bddbb08b1d0dbab3ea79fa0d2067aa858753
Fixes: 76228188
Test: Manual - system starts, permission checks work before / after update
Address API review by describing relationship between the
PackageManager.hasSigningCertificate() methods and the PackageInfo
GET_SIGNING_CERTIFICATES method, as well as differentiating the
UID documentation from the package-name based one.
Bug: 74831566
Test: None, doc change.
Change-Id: I11c556325f9b2efbc2e5e1cf896b9c58db092ae8
Use the common rethrowFromSystemServer() pattern. Carefully only
throws for calls going to system_server; leaves existing behavior
intact when calling a ContentProvider.
Bug: 77671218
Test: builds, boots
Change-Id: Ie5e0763fb5e62b832f2b6a03c8f9d72dab3bf89a
It seems pretty unlikely that we'd ever want to disallow access to the
light greylist in P, since doing do would break do many apps. We don't need
this policy here as an opt-in for apps now, since the StrictMode work will
achieve the same thing.
Instead, make a "just warn" policy which allows access to all APIs, but
leaves the detection and logging logic in place. This gives us the option
of disabling enforcement, but still gathering logs to find out which apps
use which APIs.
Bug: 77517571
Test: Boot device
Test: Hardcode policy of HIDDEN_API_ENFORCEMENT_JUST_WARN and verify log
Change-Id: I588f347716a79ac5887b74763c8afc16b3be699b
Added an AlertActivity to intercept the start for an activity belonging
to a suspended app. More details will be shown if the suspending app
also defines an activity to handle the API action
SHOW_SUSPENDED_APP_DETAILS.
Test: Added tests to existing classes. Can be run via:
atest com.android.server.pm.SuspendPackagesTest
atest com.android.server.pm.PackageManagerSettingsTests
atest com.android.server.pm.PackageUserStateTest
Bug: 75332201
Change-Id: I85dc4e9efd15eedba306ed5b856f651e3abd3e99
This change plumbs the original uid of a startActivity call through to
PackageManagerService#queryIntentActivitiesInternal so that we properly
filter.
Test: manual - launch previously failing instant app
Change-Id: I0a62195f67c2e08315ce2d87f1d8c516c2327ba6
Fixes: 77489209
This compatibility change ensures that apps built for pre-P that rely
on reflection to access ApplicationInfo#versionCode don't crash. The
move to long version code introduces a new field and all modifications
of the field are wrapped in a method that ensures both the new and old
fields are set appropriately.
Test: manual - impacted app runs
Change-Id: I5fb37c65b0fb04042dda12479d1e1a76590daa3d
Fixes: 74393568
This means that APKs signed with the platform cert are allowed to use
hidden APIs, even if they are not on the package whitelist, and if they are
not in the system image. It will also allow a number of packages to be
removed from the package whitelist.
Also remove all platform cert signed apps from the package whitelist, as
there is no longer any need for them to be in there.
Bug: 64382372
Test: device boots
Change-Id: Id805419918de51f946c1f592581bab36ae79de83
Suspended packages get their activities intercepted at start, but they
can still show system_alert or toast_windows from other components.
These need to be hidden when the app goes into suspend and unhidden when
it is unsuspended.
Test: atest com.android.server.wm.WindowStateTests
Bug: 77498821
Change-Id: I9ac446f20feb23e2090ba306b4435c46b9aeec95
Add a new capability that may be granted to past signing certificates
after changing to a new signing certificate that will allow applications
to go back to a previous signing certificate. This capability is
intended to not be granted, but may be added later in the event that
a signing certificate change caused undesirable behavior.
Bug: 73927694
Test: PkgInstallSignatureVerificationTest
Change-Id: I7453a2da00e740a55de45e7b144f308a9bc33772
(cherry picked from commit a1d0cf74f9)
The suspending app can provide a Bundle of information to be used by the
launcher for handling suspended packages. Added APIs:
- getSuspendedPackageLauncherExtras(String, UserHandle): To retrieve
the launcher extras for the given package and user.
- Callback#onPackagesSuspended(String[], UserHandle, Bundle): A
callback that will be invoked with the package names and the launcher
extras whenever sent packages are suspended.
Test: atest com.android.server.pm.SuspendPackagesTest
Bug: 76119578
Change-Id: I505d134809639a57c3314f994af34d576d905e74
Bug: 72443754
Fix: 72443754
Test: atest ${ANDROID_BUILD_TOP}/frameworks/base/services/tests/servicestests/src/com/android/server/content/SyncOperationTest.java
Test: Manual test with contacts sync:
Precondition: Put the contacts sync in RARE bucket.
adb shell dumpsys deviceidle tempwhitelist -r com.google.android.syncadapters.contacts
adb shell am make-uid-idle com.google.android.syncadapters.contacts
adb shell am set-standby-bucket com.google.android.syncadapters.contacts 40
Test 1: Toggle contacts sync from the Settings -> Account
- Make sure a sync happens.
Test 2: Mutate a contact on the WEB
- Sync is scheduled, but won't run because it has no network access.
- am set-standby-bucket com.google.android.syncadapters.contacts 30
- Sync run runs.
Test 3. adb shell requestsync -n ACCOUNT -t com.google -a com.android.contacts
- Sync is scheduled but won't run.
Test 4. adb shell requestsync -n ACCOUNT -t com.google -a com.android.contacts -f
- Sync is scheduled but it still won't run.
Test 5. adb shell requestsync -n ACCOUNT -t com.google -a com.android.contacts -F
- Sync now runs
Change-Id: I1eb972ed321d2a1a782ae23ccb806671926d3e6b
Add a feature flag to find out if Device ID attestation is supported or
not, as it is an optional feature.
Otherwise, the cts tests could not meaningfully say if the device
correctly supports this feature or not.
Bug: 72642093
Bug: 73448533
Test: Modified CTS tests.
Change-Id: Ia6ba47a5262412ab24afa700d1b891be10a21df9
This CL adds the basics to set black, dark gray or light gray list
enforcement, rather than just black as before. It's not possible to
actually set the policy per-package yet.
PackageDexOptimizer still uses a single bit, for API checks on/off, rather
than the new enum. It assumes blacklist enforcement internally. This can
be improved in a follow up CL.
(cherry-picked from commit e52130ae4c)
Test: m
Test: Boot device
BUG: 73337509
Change-Id: Ieb4bd9cc439c6a5b8fb9424d8902d8b46aec309f
Merged-In: Idd73c9938592c5c4d67cfb9efefdffed0dd5f262
Grant the camera permission to the active LUI app since LUI uses QR scanner
to download profile.
Before it, revoke the previously granted permissions first.
Bug: 35068517
Test: test on phone
Change-Id: I2db9597eed423835b9499ef6000579b5ee5b2cb6
Added new broadcast actions MY_PACKAGE_SUSPENDED and
MY_PACKAGE_UNSUSPENDED, which are sent to the package that is affected
by the suspend state change. A suspended package also receives a bundle
of app extras to pass more information. This makes it easier for
packages to deal with being suspended/unsuspended.
Also updated some existing documentation to make it clearer.
Test: atest com.android.server.pm.SuspendPackagesTest
Bug: 75036698
Change-Id: I772cf0c023669bc946e07ced4ebccfa74f6835b2
For compatibility, had to continue returning null when drawables could
not be decoded. Fix annotation to match pre-P behavior (the behavior
was reverted separately).
Fixes: 69543526
Test: make
Partial revert of Ib01eca970c5c9969998ce5b265b120aa7048b41a
Change-Id: I5f612f47793c3f04cf9874e13efdc13397ddd4e8
The Telephony Data Service is a privileged service
that provides Data capabilities *to* Telephony. A
data service that provides IWLAN may also use WiFi
as an underlying connection that tunnels Telephony
data services over WiFi using IPsec. The carrier-
config-driven permissions model causes the
framework to bind to an appropriate Telephony Data
Service, for a given carrier, and that Data Service
is responsible for providing Cellular data. Thus,
The TelephonyDataService needs sufficient
permissions to access cellular info necessary for
performing signalling for IWLAN. This includes
Phone state information and location information
such as the current Wifi access points and the
current cell towers. In addition, a Telephony
Data Service may require access to IPsec if the
data service uses the Android API to establish
IPsec, which is optional today.
Bug: 66955045
Test: wip
Merged-In: Ibe4f7806a47e2a50999376ff0a5a07dc5b332953
Change-Id: Ibe4f7806a47e2a50999376ff0a5a07dc5b332953
