|
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
|
