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