Closed Bug 1286944 Opened 8 years ago Closed 6 years ago

Build Process for Android partner distributions

Categories

(Release Engineering :: Release Requests, defect, P2)

Product:
Release Engineering
Component:
Release Requests
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mkaply, Unassigned)

References

Details

Similar to how we pull partner assets from Github and repackage desktop builds, we'd like to have the same infrastructure for Fennec builds.

nalexander created a "bouncer" apk that contains the partner customizations. We want to start by attempting to package those.

http://gecko.readthedocs.io/en/latest/mobile/android/fennec/bouncer.html

The key here is that the signature used to package these "bouncers" has to be the same signature that is used for official builds.

So there are some security implications.
Previous discussion around signing a demo was here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1284582
This has moved up significantly in priority with our push to do distributions this year, although the ask now is for the standard Firefox APK, not for the bouncer APK.

Rail was able to do a couple one off builds for a partner, but going forward, we're going to need a process to do this.

It should involve simply taking the Firefox APK, adding in the partner distributions and repackaging and resigning it.
(In reply to Mike Kaply [:mkaply] from comment #2)
> This has moved up significantly in priority with our push to do
> distributions this year, although the ask now is for the standard Firefox
> APK, not for the bouncer APK.

It would be nice to get rid of the bouncer APK support, then -- it's a bit of an odd out-growth, not exactly a hack but not mainstream either.
 
> Rail was able to do a couple one off builds for a partner, but going
> forward, we're going to need a process to do this.
> 
> It should involve simply taking the Firefox APK, adding in the partner
> distributions and repackaging and resigning it.

This should be straight-forward.  We just need to pull the distribution from GH (although I think specifying extra source repos to Task Cluster jobs was deprecated) and add a few mozconfig flags to get this.  This is probably already do-able with try builds.
Priority: -- → P1
Hi Max, per the comment3 ,

Could you please kindly share your views if this is feasible on Fennec ? 
Thank you very much !!
Flags: needinfo?(max)
(In reply to Rachelle Yang [:ryang][ryang@mozilla.com] from comment #4)
> Hi Max, per the comment3 ,
> 
> Could you please kindly share your views if this is feasible on Fennec ? 
> Thank you very much !!

Hi Rachelle, did you mean Mike (Kaply)?  And my comment #3 is about Fennec, so yes, it's feasible.
Flags: needinfo?(ryang)
Thank you, Nick.
Hi Max, 
Could you please help us with this for potential partner distribution? 
Thank you !
Flags: needinfo?(ryang)
Hi Joe and Barbara , it's feasible. 

But what's the requirements for which partners? 
Do you have more information/ background on what to tailor for ??  and for which distribution ?
Thank you very much !
Flags: needinfo?(jcheng)
Flags: needinfo?(bbermes)
The requirements should not be partner specific. We should have the ability to take any partner out of Github and have their customizations bundled with a Fennec APK.

I will create a sample partner public on Github for this.
(In reply to Mike Kaply [:mkaply] from comment #9)
> The requirements should not be partner specific. We should have the ability
> to take any partner out of Github and have their customizations bundled with
> a Fennec APK.
> 
> I will create a sample partner public on Github for this.

This already exists: https://github.com/mozilla/fennec-distribution-sample.  Everybody on this ticket needs to absorb https://bugzilla.mozilla.org/show_bug.cgi?id=1163084 and talk to jlund (and, to a lesser extent, myself) before re-building this particular wheel.
Thanks for the pointer, nick. I'm surprised this didn't come up earlier.

It looks like those builds have been turned off:

https://bugzilla.mozilla.org/show_bug.cgi?id=1307030

and I never saw a confirmation that they would work for private Github repositories. I'll ping jlund.
Hi Max, Julian, Nevin ,and Jing-Wei, 

Per comment 9,Mike suggested this build should not be partner specific.

and the method of these sample build is already turned off in firefox52(https://bugzilla.mozilla.org/show_bug.cgi?id=1307030 )

Do you have any idea or concern , or any suggested way to proceed ?

Thank you !
Flags: needinfo?(walkingice0204)
Flags: needinfo?(topwu.tw)
Flags: needinfo?(cnevinchen)
I've been in touch with mkaply. It is my understanding that this work can wait until next week. I am currently heavily involved with releases as it is uplift and release week.

Two note if it hasn't been discussed,

1) all android builds/tests/nightlies now use taskcluster as tier 1. Betas and Releases still use buildbot but we hope to migrate that as central rides the trains to beta and so on. This means we can probably, unlike last time, safely use taskcluster only.

2) scheduling now uses `mach taskgraph`. So while the way to scheduling will be foreign to what it was, adding a partner build at a per-checkin or try level, should be trivial

3) if these builds need releasing: e.g. updates/signing/artifact-permanence, you will need releng assistance after getting per-checkin builds set up.
Flags: needinfo?(jcheng)
I just started to read all these partner distribution related bugs. 
Base on what i'm reading on this bug, it looks like we are getting rid of the bouncer apk and will figure out a way to include partner customization as part of a bundled fennec apk and distribute to partners?

Just curious if we have discussed about some of the advantages of bouncer.apk that could give us some advantages when having partner discussion? such as 

1. apk size? it is always likely a concern from partners and bouncer apk could be a way to mitigate the size problem?

2. with bouncer apk, we probably don't have to constantly package a customized build whenever we have a new build so partners can include the latest build when they manufacture devices.

3. partner test criteria for a bouncer.apk and an actual customzed browser preloaded on device could be a lot different? it may give us more flexibility in bug priority/resolution discussions

my 2 cents
(In reply to Joe Cheng [:jcheng] (please needinfo) from comment #16)
> I just started to read all these partner distribution related bugs. 
> Base on what i'm reading on this bug, it looks like we are getting rid of
> the bouncer apk and will figure out a way to include partner customization
> as part of a bundled fennec apk and distribute to partners?
> 
> Just curious if we have discussed about some of the advantages of
> bouncer.apk that could give us some advantages when having partner
> discussion? such as 
> 
> 1. apk size? it is always likely a concern from partners and bouncer apk
> could be a way to mitigate the size problem?

So far APK size isn't an issue and even if it was, we would still need the partner process to put customizations into the bouncer APK. This bug is still relevant.

There is already work being done to reduce the size of the APK.

> 2. with bouncer apk, we probably don't have to constantly package a
> customized build whenever we have a new build so partners can include the
> latest build when they manufacture devices.

This bug is not about preloading, that is a separate discussion. This bug is more for partners that provide Firefox as a download with their customizations. In that case, the bouncer is not a good idea, because the user would have to do an install and then an upgrade.

We want the user to have an install of Firefox immediately.

> 
> 3. partner test criteria for a bouncer.apk and an actual customzed browser
> preloaded on device could be a lot different? it may give us more
> flexibility in bug priority/resolution discussions

I'm not sure what you mean here.
For the record, I've went through above thread and document, but I can't find any action item for Taipei Fennec team(for now). It seems that current design is enough. 
Maybe we can schedule a meeting to clarify the requirements (what and how to customize) and plan further.
Flags: needinfo?(max)
Flags: needinfo?(topwu.tw)
let me know if releng can provide any guidance on this once requirements are more known. I'm not sure how much work we can provide on our end but I can certainly help answer any questions or point you to someone who knows.
(In reply to Jordan Lund (:jlund) from comment #19)
> let me know if releng can provide any guidance on this once requirements are
> more known. I'm not sure how much work we can provide on our end but I can
> certainly help answer any questions or point you to someone who knows.

I think the main thing we need from releng is helping setting this up as a process, similar to our existing desktop partner process.

I picture partner customizations being checked out of Github and then builds being automatically created.

Based on what you've said, the actual build work is done. We just need to hook everything up...
Back to P2 since no one has been working on this.
Priority: P1 → P2
Just had a conversation with jlund where we worked out exactly what I'm trying to do here.

The goal is to have certain mobile repacks happen the same way that they happen on desktop.

So certain customizations are checked out from Github and added to the existing APK and repacked and resigned.

There's no need to worry about updates or anything like that. They will look exactly like Fennec release builds.

We don't think that reusing the dummy-apk is the right method here.

This is not urgent at this point, but hoping to get it on the radar for he next 3-6 months.

I'm clearing the needinfo because there's nothing needed from the mobile team at this point.

Rail, this is similar to what we had to do with the partner we talked about in Hawaii. Just automating that.
Flags: needinfo?(walkingice0204)
Flags: needinfo?(bbermes)
(In reply to Mike Kaply [:mkaply] from comment #22)
> Rail, this is similar to what we had to do with the partner we talked about
> in Hawaii. Just automating that.

Which was simple as https://hg.mozilla.org/build/braindump/file/tip/mobile-related/repack.sh
(In reply to Mike Kaply [:mkaply] from comment #22)
> Just had a conversation with jlund where we worked out exactly what I'm
> trying to do here.
> 

Thanks for summarizing our meeting. cc'n catlee.

Q3 is a possibility, but that depends on current high priority work. Either way, I'll update this bug when I'm back from PTO the week of May 15th and get this triaged in our queue.
Since I'm temporarily managing part of the releng team, I sent a followup email to Mike to try to gauge business impact/priority.
Flags: needinfo?(mozilla)
Email sent. I think this can move out of Q3.
Flags: needinfo?(mozilla)
Bulk change of QA Contact to :jlund, per https://bugzilla.mozilla.org/show_bug.cgi?id=1428483
QA Contact: coop → jlund
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Component: Custom Release Requests → Release Requests
You need to log in before you can comment on or make changes to this bug.