Add OWNERS to apex/jobscheduler, and update README

yamasani@google.com

omakoto@google.com

ctate@android.com

ctate@google.com

kwekua@google.com

suprabh@google.com

 No newline at end of file

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

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

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

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

  (Note `jobscheduler-service.jar` will be put at the end in http://ag/9128109)

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