1137586 - Use different version codes for each API range

Status: RESOLVED FIXED

(Firefox Build System :: Android Studio and Gradle Integration, defect)

Description

[Richard Newman [:rnewman]]

This is my proposal from Bug 1120762. It results in APKs that seem to cooperate when uploaded to Play.

Comment 1

[Richard Newman [:rnewman]]

Attachment: Use different computed version codes for split APKs. v1

Different APKs with the same version code cannot be uploaded to Google Play.

We want the later API range version to win, just by default.

We need x86 to beat ARMv7 even at a higher API range, because we don't ever want to deliver an ARM APK to an x86 device with an emulation layer.

So this patch does the following:

* Add the MIN_SDK_VERSION to the version code. That'll give us a gap of 2.
* Additionally increment the 9-23 x86 version by 3, so that the 9-23 x86 APK has a higher version code than the 11-23 ARMv7.
* Eliminate the ARMv6 logic.

Comment 2

[Richard Newman [:rnewman]]

There is an alternative approach here, which is to apply the largest version code to the lowest APK, relying on the supported API range but facing in the opposite direction.

I'm less keen on that, simply because minSdkVersion is 'stronger' than maxSdkVersion, being enforced on the device.

Comment 3

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8570321 [details] [diff] [review]
Use different computed version codes for split APKs. v1

Review of attachment 8570321 [details] [diff] [review]:
-----------------------------------------------------------------

This whole approach is so fragile :/

It offends my engineering sensibilities that we're exposing ourselves to overlapping version code ranges, although I am aware in practice that any one builder will either be building the same configuration (and therefore will see a monotonically increasing sequences of codes) or will be building all configurations but with a large gap between builds (and therefore will not see overlapping version code ranges).  But it still smells wrong, and it's difficult to adjust and correct in the future.

The one thing that really worries me is he increment by 3 for x86; it's going to be almost impossible to keep this correct as the min ranges change.  How would you feel about doing something like

buildid + (64 * {0 for arm, 1 for x86}) + mindsk?

That way the arm and x86 builds won't overlap.  This gives headroom for 64 android versions.  The cost is that it pushes overlapping build ranges into the realm of hours (I think -- the cut 10 gives us yyyymmddhh).  We were already there with the +1 and -1, but this makes it worse.

I don't understand why we cut 10 but I'll assume it's for a good reason.

In conclusion: this is an expedient conclusion.  I'm worried about the hard coded 3.  We change this once every ~2 years; we can live.  Do as you see fit.

Comment 4

[Richard Newman [:rnewman]]

Nick and I discovered that the current build ID is horrific: it's keyed by when the builder picks up the job.

If x86 is picked up on one side of an hour boundary, and ARMv7 on the other side, they'll have the same version code!

If x86 is picked up one day, and ARMv7 on the next day, x86 users will get an ARMv7 build!

This patch does not completely fix this situation. I'll file a follow-up to use a completely different approach for version code computation within the confines of a signed 32-bit int.

I'll land this now, because it only consumes an extra ~12 version codes, and should get us a shippable beta.

Comment 5

[Richard Newman [:rnewman]]

https://hg.mozilla.org/integration/fx-team/rev/cfbb48d0e47e

Comment 6

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8570321 [details] [diff] [review]
Use different computed version codes for split APKs. v1

AFAIK the plan is to test this with the 37 Beta builds. Please proceed with the change to get the Fennec split APKs working in 37+.

Comment 7

[Richard Newman [:rnewman]]

https://hg.mozilla.org/mozilla-aurora/rev/33147d1285b8

Comment 8

[Richard Newman [:rnewman]]

https://hg.mozilla.org/releases/mozilla-beta/rev/cea5c7cdfa13

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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