- Move VibratorManagerService to com.android.server.vibrator and make
all other classes there package-private;
- Add some missing haptics-related files to OWNERS files;
- Remove some unused methods;
- Delegate CombinedVibrationEffect to input devices, instead of only
delegating VibrationEffect effects;
- Move vibratorservice.proto to vibrator folder and add missing fields;
- Mark large VibrationThread tests with @LargeTest;
Fix: 131311651
Fix: 177805090
Test: VibratorManagerServiceTest
Change-Id: Ic747190b70b2f45ac7671eb01f8f05cf66d3a96c
This adds a lot of unused code but this should make it easier to
review subsequent CLs.
Bug: 173331190
Test: builds, boots, "dumpsys vpnmanager" succeeds
Change-Id: Ied379654a0c3ab6242d3125661fe30f322395059
Add default system implementation of vibrator manager service that uses
IVibratorManagerService to access the device vibrators.
Change implementation of SystemVibrator to use VibratorManagerService
and delete local service VibratorService.
Introduce missing public APIs for VibratorManager and Vibrator.getId.
Bug: 167946816
Test: VibratorManagerServiceTest, VibratorTest, VibrationEffectTest
Change-Id: I55cdeb72c7ca39ccf0c7b2fda60b16de1031801e
It's somewhat hard to debug with just allocation backtraces when the
cause of the leak is a Java object leak. Generate an hprof dump when
this happens.
For privacy reasons, we don't include this in bugreports, since the
contents of system_server's memory is highly sensitive: they must be
manually requested from dogfooders.
Bug: http://b/176389805
Test: manual
Change-Id: Ib7755433395f341d90b732f285f00c8675291139
Unfortunately it's possible to call this during PackageManagerService
initialization, so this needs to be attached before PMS gets created.
Rather than using a deferred injection, this makes PMS call
setConnection to directly set the callback. A better isolated might be
worth exploring in the future, but overall it shouldn't really matter.
Exempt-From-Owner-Approval: Already approved by owners on main branch
Bug: 163565712
Test: com.android.server.pm.test.domain.verify
Change-Id: Ib60f5560ecaa510474228aa1c38eff5d6041ab58
Handles adding a new package (either from a brand new install or a boot
scan) and migrating between packages when installing an update.
Will merge the package states in the update case to preserve successful
verifications while removing failed domains so that they can be
re-requested by the verification agent.
Exempt-From-Owner-Approval: Already approved by owners on main branch
Bug: 163565712
Test: manual, device boots, will be tested as part of later changes
Change-Id: I54dc8415e10544e618905e269ab95ec0a2af0fb0
Sets up the callback and the actual service initialization so that
future domain verification changes can access PackageManager APIs.
Exempt-From-Owner-Approval: Already approved by owners on main branch
Bug: 163565712
Test: none, device boots, tested implicitly as part of other changes
Change-Id: Ie75ad0ee002ae92c21387777ff41c2504c69b836
Just the basic SystemService so that future CLs can add methods. Starts
the service in SystemServer, but effectively does nothing.
Exempt-From-Owner-Approval: Already approved by owners on main branch
Bug: 163565712
Test: none, just a skeleton
Change-Id: I1388423894e1e96511ab0f7de8ac5a7c2eea6de0
In preparation for making tombstones available to apps, extract the
tombstone tracking code from BootReceiver to its own service.
Bug: http://b/159164105
Test: manual
Change-Id: I789f41f12a8be312b6e966226646c4ec4becc1aa
Role service is modularized in this release and allows lower level
roles to be introduced after role logic is moved from
PermissionController APK into the system server JAR. So move starting
role service earlier as well to allow lower level roles.
This has no immediate effect because currently initialization for all
roles happens upon user start, but once role logic is inside system
server, we can allows initializing certain roles earlier in the boot
process, e.g. via SystemService.onBootPhase().
Fixes: 178565325
Test: presubmit
Change-Id: I8d183553f08aa6200aa3566afaabd40a7ce9489c
(cherry picked from commit d93060190f)
GameManager service is a service to manage game related features. This
patch creates the initial service to manage the game mode and persist
the data across reboot.
Bug: b/174956354
Test: atest GameManagerTests
Test: atest GameManagerServiceTests
Test: atest GameManagerServiceSettingsTests
Change-Id: Iee2ab47c79d29f48847bc6d4b3eb781a5af18ff4
This change alters the start-up order of the VCN and Connectivity
services.
Bug: 174636568
Test: atest FrameworksVcnTests
Test: atest FrameworksNetTests
Change-Id: I1af29d52b94e77781eb2bf2082fcbe43648ee800
This change alters the start-up order of the VCN and Connectivity
services.
Bug: 174636568
Test: atest FrameworksVcnTests
Test: atest FrameworksNetTests
Change-Id: I1af29d52b94e77781eb2bf2082fcbe43648ee800
Merged-In: I1af29d52b94e77781eb2bf2082fcbe43648ee800
Move some animation functions in AppTransition to new
TransitionAnimation class for wm-shell using.
Bug: 175053726
Test: build
Change-Id: I7eef67359fd4532f7e4d97c787d5288362a32f13
Introduces a new SystemService to act as intermediary between the
Perfetto trace daemon and Traceur.
Bug: 175591887
Test: adb shell service call 1 i32 0/1
Change-Id: Idea7761a8479827f0cfa561e56ba2beac3072939
Move code from com.android.server.location.timezone to
com.android.server.timezonedetector.location.
It has more in common with time zone detection than location code.
Bug: 175119330
Test: Treehugger
Change-Id: I80e8c88ba1e3903f3b662cb195c5b2877ba661b0
Rotation Resolver Service provides the suggested screen rotation
to the system server.
Bug: 162359770
Bug: 172370409
Test: atest RotationResolverManagerPerUserServiceTest
Change-Id: Ia43dfdba8502e04768933ef46a4ac8a687d4936c
These changes have to be in this CL together because:
- Code in service-permission depends on IRoleManager in
framework-permission, so the APIs in framework-permission and the code
in service-permission need to be moved together.
- The changes to service-permission build rules doesn't make sense
without the code moved in, so they have to be together as well.
Other details:
- framework-annotations: Several annotations are added into
framework-annoatations. Since the discussion with API council seems to
allow user IDs in system server in-process APIs, @UserIdInt and
@AppIdInt is added. @MainThread and @AnyThread is added since
@WorkerThread is already added. @CallSuper is added since @CheckResult
is also already added and they are similar in terms of category of
functionality.
- framework-permission-s-shared-srcs: 3 classes (and 2 AIDL files)
from framework is copied as shared source files and jarjared for
framework-permission, and an additional 3 is added for
service-permission as service-permission-shared-srcs. Similar to
framework-wifi and service-wifi, the 3 classes in framework-permission
is also available to service-permission by the stub library
framework-permission-pre-jarjar, and the other 3 classes used only for
service-permission is included separately to minimize our impact on
classes loaded into boot classpath. framework-permission and
service-permission shares the same jarjar rules to make sure the
classes remain available, and for the same reason framework-permission
cannot be shrank during any optimization.
- framework-permission-s-shared: A java_library target for
framework-permission-shared-srcs is created to make sure that the
public classes won't be counted as APIs, as it would be if directly
included as srcs for framework-permission
java_sdk_library. service-permission-shared is the same thing for
service-permission.
- framework-permission-s: A new java_sdk_library target created to be
loaded into bootclasspath by Android S+.
- Dumpsys Protobuf: The dumpsys protobuf
file (rolemanagerservice.proto) is moved into the module, and both the
platform (incident.proto) and the module uses protoc-gen-javastream to
generate the Java classes from it. This should be fine since it's a
"source level inclusion", and we jarjar the generated classes in our
module to avoid conflict with platform copies.
Bug: 158736025
Test: manual
Test: device boots, default apps can be changed successfully.
Change-Id: I1914774f631e51d0c587a7e527a1c9bc05ee1595
- PooledLambda: PoolLambda is replaced with plain lambdas, to avoid
adding ~20 classes to boot classpath (for each module that uses
lambda).
- SystemServiceRegistry: RoleFrameworkInitializer is added to add
ROLE_SERVICE, similar to other modules.
- RoleService: RoleManagerService is renamed to RoleService to better
reflect the manager/service relationship.
- @MainThread: import for Looper is removed because it's only used in
javadoc and triggers package not exist error during build. @linkplain
in the javadoc is also removed because it triggers an error in
Metalava parsing and isn't critical.
- Added small utilities: These utilities has their full version in
platform, but is too large and contains too many internal references
in methods unreferenced by role, whereas actually role only needs 1 or
2 methods from them. So just create a small copy of the used methods
for role modularization, and they will be moved into APEX with role.
Bug: 158736025
Test: manual
Change-Id: I74f20b37d23370e258e7fc7130e28c5312abf46c
The computePackageStateHash() implementation needs
PackageManagerInternal.forEachInstalledPackage(),
getApplicationEnabledState(), getEnabledComponents() and
getDisabledComponents() to work, for which we don't have good
alternatives in API. Even if we added those APIs, generating and
iterating over PackageInfo for all packages in the system would surely
drive up CPU and memory usage and regress our performance, and the new
AndroidPackage system APIs isn't ready in S yet. So we can move
computePackageStateHash() implementation into platform. Once we move
role logic into system server, granting default roles may be fast
enough and we may consider the deprecation/removal of this.
This way we can also remove the final dependency we have on
PackageManagerInternal and be ready for modularization.
Bug: 158736025
Test: presubmit
Change-Id: I14119f2e95c861ee3539108748a4912b051b4462
GnssTimeUpdateService listens for location updates. Once an update is
received, it reads the time provided by GPS and suggests it to
TimeDetectorService. TimeDetectorService can then use it to set the
SystemClock based on included time sources and priority.
Bug: 157265008
Test: Presubmits + atest + Manual
- atest frameworks/base/services/tests/servicestests/src/com/android/server/timedetector/GnssTimeUpdateServiceTest.java
- For manual testing, the Location Shell Commands can be used to add /
enable a gps test provider to set gps locations with a specified time.
The time detector dumpsys can then be used to verify that a GNSS
suggestion has been made.
Change-Id: Ife27ecd6d122f33b7cc93d7832e3085acc33c160
The logic to read the platform XML is moved from RoleUserState. The
logic to read legacy settings is left untouched except refactored to
return the mapping at once.
Bug: 158736025
Test: presubmit
Change-Id: Ifd1770bf869ea77b2f8a4ff8b3eae46a46cc90cf
