This ensures that any calls made (intentionally or not) in the system
server using the Compatibility (in-app process) gating APIs will always
return true, and log the gated feature.
Bug: 143591326
Test: m
Merged-In: I96792cf852f4167fc39d5055704f8617efaae25e
Change-Id: I96792cf852f4167fc39d5055704f8617efaae25e
Introduce a platform_compat_native service that just calls the
platform_compat service.
The new service is needed as it needs a slightly different (more
limited, no ApplicationInfo in cpp) aidl API, and a class can only
extend one stub.
Test: Call the service from dumpsys.cpp (http://aosp/1142055)
Bug: 138275545
Change-Id: Ic46cc34b4c1dd4ebc6bcc996fb3f8503607214ac
Merged-In: Ic46cc34b4c1dd4ebc6bcc996fb3f8503607214ac
Refactor NetworkStackClient class to move the module service binding &
network stack process death monitoring to a separate class. This class
will only instantiated in the SystemServer process.
The new class |SystemServerToNetworkStackConnector| will be used from
the client classes corresponding to each module running on the network
stack process (NetworkStackClient, WifiStackClient, etc)
This has 2 main advantages:
a) Reduces code duplication (Otherwise the various Client classes need
to replicate the service bindding & process death monitoring).
b) Central crash recovery for the network stack process (Otherwise the
various Client classes will trigger multiple recovery for a single
network stack process crash).
Bug: 135679762
Bug: 140006229
Test: Device boots up & connects to wifi networks.
(cherry-picked from 7e6f5f5e080f2d2ae3ef0397c21bd666f5ce4d31 & applied
aosp/977048)
Change-Id: I673581b0067b9a3f72dd68a3ab622c18183ebd2e
Merged-In: I673581b0067b9a3f72dd68a3ab622c18183ebd2e
Refactor NetworkStackClient class to move the module service binding &
network stack process death monitoring to a separate class. This class
will only instantiated in the SystemServer process.
The new class |SystemServerToNetworkStackConnector| will be used from
the client classes corresponding to each module running on the network
stack process (NetworkStackClient, WifiStackClient, etc)
This has 2 main advantages:
a) Reduces code duplication (Otherwise the various Client classes need
to replicate the service bindding & process death monitoring).
b) Central crash recovery for the network stack process (Otherwise the
various Client classes will trigger multiple recovery for a single
network stack process crash).
Bug: 135679762
Test: Device boots up & connects to wifi networks.
(cherry-picked from 7e6f5f5e080f2d2ae3ef0397c21bd666f5ce4d31 & applied
aosp/977048)
Change-Id: I673581b0067b9a3f72dd68a3ab622c18183ebd2e
Merged-In: I673581b0067b9a3f72dd68a3ab622c18183ebd2e
It's needed by ActivityManager and PackageManager.
Also use a constant in Context for the name.
Test: flashed device with ag/9025572 and ag/9204795 and the platfrom
compat was accessible.
Bug: 137769727
Change-Id: Ie1130a3f0bdd1769fe0755db0089702ea64d9db6
Merged-In: Ie1130a3f0bdd1769fe0755db0089702ea64d9db6
It's needed by ActivityManager and PackageManager.
Also use a constant in Context for the name.
Test: flashed device with ag/9025572 and ag/9204795 and the platfrom
compat was accessible.
Bug: 137769727
Change-Id: Ie1130a3f0bdd1769fe0755db0089702ea64d9db6
Merged-In: Ie1130a3f0bdd1769fe0755db0089702ea64d9db6
Restricted permissions cannot be held until whitelisted. In
a P -> Q upgrade we grandfather all restricted permissions.
However, the whitelisting code runs after the internal update
of permission happens for the first time resulting in a
revocation of the restricted permissions we were about to
grandfather.
The fix is to not deal with restricted permission when updating
the permissions state until the permission controller has run
the grandfathering logic and once the latter happens we do run
the permission update logic again to properly handle the
restricted permissions.
Bug: 138263882
Test: atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
P -> Q upgrade preserves grandfathered restricted permissions
P -> Bad Q build -> Q fixes up broken fixed restricted permissions
Change-Id: Iaef80426bf50181df93d1380af1d0855340def8e
(cherry picked from commit 0b41c8940a44a9eff4b277ce019a1ffdb3a44b7e)
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Change-Id: Ie8cfba397930a1bd5ec947f4834478bb629fa640
Merged-In: I19e5fbfefcf59e0b53b197ea8e9e3cb78439b4c4
This allows PlatformCompat to be called from anywhere in the platform.
In follow-up CLs, we'll define permissions for each method and/or
filtering rules to prevent abuse from apps.
Test: m
Bug: 137769727
Change-Id: I19e5fbfefcf59e0b53b197ea8e9e3cb78439b4c4
Merged-In: I19e5fbfefcf59e0b53b197ea8e9e3cb78439b4c4
This fixes the accidental removal (change ID
If2e6afe21f6efcb141f3a4428ff9154b68f08a1d)
of a call to ActivityManagerService.enterSafeMode, ensuring that
when the rest of the device is in safe mode, ActivityManagerService
and PackageManagerService are made aware of it and properly filter
app launches.
Fixes: 137052912
Test: manual; safe mode correctly blocks 3p apps
Change-Id: Ie2caf6d2fd74b241927a245393fb31658201962f
Merged-In: Ie2caf6d2fd74b241927a245393fb31658201962f
Remove the ability to turn off TimeDetectorService. After
http://r.android.com/1000492 it will be required in all cases.
Also remove [Old|New]NetworkTimeUpdateService as the expected
changes have not been implemented.
Bug: 133492648
Test: build only
Merged-In: Iad7ff59b19fa54750831819c68b7b733e5763902
Change-Id: Iad7ff59b19fa54750831819c68b7b733e5763902
This fixes the accidental removal (change ID
Ibe849f56f5fe8af1415dc6c85b484d0edca518ec)
of a call to ActivityManagerService.enterSafeMode, ensuring that
when the rest of the device is in safe mode, ActivityManagerService
and PackageManagerService are made aware of it and properly filter
app launches.
Fixes: 129781631
Test: manual; safe mode correctly blocks 3p apps
Change-Id: Ie2caf6d2fd74b241927a245393fb31658201962f
Similar to I3876c41e6d0e41d044a5b1d5e57f894c7fb4fb0e and
I69067fbbb8be4e421918c18b67269044fab51b3e where we pause
the watchdog because dexopting and moving A/B artifacts can take a while,
here scanning packages can take a long time depending on the number of
apps installed on the device.
Bug: 135103243
Test: Manually tested by adding an artificial sleep in
PackageManagerService#main and verified that watchdog was not triggered
Change-Id: Ia5b2b5741194a33f7cd09e79c0904696ce546026
Merged-In: Ia5b2b5741194a33f7cd09e79c0904696ce546026
Similar to I3876c41e6d0e41d044a5b1d5e57f894c7fb4fb0e where we pause
the watchdog because dexopting can take a while, here moving A/B
artificats can take a long time.
Bug: 134062700
Test: Manually tested by adding an artificial sleep in
OtaDexoptService#main and verified that watchdog was not triggered
Change-Id: I69067fbbb8be4e421918c18b67269044fab51b3e
This check was intended to be removed once we had the ability to add the
Bluetooth systemFeature check. Removing it now so emulator can enable
bluetooth
Bug: 132627197
Test: Built and ran emulator locally to confirm BTService running
Change-Id: I3e0606e0e4154299e65e5f62d8a1720922d796ad
Since we start the watchdog early during boot, we may have some false
positives where the watchdog thinks a thread is blocked but it
is just running a long task. This cl enables us pause the watchdog
triggering for the current thread and resume the triggering after
the long running task. An alternative would be pausing for a specified
duration without an explicit resume but that may be difficult
to find an upper bound for tasks across all devices.
For now the primary long running task is dexopting which happens on
the main thread during boot. We pause the watchdog triggering on the
main thread and resume afterwards.
Test: Verified with logs that pausing the Watchdog pauses triggering
and resuming resumes triggering
Bug: 132076426
Change-Id: I3876c41e6d0e41d044a5b1d5e57f894c7fb4fb0e
The following device admin related events now generate interruptive notifications:
1. Admin-triggered remote bug report collections (requires user action)
2. Remote work profile wipe - post wipe notification
3. The enabling of Network logging
4. Admin remotely installs/removes an APK
5. Work profile needs unlocking after boot
Test: manual
Change-Id: If5a51123c05b15e544a31ac7ec6b42ec831a1ccc
Fix: 130623009
Fix: 120770584
Fix: 118810015
Starting TestHarnessModeService outside of the FRP block will allow OEMs
to provide their own implementation of
PersistentDataBlockManagerInternal in LocalServices, which will allow
them to satisfy all CTS requirements even without supporting Factory
Reset Protection.
Bug: 131439285
Test: make && adb shell cmd testharness enable
Change-Id: If3ea192a22105716cab1dbed832f8c20b51058b7
(cherry picked from commit 87ac4ea4a586457f84a9534526486ace4152b635)
Propagates any changes to the display config made inside any
framework overlay. Notably any display cutout adjustments.
Partial revert of ag/I844de9e09eb1464ae112e1b480d21cf662a026e0
with the OMS method moved into AMS.
Bug: 130444380
Test: manual test with simulated cutout on blueline device
Change-Id: Ifa24954352fa5e92816baa8d669b9abedc4f4ab8
* Split populateActivePackagesCacheIfNeeded into populateApexFilesCache
and parseApexFiles.
* populateApexFilesCache does an IPC to apexd , while parseApexFiles
does the heavy lifting of parsing apex files and extracting signature;
* Split is required because during PackageManagerService boot-sequence
we need to know list of apex packages, and in order to get that
information we don't need to parse apex files.
* Both populateApexFilesCache and parseApexFiles are enquened to run in
ApexManagers own HandlerThread so that they don't block other tasks in
system servers boot sequence.
* Changed ApexManager to use CountDownLatches instead of locks to
synchronize between thread, as they are more modern and easier to use.
Also did some perf testing on blueline by running
atest google/perf/boottime/boottime-test:
Without https://googleplex-android-review.git.corp.google.com/q/Ic7e5e14ed2d02d3685fd39bb70bc9423ae78f18e:
SystemServerTiming_StartPackageManagerService_avg: 2767.2
With what is currently in qt-dev:
SystemServerTiming_StartPackageManagerService_avg: 3728.4444444444443
Without splitting into populateApexFilesCache and parseApexFiles:
SystemServerTiming_StartPackageManagerService_avg: 3247.5
This change:
SystemServerTiming_StartPackageManagerService_avg: 2894.7
Test: device boots
Test: atest CtsStagedInstallHostTestCases
Bug: 131611765
Change-Id: I980700cd785c22d7f1ace294bb5456056d68baaa
The system server can deadlock without making progress during early
boot. If this happens without crashing, no rollback mechanisms will be
triggered because there's no crash. With this change, if the system
server deadlocks early during boot, the Watchdog will crash the
system server, frequent enough crashes (4 in 4 mins) will trigger
the native watchdog and cause apexd to rollback any staged mainline updates.
Bug: 129597207
Test: Boots fine and logs indicate threads and monitors are registered
properly. Also adding an artificial sleep to the PackageManagerService
during boot crashes the system_server. At the moment, this is not
detected by the native watchdog because the default_timeout of 60
seconds before crashing the system_server never triggers the native
watchdog crash frequency threshold. Will fix in later cl.
Change-Id: I956a263e96d17d55bc512a5eab905cd2a14a7abb
GPU Service is used to monitor all GPU and graphics driver related features.
This patch implements GPU service into System Server, and implements
functionality to extract the whitelist out of game driver package when the
package is upgraded or removed. This will move the whitelist processing off
critical path when app launches.
BUG: 123290424
Test: Build, flash and boot. Verify by upgrading game driver apk.
Change-Id: I563a138bfe0c4c1bb17ed28dab5d6a8df244021d
Merged-In: I563a138bfe0c4c1bb17ed28dab5d6a8df244021d
This change adds a mechanism for restricting permissions (only runtime
for now), so that an app cannot hold the permission if it is not white
listed. The whitelisting can happen at install or at any later point.
There are three whitelists: system: OS managed with default grants
and role holders being on it; upgrade: only OS puts on this list
apps when upgrading from a pre to post restriction permission database
version and OS and installer on record can remove; installer: only
the installer on record can add and remove (and the system of course).
Added a permission policy service that sits on top of permissions
and app ops and is responsible to sync between permissions and app
ops when there is an interdependecy in any direction.
Added versioning to the runtime permissions database to allow operations
that need to be done once on upgrade such as adding all permissions held
by apps pre upgrade to the upgrade whitelist if the new permisison version
inctroduces a new restricted permission. The upgrade logic is in the
permission controller and we will eventually put the default grants there.
NOTE: This change is reacting to a VP feedback for how we would handle
SMS/CallLog restriction as we pivoted from role based approach to roles
for things the user would understand plus whitelist for everything else.
This would also help us roll out softly the storage permisison as there
is too much churm coming from developer feedback.
Exempt-From-Owner-Approval: trivial change due to APi adjustment
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
Test: atest CtsPermissionTestCases
Test: atest CtsPermission2TestCases
Test: atest RoleManagerTestCases
bug:124769181
Change-Id: Ic48e3c728387ecf02f89d517ba1fe785ab9c75fd
This service connects to a remote system captions manager service. This
service is responsible for enabling system captions when the user
requests them. As the system binds to it, this service will be
persistent.
Cherry pick from ag/6761232
Bug: 128925852
Test: Manual. I created an implementation of the service.
Merged-In: Iafde1bb68f4754d8167624f47c6833d43c0ec336
Change-Id: Iafde1bb68f4754d8167624f47c6833d43c0ec336
The system server (in SystemServer.java) defines the boot
sequence, during which an event called SystemReady happens.
This corresponds to a time when critical system services
that are depended upon by other components in the system
server are ready to handle requests from their dependencies.
Some system services are listening to this event to defer
initializations that depend on the critical services.
Because the network stack is only started after SystemReady,
there is no way any NetworkMonitor may be started before
SystemReady. Remove the associated mechanism.
Fix: 129376083
Test: FrameworksNetTests
Change-Id: I071eeb10d0b7c4f71af6653d322c7b442b2cc7ee
Some API changes per API reivew:
- Move DynamicAndroidClient and ~Manager to android.os.image.
- Rename them to DynamicSystemClient and ~Manager.
- Rename permission MANAGE_DYNAMIC_ANDROID to MANAGE_DYNAMIC_SYSTEM
- Corresponding changes in the installation service.
- Corresponding changes in privapp-permissions-platform.xml.
- Add missing annotations.
- Change setOnStatusChangedListener's parameters order.
- Improve documentations.
- Re-generate api/system-current.txt.
Bug: 126613281
Test: adb shell am
Change-Id: Ia920e9ccf6de1dbbd38c52910cb72cb81b9b5b32
The NetworkStack needs to be marked as start requested before any client
can use it from the system server, so it knows to queue requests until
it actually comes up.
This fixes a bug introduced in commit:
I93315ad31925bd436e21d1eabb21d5967e6aae60
where a client trying to use the network stack in the system server
before ActivityManager.systemReady() could block and eventually timeout,
resulting in a null INetworkStackConnector.
Test: booted, WiFi working
Bug: 128620654
Change-Id: Ieca2657373eba78195b387fb266fa0424fce8ada
In practice the NetworkStack was not started after
ActivityManager#systemReady, since ActivityManager was only scheduling
the start (mPendingStarts).
Requesting the start too early causes issues for the PackageManager to
install updates/rollbacks.
Test: flashed AOSP and internal builds, WiFi working
Bug: 128331883
Change-Id: I93315ad31925bd436e21d1eabb21d5967e6aae60
