1291372 - [geckoview] Produce and upload GeckoView AAR file when building with Gradle

Status: RESOLVED FIXED

(GeckoView :: General, defect)

Description

[Nick Alexander :nalexander [he/him]]

This ticket tracks making the "geckoview" library project added by Bug 1291363 produce an AAR file suitable for consumption, and getting the TC
job added by Bug 1291370 to at it as a build artifact.  This should let
potential consumers download and test against the GV builds.

I'm not going to file individual tickets for these just yet, but I can
think of the following bits we'll want to stuff into the AAR (eventually):

* proguard.txt.  This is crucial -- without it, our JNI entry points may get optimized away, leading to immediate crashes.  On day one, we might just protect org.mozilla.gecko*.

* Minimal permission requests.  On day one, we can ship with the set of permissions Fennec asks for.  Over time, however, we should remove (or make optional) as much of the permission space as Gecko can function without.

* Transitive dependencies.  I think Gradle will produce an AAR with the correct dependencies; but my old code (removed by Bug 1268944) did not do this correctly.  Consumers should observe failures from missing support libraries immediately.

* Better versioning.  For historical reasons (see extensive discussion in Bug 1182579 and friends), Fennec has a complicated numerical version code.  We can and should simplify the version tags for the GeckoView library to simply match Gecko's underlying version number, if at all possible.

* A source JAR.  I'm not sure this is possible with an AAR, but if it is, it will make consumers lives much easier.

* JavaDoc outputs.  Again, I'm not sure it's possible to include this in an AAR, but we'll want to produce JavaDoc for our eventual API.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

(In reply to Nick Alexander :nalexander (Away Aug 9 - Aug 27) from comment #0)
> * proguard.txt.  This is crucial -- without it, our JNI entry points may get
> optimized away, leading to immediate crashes.  On day one, we might just
> protect org.mozilla.gecko*.

If crucial, then does it need doing as part of this bug; or is it crucial for a stable release, but can be done separately?


> * Minimal permission requests.  On day one, we can ship with the set of
> permissions Fennec asks for.  Over time, however, we should remove (or make
> optional) as much of the permission space as Gecko can function without.

Filed as bug 1298529.  I think that can be done independently of this bug (although it depends on bug 1098129 - Split GeckoView and Browser packages).


> * Better versioning.  For historical reasons (see extensive discussion in
> Bug 1182579 and friends), Fennec has a complicated numerical version code. 
> We can and should simplify the version tags for the GeckoView library to
> simply match Gecko's underlying version number, if at all possible.

It'd be useful to expose both the (monotonically increasing) Gecko version number and a separate version string that reflects the compatibility of changes to the public API, f.e. using semantic versioning <http://semver.org/> to distinguish between major (breaking) and minor (enhancement) changes.  I'm not familiar enough with the options for expressing versions in Android libraries to know how best to do this, however.

Cordova (which has a bit of a different problem, admittedly) appears to use SemVer for its various components, per this description (although I haven't found an explicit statement to that effect):

https://taco.visualstudio.com/en-us/docs/tutorial-cordova-5-readme/

Crosswalk, on the other hand, uses a four-part format in which the first part gets incremented with train-like releases every six weeks, while the second part represents the Chrome version number:

https://github.com/crosswalk-project/crosswalk-website/wiki/release-methodology#version-numbers

Electron has the similar problem of needing to differentiate between its API and the versions of Chromium (and Node) it ships.  See this issue for a description of (and debate about) their use of a modified form of SemVer (which accounts for but doesn't actually express the versions of Chromium and Node they ship):

https://github.com/electron/electron/issues/5561


> * A source JAR.  I'm not sure this is possible with an AAR, but if it is, it
> will make consumers lives much easier.

http://stackoverflow.com/questions/36181814/how-to-export-aar-library-with-its-documentation suggests that this is doable, although it doesn't confirm it.


> * JavaDoc outputs.  Again, I'm not sure it's possible to include this in an
> AAR, but we'll want to produce JavaDoc for our eventual API.

Indeed, and publish it online in addition to including it in the AAR.  I filed this as bug 1298542.

Comment 2

[Nick Alexander :nalexander [he/him]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #1)
> (In reply to Nick Alexander :nalexander (Away Aug 9 - Aug 27) from comment
> #0)
> > * proguard.txt.  This is crucial -- without it, our JNI entry points may get
> > optimized away, leading to immediate crashes.  On day one, we might just
> > protect org.mozilla.gecko*.
> 
> If crucial, then does it need doing as part of this bug; or is it crucial
> for a stable release, but can be done separately?

Crucial for any release, and probably for some development -- without it, bits of the Gecko JNI code may be optimized away entirely.  It's easy, though -- just need to put a proguard.txt into the correct directory and it should all work out.

Comment 3

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1291372 - Produce Maven repository with GeckoView Javadoc and Sources JARs.

We use a Maven repository and the (misleadingly named!) uploadArchives
task because this is the best way to make Android Studio download and
recognize the Javadoc and sources.  With this, it's automatic; with a
single AAR file, it's a nightmare of point-and-click configuration.

This patch does a bunch of Gradle hacking to make -javadoc and
-sources JARs; there's nothing special or particularly likely to break
here.

This patch also adds Proguard declarations to the :geckoview library
project.  That involves moving a good part of the Proguard
configuration into mobile/android/geckoview.  (I also expand upon the
existing configuration.)  This should be only a re-arrangement, and
the resulting file is included in the original, so nothing should be
changed.

Review commit: https://reviewboard.mozilla.org/r/91576/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/91576/

Comment 4

[Nick Alexander :nalexander [he/him]]

This try build is looking good: https://treeherder.mozilla.org/#/jobs?repo=try&revision=29bad843a029de68d27a0775529d49f5e3a2bae7&selectedJob=30701871.

A `build.gradle` file starting
```
apply plugin: 'com.android.model.application'

repositories {
    maven {
        url "https://queue.taskcluster.net/v1/task/cPpyah5QSVaCpRpUcB83lg/runs/0/artifacts/public/android/maven"
    }
}
...
```
works as expected!

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8808843 [details]
Bug 1291372 - Produce Maven repository with GeckoView Javadoc and Sources JARs.

https://reviewboard.mozilla.org/r/91576/#review91718

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/eb3dd588e1af
Produce Maven repository with GeckoView Javadoc and Sources JARs. r=snorp

Comment 7

[Sebastian Kaspari (:sebastian; :pocmo)]

This changed our APK size by 1.62%:
https://treeherder.mozilla.org/perf.html#/alerts?id=4101

Is this expected?

Comment 8

[Nick Alexander :nalexander [he/him]]

(In reply to Sebastian Kaspari (:sebastian) from comment #7)
> This changed our APK size by 1.62%:
> https://treeherder.mozilla.org/perf.html#/alerts?id=4101
> 
> Is this expected?

No.  I added some small pieces to the new Proguard file, and I think they were incorrect.  I'm investigating  Proguard with Gradle as part of Bug 1255914 and will follow up with this regression either here or there.

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/eb3dd588e1af