Closed Bug 659544 Opened 9 years ago Closed 8 years ago

Android partner repack capability

Categories

(Release Engineering :: Release Automation: Other, defect, P3)

ARM
Android
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aki, Assigned: aki)

References

Details

(Whiteboard: [releases][android][automation])

Attachments

(4 files, 3 obsolete files)

This won't happen immediately, but we'll need support for this eventually, and it would be nice to have support for it in partner-repacks/scripts/partner-repacks.py beforehand so we don't have to scramble.
Blocks: 627271
Whiteboard: [releases][android][automation]
Whiteboard: [releases][android][automation] → [releases][android][automation][android_tier_1]
per irc w/aki, this doesnt block android becoming tier1, this just gives us more options whenever we want to do custom releases on android.
Whiteboard: [releases][android][automation][android_tier_1] → [releases][android][automation]
Blocks: 701816
This will be easier to do once Axel has a single locale repack solution for Android apks.
Depends on: 702302
Assignee: nobody → aki
Blocks: 707000
Attachment #589689 - Flags: review?(coop)
Attachment #589689 - Attachment is obsolete: true
Attachment #589689 - Flags: review?(coop)
Attachment #589690 - Flags: review?(coop)
Comment on attachment 589689 [details] [diff] [review]
remove maemo from partner-repacks.py

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

Looks good. Yay for removing dead code.
Attachment #589689 - Attachment is obsolete: false
Comment on attachment 589690 [details] [diff] [review]
remove maemo from partner-repacks.py, also no SBOX vars

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

Looks even better now. ;)
Attachment #589690 - Flags: review?(coop) → review+
Attachment #589689 - Attachment is obsolete: true
Comment on attachment 589690 [details] [diff] [review]
remove maemo from partner-repacks.py, also no SBOX vars

http://hg.mozilla.org/build/partner-repacks/rev/864ccaa580d0
Attachment #589690 - Flags: checked-in+
Axel, Michael, Mark, Matthew:

Hey, I'm trying to get Android partner repacks going, so that we can ship the same bits to the Android (and possibly Amazon) markets that we're shipping on the website, without offering the market users AUS updates.

Since I'm going to be downloading a pre-built apk, inserting a file, and repackaging, I need a packaging solution unburdened by other logic or other steps.

Currently there are two ways to create a working Android package that I know of:  |make package| and the l10n |make installer-%| which calls |make repackage-zip-%|; both seem to use the MAKE_PACKAGE macro.

http://hg.mozilla.org/mozilla-central/file/f92194f05828/toolkit/mozapps/installer/packager.mk#l813

http://hg.mozilla.org/mozilla-central/file/f92194f05828/toolkit/mozapps/installer/packager.mk#l537

http://hg.mozilla.org/mozilla-central/file/f92194f05828/toolkit/locales/l10n.mk#l140

I think I need to add a third target that is a simplified version of these two targets -- basically, the packaging portion without all the copying of built objects or l10n strings.

Do you agree, and if so, do you know where this target should go or any pitfalls I should avoid?
Sounds about right.

I'd suggest to either add to the makefile in mobile/android/installer or add a subdir there. If you go for a subdir, to use the packager.mk macros, you need to define PACKAGER_NO_LIBS in your makefile. Makes sure that you don't accidently build libs.

Current pitfall is, you can't re-use the stage more than once, you need to clobber that, unpack, tweak, repack. Which is probably what you'll be doing anyway, so it's not too bad, right?
It looks like I should create a partner.js and put it inside of omni.ja defaults/pref/partner.js . I'm going to explore this route.
# download fennec as fennec.apk
mkdir -p defaults/pref
echo 'pref("app.partner.android-market", "android-market");' > defaults/pref/partner.js
unzip fennec.apk omni.ja
zip -9r omni.ja defaults/pref/partner.js 
zip -9r fennec.apk omni.ja
zip fennec.apk -d 'META-INF/*'

# sign
# zipalign
# install
# go to about:config
# verify app.partner.android-market is there and set to 'android-market'
# SUCCESS!
Progress at https://github.com/escapewindow/mozharness/tree/android-partner .
I still need to finish refactoring Android signing, add error checking to repack(), add the upload (and optional signing step?), and tie into the release automation.
This checkconfigs; I need to verify it works.
This patch adds Android partner repack capability and moves most Android signing into a base module.  It also creates a transfer.py.

* Added config files for partner repacks
* Added partner repack info to signing config files
* Added a ZipErrorList and ZipalignErrorList to mozharness.base.errors
* Added more error checking to OSMixin methods
* Added an OSMixin.write_to_file() and OSMixin.read_from_file() to standardize those operations
* Added an AndroidSigningMixin and moved passphrase(), verify_passphrases(), sign_apk(), unsign_apk(), align_apk() there.
* Added a mozharness.base.transfer with rsync_upload_directory() and rsync_download_directory() methods.
* Added a mobile_partner_repack.py.  Currently it only adds a partner.js that modifies the update channel.  It has optional signing actions, but default behavior is currently to upload to unsigned/partner-repacks/ only.
* Added a --with-partner-repacks option to sign_android.py that adds partner repack downloads and signing.  (Upload happens automatically with the rsync).
* Silenced the expected pyflakes errors.

I've run this through a number of sign_android and mobile_partner_repack tests locally.  I haven't tested having this tied into buildbot release automation yet, but I'm not too worried about that.
Attachment #608930 - Flags: review?(rail)
No longer blocks: hg-automation
Mass move of bugs to Release Automation component.
Component: Release Engineering → Release Engineering: Automation (Release Automation)
Flags: checked-in+
No longer blocks: hg-automation
Attachment #608495 - Attachment is obsolete: true
Attachment #609822 - Flags: review?(rail)
Attachment #608496 - Attachment description: (needs testing) [custom] mozharness partner repacks → [custom] mozharness partner repacks
Attachment #608496 - Flags: review?(rail)
Attachment #608496 - Attachment is obsolete: true
Attachment #608496 - Flags: review?(rail)
Attachment #609843 - Flags: review?(rail)
Attachment #609822 - Flags: review?(rail) → review+
Attachment #608930 - Flags: review?(rail) → review+
Attachment #609843 - Flags: review?(rail) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
I merged this to production for the 12.0b3 release.
Blocks: 879328
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.