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.
Change-Id: Ie1130a3f0bdd1769fe0755db0089702ea64d9db6
This reverts commit b897b173c1.
Reason for revert: real fix on Iea89b3d379792327657e01869c9494975e7b0306
Bug: 139416391
Bug: 135218095
Change-Id: Ib8f97ca460ccea90d2b674e83cbda2a62be2538e
Test: none
This reverts commit c6fff2524b.
Reason for revert: causing WM pre-submit tests to fail on go/wm-tests
Change-Id: I7a6db671f17fb056f29d5e02f58a7da88afda7ed
a) Moved wifi service to a separate APK
b) Use the IWifiStackConnector to load the wifi stack from
SystemServer (similar to network stack).
c) Create a new WifiStackClient interface for system server to interact
with the wifi stack (under new services/wifi folder). Note: This not planned
to be updated via wifi-sdk Apex.
d) Add priv-app permissions for the new wifi stack APK.
Bug: 113174748
Test: Device boots up & connects to wifi networks, hotspot toggle, etc.
Test: Will send for regression tests
Change-Id: I54b3a11ed30668bad5a387370484b2bb0eabca5f
Merged-In: I54b3a11ed30668bad5a387370484b2bb0eabca5f
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.
Change-Id: I673581b0067b9a3f72dd68a3ab622c18183ebd2e
Merged-In: I673581b0067b9a3f72dd68a3ab622c18183ebd2e
As the main javadoc states:
"An app can check whether wallpapers are supported for the current user,
by calling {@link #isWallpaperSupported()}, and whether setting of
wallpapers is allowed, by calling {@link #isSetWallpaperAllowed()}."
Test: manual verification on automotive
Test: atest CtsAppTestCases:android.app.cts.WallpaperManagerTest # on automotive
Bug: 138939803
Change-Id: I88946f92ff54e556d289c41c28e22da3a4b8c8b8
- Also remove the dependency from SystemServiceRegistry to JobScheduler
See apex/jobscheduler/README_js-mainline.md for the details.
Bug: 137763703
Test: build and boot
Test: atest CtsJobSchedulerTestCases
Change-Id: I2386c78b7a6085d6e543a63f22cb620c4cabd06a
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 0b41c8940a)
- Also remove the dependency from SystemServiceRegistry to JobScheduler
See apex/jobscheduler/README_js-mainline.md for the details.
Bug: 137763703
Test: build and boot
Test: atest CtsJobSchedulerTestCases
Change-Id: Ic8ae8e99e6600b261618b5cfb6590d3f3664ae9f
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
Moving InputMethodSystemProperty from android.view.inputmethod to
com.android.server.inputmethod so that it can be accessed only from
the system_server.
Change-Id: I41707a4e5dfe824cbe9e873ec598762d36c64c09
Fix: 137203823
Test: Build and flash
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
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 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
Also refactored SystemServer.BOOT_TIMINGS_TRACE_LOG into a helper class, so it's not permanently
allocated.
Bug: 133242016
Test: manual verification
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.DeviceOwnerTest#testCreateAndManageUser_StartInBackground
Change-Id: Id059d4d777bfc705e510d157930aefc7757d8cf8
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 87ac4ea4a5)
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
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
