User:Clouserw/APKFactory

C&C APK Factory

We're building an APK Factory! In short, this is a black box which will accept a manifest URL as input and return a .apk file. This project includes some UI changes on the Marketplace but the vast majority of the project is backend and APIs.

The primary use case is:

• An end user, using Fennec, clicks an Install button on any web page
• Fennec retrieves the manifest linked to from the Install button and sends it to the APK Factory
• The APK Factory processes it and turns it into an APK (~seconds)
• The APK Factory returns an APK in response to the manifest
• Fennec installs the APK as a normal android app

User Stories

Use case: install

As a user, I can tap Install on a web page and an APK is downloaded to my device so that my phone's native package installer can install the app.

Use case: manual update

As a user, I can have my phone check for updates and have my phone download them so that I may keep my webapps safely up-to-date.

Implementation Note: Fennec will poll the APK factory (or, perhaps a different domain?) with a JSON blob to see if there are updates. Push notifications are not available across all our platforms so we're back to polling here.

Use case: update

As a user, I can trust that my phone will automatically keep my webapps up to date.

Use case: developer's own keys

As a developer, I can use my own key to sign my Android APK, so I can use the key elsewhere.

Implementation Notes:

• Changing keys for an already published APK is impossible
• For a large proportion of developers, a randomly generated APK signing key will be sufficient.
• We'll need this early enough in the submission process that the first copy of their app will have the right key
• [uiwanted]: We need to make sure developers with keys actually see this as otherwise their userbase is forked.

Use case: developer opt-out

As a Developer, I can chose not to have my app auto-generated as an Android APK

dvd: Issue: what if the developer doesn't know that his app is going to be auto-generated and installed as an APK on Android. If the OWA has not been submitted through the marketplace, the developer is not aware of this. The developer may already have the same app developed as an Android native app or an Android Webapp. If Fennec displays any webapp with an install button as the webapp thinks it will be deployed within the browser, there is no way for the developer to opt out. I am not arguing against the openness as an argument but rather for the developer to be in control.

Use case: pre-submission development

As a developer I would like to be able to test my APK without submitting it to the marketplace.

TODO: Is this use case out of date? If you want to test your APK without submitting to the marketplace, just do it. That's what the install button will do, right? It is assumed that the Android toolchain is rather cumbersome and not interesting enough for the webapp developer to actually set it up successfully.

dvd: I guess i meant that the developer may want to see/test how the app performs before submitting it for review in the marketplace. I.e. you have submitted a webapp and didn't opt from not having an APK developed. So before the app goes into review mode, you can chose to test the APK and then submit it. However, this is not so practical as submitting a webapp would get it into review process; rather have the developer to opt-out later by not approving the de-bug version if he doesn't like the apk

The APK should not be publishable on an APK app-store, e.g. signed with a debug key, icon marked with "IN TEST".

This use of the apk-factory should be invoked by the developer from the command line or App Manager.

In coming releases, we would like the developer to be able to construct an APK without calling out to a server, either from the command line or App Manager.

Use case: post-submission review

• As a reviewer, I would like to follow the same review process as I do for the normal app.
• As a reviewer I can run the APK on my Android phone.
• As a developer I can run the same APK as the reviewer.

TODO: the third story here says "same APK" - does that mean an APK with a debug cert, or the actual same one. I prefer the former.

dvd: yes, the former

Implementation Notes: The APK should not be publishable on an APK app-store, e.g. signed with a debug key, icon marked with "IN REVIEW".

Use case: post-review acceptance

As a developer, I can download the APK that will be installed on user's devices, so I can distribute it myself.

Once the webapp is ready for publishing, the developer should receive (as part of an existing email?), a link to the APK. TODO: Why wouldn't we just put a download link in the developer control panel in the Marketplace? Or is this for 3rd party install buttons too (in which case, how do we get their email address?)

dvd: this use case can only apply to marketplace - as well as e.g. upload and download keys. Unless we enhance APK Factory with developer sign-in but that really sounds like duplication as the openness of allowing our marketplaces and direct installs can be achieved and still making APK Factory closed. Or?

Implementation

  +------------+    +-------------+    +------------+
  | User Agent +--->| APK Factory +--->| APK Signer |
  |  (Fennec)  |<---+             |<---+            |
  |            |    |             |    |            |
  +------------+    +-------+-----+    +------------+
                          ^ |
                          | |
  +-------------+         | |
  | Marketplace +---------+ |
  |             |<----------+
  |             |
  +-------------+

User Agent / Fennec Modifications

• mozApps.install() and mozApps.installPackage() to send the manifest to the APK Factory
• Manual updating UI and JSON request (TODO: needs detail / spec)
• Periodic updating check

Marketplace Modifications

• [uiwanted] Adjust developer flow to opt-out of automatic APK generation
• Adjust developer tools to add APK download link to versions page of the app page
• [uiwanted] Adjust developer tools to accept a user specified signing key (associated with app)
• Adjust reviewer tools to ask for Reviewer APKs (TODO: How do we specify the reviewer debug key?)

APK Factory Modifications (this is a new service)

• Requires Java Development Kit (JDK) not just an environment (JRE). Requires new hardware?
• API to accept manifest as input
  • Differentiate between hosted & packaged apps
  • Do the actual packaging
    • duplicate/enhance the prototype
    • APK Factory builds the android project from a template and data in the manifest including icons, L10n, permissions, and web activities
    • For packaged webapps, the package.zip and mini-manifest files will be included in the .apk
• API to accept signing key from the Marketplace if specified
• Ability to sign using an android debug key
• Ability to sign using production app keys if signing for final packages
• API to send and receive keys from the APK Signer
• GC to clean up old packages on disk
• API to accept a JSON list of manifests and return which have updates (TODO: needs spec)
  • App freshness is a function of:
    • the manifest
    • changes to the android library code
    • If it's a packaged app, the package.zip (we can hash this)
  • Android Apps have a hard requirement that the versionCode, a non user facing integer representation of the version string, be positively increasing.
• Have the ability to regenerate all apps (including bumping versionCode) (useful for fixing a security hole in apk-factory-library)

TODO: An assumption is that developers will only specify their own key if they are uploading via the Marketplace. Perhaps that isn't true? ozten brings up a good point that we'd need auth for this somewhere, marketplace makes sense...

dvd: wouldn't the APK Factory need to store manifest URL, version code, keys (or link to key). Would also need to check if the manifest fits the app, no? Like what we do in the marketplace if the app has significantly changed from the manifest, then it will not run.

APK Signer Modifications (this is a new service)

• Requires new hardware
• Based heavily on solitude
• A secure storage area for production signing keys
• No outside network traffic (see above diagram)