android:versionCode magic for single-locale repacks

RESOLVED WONTFIX

Status

()

Firefox for Android
General
RESOLVED WONTFIX
6 years ago
2 years ago

People

(Reporter: Pike, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
AFAICT, we need to bump the android:versionCode in AndroidManifest.xml for the builds we offer for non-market downloads.

I doodled around a bit with the androguard code, and found that the BuildID we have in application.ini ends up, up to the day, as a lsb word (struct.pack format is "<L") in the compressed xml.

Which means, we can bump the versionCode as part of the repack logic, probably in unpack.

In the manifest I tried, the byte sequence only appears once, so we could start with just replacing that byt sequence with a bumped one. Not sure how reliable that is. Or we use a bunch of code from androguard to be smarter about locating the integer, or at least, narrowing down where it is. That'd be not too hard:

>>> bts=open('AndroidManifest.xml','rb').read()
>>> p=apk.AXMLParser(bts)
>>> p.next()
0
>>> p.next()
2
>>> p.getName()
u'manifest'
>>> p.buff._BuffHandle__idx
7640

and then rfind the sequence created by struct.pack('<L', 2012051504) and replace it, and write back the compressed file.

Not really tested the whole story, though.

Aki, Alex, do you have alternative ideas?

Also, how should we hook this up into the automation?
(Reporter)

Updated

6 years ago
blocking-fennec1.0: --- → ?

Comment 1

6 years ago
Be careful -- whenever we've tried to touch this file without actually doing a repackage, we've ended up with a non-runnable apk.

I'd love to be able to bump this at repack time, though.
The only solution I know of that will work is a re-|make package| but I'd love an alternate solution.

Comment 2

6 years ago
This could only be a blocking-fennec1.0 bug if we decide to move forward with web downloaded, single-locale, localization builds. Even still, we have a plan of how to move forward in that scenario without a versioncode change through repacks (2 separate builds for store/web APKs).

Comment 3

6 years ago
We went over this in mobile triage - we'll revisit this based upon our final l10n ship strategy later, but this won't be a blocker.
blocking-fennec1.0: ? → ---
(Reporter)

Comment 4

6 years ago
Hrm. Seems that AndroidManifest.xml is actually regenerated during the packaging step.

Can someone inspect the apks we generate (en-US, multi, and single-locale) to see which android:versionCode are actually in them?
Keywords: qawanted

Comment 5

6 years ago
I have apktool ( http://code.google.com/p/android-apktool/ ) so I can, later.

However, IIRC, the repack keeps the exact same versionCode as en-US.  And since the multilocale build is in the same objdir as the en-US build, it has the same versionCode as well.

Comment 6

6 years ago
Created attachment 625231 [details]
apktool output

Very interesting.

gd and he seem to be broken, so no data.
fa seems to be a couple days old.

For everything else, en-US and multi are 2012051803; the locale repacks are 2012051804 , suggesting that this isn't inherited from the repacked en-US build.

We need better logic to actively increment this instead of relying on the repack happening at a later hour than the en-US build, but this is promising.
Removing qawanted since the needed info has been added. Please see Comment 6.
Keywords: qawanted
If there's a need, it hasn't arisen in more than 3.5 years.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.