Closed Bug 1291372 Opened 4 years ago Closed 3 years ago

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

Categories

(GeckoView :: General, defect)

defect
Not set

Tracking

(firefox52 fixed)

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: nalexander, Assigned: nalexander)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

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.
(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.
(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.
Blocks: 1315118
Blocks: 1316188
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!
Blocks: 1316220
Comment on attachment 8808843 [details]
Bug 1291372 - Produce Maven repository with GeckoView Javadoc and Sources JARs.

https://reviewboard.mozilla.org/r/91576/#review91718
Attachment #8808843 - Flags: review?(snorp) → review+
Pushed by nalexander@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/eb3dd588e1af
Produce Maven repository with GeckoView Javadoc and Sources JARs. r=snorp
This changed our APK size by 1.62%:
https://treeherder.mozilla.org/perf.html#/alerts?id=4101

Is this expected?
Flags: needinfo?(nalexander)
(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.
Flags: needinfo?(nalexander)
Assignee: nobody → nalexander
https://hg.mozilla.org/mozilla-central/rev/eb3dd588e1af
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52
Product: Firefox for Android → GeckoView
Target Milestone: Firefox 52 → mozilla52
You need to log in before you can comment on or make changes to this bug.