Closed Bug 776185 Opened 12 years ago Closed 12 years ago

ANDROID_VERSION_CODE needs to be based off MOZ_BUILD_DATE

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox16 fixed, firefox17 fixed)

RESOLVED FIXED
Firefox 17
Tracking Status
firefox16 --- fixed
firefox17 --- fixed

People

(Reporter: mozilla, Assigned: mfinkle)

References

Details

Attachments

(2 files)

Android Native needs to be the first 10 digits of MOZ_BUILD_DATE (if set); Android native armv6 would have to be the first 10 digits of MOZ_BUILD_DATE decremented by one; and android-xul would be the first 10 digits of MOZ_BUILD_DATE, incremented by one.

Background:

1) we pass in MOZ_BUILD_DATE to release builds to make sure the buildids are the same, a la
    make -f client.mk build MOZ_BUILD_DATE=20120717110313

2) android versionCodes are very important to get right in relation to each other.  Until we fixed bug 760740, we had to upload android-xul after android native, and android-xul had to have a larger versionCode.

Android-xul may no longer apply, but android-armv6 now does.
https://bugzilla.mozilla.org/show_bug.cgi?id=775232#c15

3) Merely going by build timestamp may result in the builds being built in the wrong order, with overlapping versionCodes.  Since we're already passing in a shared MOZ_BUILD_DATE, let's use that instead of assuming the builds will build in the right order.

4) Since armv6 builds need to have a lower versionCode than android native armv7, I'm requesting that we also decrement that versionCode.

This blocks our ability to build beta release builds of armv6.
Attached patch patchSplinter Review
I stole most of this from the XUL change, but I decrement instead of increment. I assume MIN_CPU_VERSION is ok to use and I am testing it the right way.

This built ok for me in my armv7 build (I think... where can I see the version code?)

I am pushing to Try too.
Assignee: nobody → mark.finkle
Attachment #644575 - Flags: review?(blassey.bugs)
Attachment #644575 - Flags: feedback?(aki)
Comment on attachment 644575 [details] [diff] [review]
patch

I think this will decrement.
However, I think this is also dependent on the computer time, rather than using MOZ_BUILD_DATE... I might be wrong.

This should be enough to let us build the two platforms at the same time, assuming android-armv6 starts before or in the same hour as android.
We can tie in MOZ_BUILD_DATE at a later time.
Attachment #644575 - Flags: feedback?(aki) → feedback+
Attachment #644575 - Flags: review?(blassey.bugs) → review+
If we're unlucky and end up decrementing yyyymmdd00 or even yyyymm0100, does Google Play care ? aka does the buildID have to be valid
http://developer.android.com/tools/publishing/versioning.html says it just needs to be an integer, so never mind me. I'm trigger happy after bug 741688.
Comment on attachment 644575 [details] [diff] [review]
patch

[Approval Request Comment]
User impact if declined: won't be able to push ARMv6 and ARMv7 builds to google play as the same product
Testing completed (on m-c, etc.): try run, just landed on inbound
Risk to taking this patch (and alternatives if risky): should be zero risk. Alternative is for RelEng to do two seperate builds at least an hour apart
String or UUID changes made by this patch: none
Attachment #644575 - Flags: approval-mozilla-beta?
Attachment #644575 - Flags: approval-mozilla-aurora?
Grepping for MOZ_BUILD_DATE gives me this chunk of code: http://hg.mozilla.org/releases/mozilla-beta/file/327b951ff6a8/config/Makefile.in#l81 .

Maybe the long term fix is something like

ifeq (,$(ANDROID_VERSION_CODE))
ifeq ($(MIN_CPU_VERSION),7)
ifdef MOZ_BUILD_DATE
ANDROID_VERSION_CODE=$(shell echo $(MOZ_BUILD_DATE) | cut -c1-10)
else
ANDROID_VERSION_CODE=$(shell $(PYTHON) $(topsrcdir)/toolkit/xre/make-platformini.py --print-buildid | cut -c1-10)
endif
else
# decrement the version code by 1 for armv6 builds so armv7 builds will win any compatability ties
ifdef MOZ_BUILD_DATE
ANDROID_VERSION_CODE=$(shell echo `echo $(MOZ_BUILD_DATE) | cut -c1-10` - 1 | bc)
else
ANDROID_VERSION_CODE=$(shell echo `$(PYTHON) $(topsrcdir)/toolkit/xre/make-platformini.py --print-buildid | cut -c1-10` - 1 | bc)
endif
endif
endif

?
which is not very pretty, but will avoid release-day unpredictability.
Knowing Murphy, this will happen on a chemspill day.
Maybe we should be going off buildid instead.
ifeq (,$(ANDROID_VERSION_CODE))
ifeq ($(MIN_CPU_VERSION),7)
ANDROID_VERSION_CODE=$(shell cat $(DEPTH)/config/buildid | cut -c1-10)
else
# decrement the version code by 1 for armv6 builds so armv7 builds will win any compatability ties
ANDROID_VERSION_CODE=$(shell echo `cat $(DEPTH)/config/buildid | cut -c1-10` - 1 | bc)
endif
endif

?
Not sure if this will work, but if it does, I think that will solve this bug.
Comment on attachment 644575 [details] [diff] [review]
patch

[Triage Comment]
Let's only take this on Aurora for now, as we're still evaluating ARMv6 builds for Beta 15.
Attachment #644575 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/013625180b24
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 17
Reopening until we use MOZ_BUILD_DATE or the buildid.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 644575 [details] [diff] [review]
patch

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

no longer needed on beta
Attachment #644575 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
This seems to work on try: https://hg.mozilla.org/try/rev/d829418828bc (https://tbpl.mozilla.org/?tree=Try&rev=79f315f60aa4).

Any problems having the UA_BUILDID changed as well?
(In reply to Chris AtLee [:catlee] from comment #14)
> Any problems having the UA_BUILDID changed as well?

No problem there.  UA_BUILDID is no longer used for anything on Android.
Attachment #650364 - Flags: review?(mark.finkle) → review+
https://hg.mozilla.org/mozilla-central/rev/87b84230f0ee
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.