* changes:
[Tether10]Remove UserManagerInternal usage in Tethering
[Tether07] Migrate Tethering into module
[Tether07] Clean up build rule for libtetheroffloadjni
Now tethering would be run in dedicated service.
TetheringManager is the interface used to communicate with
TetheringService. The new call flow would be: ConnectivityManager
-> ConnectivityService -> TetheringManager -> TetheringService.
Note: the return value of #tether(), #untether() and #setUsbTethering()
APIs would always be no error. Client can use #getLastTetherError()
or #getTetheredIfaces or listen tether state change to check
status of corresponding interface.
Bug: 136040414
Bug: 144742179
Test: -build, flash, boot
-atest TetheringTests
-atest FrameworksNetTests
Change-Id: I7e78c0e0a3e70f940a749ba2a39ece7c7ec5b9b3
Merged-In: I7e78c0e0a3e70f940a749ba2a39ece7c7ec5b9b3
Add a new time zone detection service. Much of the code is from
frameworks/opt/telephony with some changes for naming, threading and
to modify the interaction with the "Callback" class.
Overall goal:
Implementing the service in the system server means it will be easier to
add new time zone detection logic unrelated to telephony in future.
Bug: 140712361
Test: atest com.android.server.timezonedetector
Test: atest android.app.timezonedetector
Change-Id: I89505fc4fecbd3667b60f8e1479b8f177eaa60ae
Merged-In: I89505fc4fecbd3667b60f8e1479b8f177eaa60ae
(cherry picked from commit 3e3b5405b6)
This allows the RecoverySystemService to be instantiated outside of its
lifecycle events and mocked connections to be injected during the tests.
Test: atest FrameworksServicesTests:RecoverySystemServiceTest
Merged-In: If75632b8dc16c916f3fa90853d6c1863b75d2c64
Change-Id: If75632b8dc16c916f3fa90853d6c1863b75d2c64
Remove dead code from SystemServer that obstensively protects devices
from negative (< 1970) system clock times, but does not.
In reality, SystemServer calls SystemClock.setCurrentTimeMillis(), which
calls through to the AlarmManager.setTime() binder call. When the code
runs the system server hasn't started any services yet, so this would
always fail.
AlarmManager has similar protections in place that do work: if the
device is earlier than a "build time", then the device's clock is forced
forward. That provides the protection that the code being removed from
SystemServer was trying to achieve.
Test: Added logging to SystemClock to prove AlarmManager is null /
manual debugging
Change-Id: I87dca1062829bc1a10202804fa7ee31e0a6f03a3
This helps reviewing the refactor of the RecoverySystemService in which it
is made a bit more testable.
Test: make && emulator
Change-Id: Ifc5a658fe68ed10ab400f43d1d3967c0acccbd11
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
Bug: 132111956
Change-Id: I88946f92ff54e556d289c41c28e22da3a4b8c8b8
Merged-In: I88946f92ff54e556d289c41c28e22da3a4b8c8b8
(cherry picked from commit 34a861add1)
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 7e6f5f5e08 & 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.
Change-Id: I673581b0067b9a3f72dd68a3ab622c18183ebd2e
Merged-In: I673581b0067b9a3f72dd68a3ab622c18183ebd2e
(cherry picked from commit 7e6f5f5e08)
(cherry picked from commit b51c428f41)
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 7e6f5f5e08 & 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 0b41c8940a)
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
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 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
