Add OWNERS to apex/jobscheduler, and update README

Bug: 137763703
Test: presubmit
Change-Id: I0a6e0089f392ef413c9201f3596a4d2e2703857a

apex/jobscheduler/OWNERS

@@ -0,0 +1,6 @@
+yamasani@google.com
+omakoto@google.com
+ctate@android.com
+ctate@google.com
+kwekua@google.com
+suprabh@google.com

apex/jobscheduler/README_js-mainline.md

@@ -6,46 +6,33 @@ See also:
 - http://go/moving-js-code-for-mainline
 - http://go/jobscheduler-code-dependencies-2019-07
 
-- [ ] Move client code
-  - [ ] Move code
-  - [ ] Make build file
-  - [ ] "m jobscheduler-framework" pass
-  - [ ] "m framework" pass
-  - [ ] "m service" pass
-- [ ] Move proto
-  - No, couldn't do it, because it's referred to by incidentd_proto
-- [ ] Move service
-  - [X] Move code (done, but it won't compile yet)
-  - [X] Make build file
-  - [X] "m service" pass
-  - [X] "m jobscheduler-service" pass
-    - To make it pass, jobscheduler-service has to link services.jar too. Many dependencies.
 - [ ] Move this into `frameworks/apex/jobscheduler/...`. Currently it's in `frameworks/base/apex/...`
 because `frameworks/apex/` is not a part of any git projects. (and also working on multiple
 projects is a pain.)
 
+## Current structure
 
-## Problems
-- Couldn't move dumpsys proto files. They are used by incidentd_proto, which is in the platform
-  (not updatable).
-  - One idea is *not* to move the proto files into apex but keep them in the platform.
-    Then we make sure to extend the proto files in a backward-compat way (which we do anyway)
-    and always use the latest file from the JS apex.
+- JS service side classes are put in `jobscheduler-service.jar`.
+It's *not* included in services.jar, and instead it's put in the system server classpath,
+which currently looks like the following:
+`SYSTEMSERVERCLASSPATH=/system/framework/services.jar:/system/framework/jobscheduler-service.jar:/system/framework/ethernet-service.jar:/system/framework/wifi-service.jar:/system/framework/com.android.location.provider.jar`
 
-- There are a lot of build tasks that use "framework.jar". (Examples: hiddenapi-greylist.txt check,
-  update-api / public API check and SDK stub (android.jar) creation)
-  To make the downstream build modules buildable, we need to include js-framework.jar in
-  framework.jar. However it turned out to be tricky because soong has special logic for "framework"
-  and "framework.jar".
-  i.e. Conceptually, we can do it by renaming `framework` to `framework-minus-jobscheduler`, build
-  `jobscheduler-framework` with `framework-minus-jobscheduler`, and create `framework` by merging
-  `framework-minus-jobscheduler` and `jobscheduler-framework`.
-  However it didn't quite work because of the special casing.
+  (Note `jobscheduler-service.jar` will be put at the end in http://ag/9128109)
 
-- JS-service uses a lot of other code in `services`, so it needs to link services.core.jar e.g.
- - Common system service code, e.g. `com.android.server.SystemService`
- - Common utility code, e.g. `FgThread` and `IoThread`
- - Other system services such as `DeviceIdleController` and `ActivityManagerService`
- - Server side singleton. `AppStateTracker`
- - `DeviceIdleController.LocalService`, which is a local service but there's no interface class.
- - `XxxInternal` interfaces that are not in the framework side. -> We should be able to move them.
+  `SYSTEMSERVERCLASSPATH` is generated from `PRODUCT_SYSTEM_SERVER_JARS`.
+
+- JS framework side classes are put in `jobscheduler-framework.jar`,
+and the rest of the framework code is put in `framework-minus-apex.jar`,
+as of http://ag/9145619.
+
+  However these jar files are *not* put on the device. We still generate
+  `framework.jar` merging the two jar files, and this jar file is what's
+  put on the device and loaded by Zygote.
+
+
+This is *not* the final design. From a gerrit comment on http://ag/9145619:
+
+> This CL is just the first step, and the current state isn't not really the final form. For now we just want to have two separate jars, which makes it easier for us to analyze dependencies between them, and I wanted to minimize the change to the rest of the system. So, for example, zygote will still only have "framework.jar" in its classpath, instead of the two jars for now.
+> But yes, eventually, we won't even be able to have the monolithic "framework.jar" file because of mainline, so we need to figure out how to build the system without creating it. At that point zygote will have the two separate jar files in its classpath.
+> When we reach that point, we should revisit the naming of it, and yes, maybe the simple "framework.jar" is a good option.
+> But again, for now, I want to make this change as transparent as possible to the rest of the world.