933017 - Write a tool to assemble a local system.img after downloading the binaries

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(Spun out of bug#910131 comment#8, and comment#15. This seemed best component, and initial owner, based on discussion in bug#910131. Please move and/or reassign as needed.)

...

We can create two different types of packages, with different complexity for building and end-user flashing:

1 - full system.img, userdata.img, boot.img.  These will include all of the Gecko, Gonk, AOSP and closed-source binaries baked into images.  These can be directly flashed to the devices using a simple fastboot tool.

2 - "partial" images and a tool, consisting of zip files/tarballs of the Gecko, Gonk, AOSP packages as well as a link to the closed-source binaries.  The end user would then run a tool that would assemble a local system.img after downloading the binaries. [There are some benefits to this, because that tool could do partial b2g-only updates as well.]

I believe that we could already do #2, but it would require creating the tool to do the final assembly.  It would also be less trivial for developers to use this tool, but that's a property of the engineering effort involved in creating that tool.  (IMO, I would guess that creating such a tool would take an average developer a week or less.)

What we'd really like to do is #1, because we already produce those images, and developers of all kinds are familiar with that flashing process.  But that involves us redistributing the closed source drivers as part of a full binary system image.

Whether we do #1 or #2; we have three target audiences:

A - internal QA.

B - internal (MoCo) developers.

C - external developers/users.

The question that I think we need to answer is to which groups can we provide solution 1 or 2.  If we can provide solution 1 to all three groups, then great; we don't need to touch 2.  If we can provide solution 1 to A/B, but need solution 2 for C, then we'll have to implement solution 2.

...
(In reply to Jishnu Menon :jishnu from comment #18)
> (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #15)
> > (In reply to Jishnu Menon from comment #14)
> > > Hi Vlad,
...
> > 
> > I'll look into #2.  My gut instinct is that it's not a lot of work, just
> > need to find someone to do it.  It can even be done by a contractor, if we
> > can find someone on short notice.
> 
> Let's try #2 - let me know what you find.
>

Comment 1

[Dale Harvey (:daleharvey)]

As mentioned in the bug I just linked, Micheal Wu has a script that will generate a update.zip to be able to install via cwm recovery, the cwm recovery process isnt particularly friendly but it seems like it should be able to be fixed up to be relatively developer friendly

Right now I am figuring out the build deps for jelly bean on osx (I can build ics fine) then I was planning to test out and see if I could get to a point where we have a usable build for the general public. 

I dont have any experience in device porting / internals (frontend + gecko dev) but would love to see this happen / happy to get any guidance.

Comment 2

[Dale Harvey (:daleharvey)]

Needinfoing Micheal in case there is any updated information, right now I will carry on trying to see how good I can get the update.zip process to be, but if theres another approach that may be better, would be handy to know

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

mwu, can you attach the latest version of your script here?

Comment 4

[Michael Wu [:mwu]]

Attachment: generate-conversion-update.sh

Comment 5

[BMO Automation]

Firefox OS is not being worked on