Factory images available for Galaxy Nexus

12,024 views
Skip to first unread message

Jean-Baptiste Queru

unread,
Dec 1, 2011, 2:48:32 PM12/1/11
to android-...@googlegroups.com
We've just made the factory image for Galaxy Nexus GSM/HSPA+ available
for download at the following URI:

http://code.google.com/android/nexus/images.html

This file, once unarchived, contains the bootloader, baseband, and the
rest of the system.

You'll need to have fastboot in your path, and to have the device in
fastboot mode before you can use it (either "adb reboot bootloader",
or press-and-hold both volume-up and volume-down then press-and-hold
power).

For convenience, a flash-all.sh script is provided as well, which
restores the entire phone to its factory state.

If you're only flashing some of the images, I strongly recommend
flashing things in the same order as flash-all.sh. Specifically, flash
the bootloader before the radio, and reboot after flashing the
bootloader or the radio.

Don't forget that after flashing back to a factory state, your
bootloader is still unlocked. Don't forget to lock it back in order to
secure your device ("fastboot oem lock").

Hopefully this'll be useful to people flashing custom AOSP builds, as
it provides a clean supported way to return to factory state.

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

Jacques Martin

unread,
Dec 1, 2011, 4:13:42 PM12/1/11
to Android Building
Will you make a factory image available for the Galaxy Nexus LTE
Verizon version once the device has been released (please !) ?
Thanks.

Jean-Baptiste Queru

unread,
Dec 1, 2011, 4:23:23 PM12/1/11
to android-...@googlegroups.com
That'd be the preferred option indeed, but the future is always uncertain.

JBQ

> --
> You received this message because you are subscribed to the "Android Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en

Jean-Baptiste Queru

unread,
Dec 1, 2011, 4:48:24 PM12/1/11
to android-...@googlegroups.com
A quick clarification:

While the hardware name for the GSM/HSPA+ Galaxy Nexus is "maguro",
the codename for the retail software configuration is "yakju" and
that's the name that currently appears on the download page. The yakju
build is indeed meant to be flashed on maguro devices.

The names don't match, because there could end up being multiple
software configurations for the same hardware, since there are
routinely per-country or per-operator software customizations for the
same hardware. As an example, crespo had soju, sojua and sojuk. Going
back much further, sapphire had opal, vfpioneer and zaku. Having
different names allows to better classify between hardware-level
problems and software-level problems during development.

Similarly, the name "full_maguro" used in AOSP builds is the name of
the software configuration that contains the full set of AOSP
functionality, configured for a maguro device.

I hope that makes sense.

I will be clarifying the content of the download page.

JBQ

athompso

unread,
Dec 2, 2011, 12:52:09 AM12/2/11
to android-...@googlegroups.com
Is there any likelihood of factory images being made available for the previous device(s), particularly the Nexus S?
 
-Adam Thompson

Jean-Baptiste Queru

unread,
Dec 2, 2011, 10:32:49 AM12/2/11
to android-...@googlegroups.com
I'd love to. Obviously, we've got the technical aspects taken care of
(it wasn't hard), but there are some non-technical aspects that are
specific to each device, so at this point I'm not 100% sure (if I was
immediately possible, I'd have released all those images at the same
time).

Hopefully I'll have good news soon.

JBQ

> --
> You received this message because you are subscribed to the "Android
> Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en
>

--

moa-code

unread,
Dec 4, 2011, 6:27:10 PM12/4/11
to Android Building
Hi,

This is great.

I'm guessing the ITL41F build is the version with the volume fix in,
right?

If this is the case, can someone do a step-by-step on how to flash
this via windows. My Nexus it almost unusable due to this bug and has
been since I got it, I've still not had the OTA for this, so any help
would be superb!

Anyone? :)


On Dec 2, 3:32 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I'd love to. Obviously, we've got the technical aspects taken care of
> (it wasn't hard), but there are some non-technical aspects that are
> specific to each device, so at this point I'm not 100% sure (if I was
> immediately possible, I'd have released all those images at the same
> time).
>
> Hopefully I'll have good news soon.
>
> JBQ
>
>
>
>
>
>
>
>
>
> On Thu, Dec 1, 2011 at 9:52 PM, athompso <athom...@athompso.net> wrote:
> > Is there any likelihood of factory images being made available for the
> > previous device(s), particularly the Nexus S?
>
> > -Adam Thompson

> >  athom...@athompso.net

Jean-Baptiste Queru

unread,
Dec 5, 2011, 10:31:57 AM12/5/11
to android-...@googlegroups.com
Well, in theory, you'd need a port of fastboot to Windows, an
appropriate USB configuration, and the same instructions might work
(assuming of course that you run the steps of the script one by one).

From where I sit, that's very theoretical, since Windows isn't a
supported platform for AOSP work, so I have no idea what it'd take to
make this work.

JBQ

bubodroid

unread,
Dec 5, 2011, 8:27:09 AM12/5/11
to Android Building
Hi JBQ,

*Please* do this for your previous Nexus S too?

All the very best;

B.

On Dec 2, 3:32 pm, Jean-Baptiste Queru <j...@android.com> wrote:

> I'd love to. Obviously, we've got the technical aspects taken care of
> (it wasn't hard), but there are some non-technical aspects that are
> specific to each device, so at this point I'm not 100% sure (if I was
> immediately possible, I'd have released all those images at the same
> time).
>
> Hopefully I'll have good news soon.
>
> JBQ
>
>
>
>
>
>
>
>
>
> On Thu, Dec 1, 2011 at 9:52 PM, athompso <athom...@athompso.net> wrote:
> > Is there any likelihood of factory images being made available for the
> > previous device(s), particularly the Nexus S?
>
> > -Adam Thompson

> >  athom...@athompso.net

Jean-Baptiste Queru

unread,
Dec 5, 2011, 10:36:24 AM12/5/11
to android-...@googlegroups.com
That would be very nice, and that's something I've been trying to make
happen for over a year (and for Nexus One before that). At the
technical level, the process would be identical. The difficulty is on
the non-technical side, with the need to obtain appropriate
distribution contracts.

JBQ

Developer

unread,
Dec 8, 2011, 11:56:32 AM12/8/11
to android-...@googlegroups.com
Dear JBQ,

what is the system.img filesystem? Is it EXT4 or yaffs2? For some reason I'm not able to mount it and extract, not either on Ubuntu or Windows. Any help will be highly appreciated!

Also what is the difference between this and Samsung builds?

Jean-Baptiste Queru

unread,
Dec 8, 2011, 12:07:01 PM12/8/11
to android-...@googlegroups.com
Those files are only meant to be used with fastboot to restore a
device to its factory state.

I don't know how they differ from Samsung's customized builds.

JBQ

> --
> You received this message because you are subscribed to the "Android
> Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en
>

--

Message has been deleted

Jean-Baptiste Queru

unread,
Dec 8, 2011, 12:11:02 PM12/8/11
to android-...@googlegroups.com
You're only supposed to flash them whole, to a Galaxy Nexus, as is.

For individual files, http://code.google.com/android/nexus/drivers.html

JBQ

On Thu, Dec 8, 2011 at 9:08 AM, Michał Banszel <michal....@gmail.com> wrote:
> So it's not possible to extract it's content?
>
> 2011/12/8 Jean-Baptiste Queru <j...@android.com>:

Chris Bossardet

unread,
Dec 8, 2011, 2:06:37 PM12/8/11
to Android Building
So far (looking at the XDA forums), we've seen three different
software builds for the GSM version. yakju (which is listed as a
Google build in the build file), yakjuxw (which is listed as Samsung),
and 'yakjusc' (which seems to be the build for DoCoMo in Japan). I
checked my own device and it seems I have the Samsung yakjuxw build.
As such, I've yet to receive any OTA update. I'm still on ITL41D
instead of ITL41F. That seems to be the case with everyone on the
Samsung build, as well. I was wondering if you had any information
about specific software revisions? Specifically, will we still get
updates direct from Google OTA with a yakjuxw build or am I better off
flashing the files you posted here to make sure I stay current?

Jean-Baptiste Queru

unread,
Dec 8, 2011, 2:17:53 PM12/8/11
to android-...@googlegroups.com
yakjusc and yakjuxw are indeed the two Samsung-prepared builds I'm
aware of at the moment, but I'm discovering them as they get released.

I only have some visibility over the builds that are prepared by
Google, i.e. yakju. Everything else comes from Samsung and I don't
know what their schedules and release plans are.

I can't guarantee that flashing the yakju files that I posted would
work on a device that originally shipped with yakjuxw, as I don't have
access to such devices. The hardware is supposed to be close, but I
don't know for sure that it's close enough.

JBQ

> --
> You received this message because you are subscribed to the "Android Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en
>

--

Chris Bossardet

unread,
Dec 8, 2011, 2:44:11 PM12/8/11
to Android Building
Is there any way you could ask around and find out any more
information for us? Mostly just want to know if the Google files are
compatible or not. I hate to bug you about it, but I'd really like to
get updates direct from Google as I did with my Nexus One before this.
Don't want to flash a file that may cause issues.

Jean-Baptiste Queru

unread,
Dec 8, 2011, 2:57:54 PM12/8/11
to android-...@googlegroups.com
I've been asking, but I've yet to receive answers. I'll let you know
if I learn anything new.

JBQ

Morris Shamah

unread,
Dec 8, 2011, 8:09:37 PM12/8/11
to Android Building
I have a yakjuxw build, but the device name is Maguro. Does this imply
that the hardware is identical/close enough?

Sorry if the question has an obvious answer, this is new to me.

Jean-Baptiste Queru

unread,
Dec 9, 2011, 9:31:38 AM12/9/11
to android-...@googlegroups.com
I don't know, sorry. I'm only familiar with yakju devices.

JBQ

Dirk Jäckel

unread,
Dec 9, 2011, 10:23:27 AM12/9/11
to android-...@googlegroups.com
On Thu, Dec 8, 2011 at 18:08, Michał Banszel <michal....@gmail.com> wrote:
> So it's not possible to extract it's content?
>

If someone knows the answer, I would also be interested to explore the
contents of these files.
I suppose JBQ is not allowed to tell us even if he knew.

Regards,
Dirk

Matthew Brideau

unread,
Dec 9, 2011, 6:51:30 PM12/9/11
to Android Building
So after applying the ITL41D version, I reboot and get a prompt to
install ITL41F.

The device powers off and tries to install and suddenly stops.

It then goes into recovery and gives me the error:

E: failed to verify whole-file signature
E: signature verification failed
Installation aborted

I then reboot and my build is still listed as ITL41D and I can no
longer find the system update available.

Any ideas on this issue?

Jean-Baptiste Queru

unread,
Dec 9, 2011, 7:10:18 PM12/9/11
to android-...@googlegroups.com
Let me try to reproduce. It's normal that you'd get ITL41F
immediately. It's not normal that ITL41F wouldn't apply.

JBQ

Jean-Baptiste Queru

unread,
Dec 9, 2011, 7:27:43 PM12/9/11
to android-...@googlegroups.com
I've tried to reproduce, but everything worked fine for me.

The odd part is that the signature of an OTA gets verified twice: once
after downloading (to avoid an unnecessary reboot) and once within
recovery (defense in depth). In your case, the first verification
succeeded, but the second one failed.

Is there any possibility that you'd have restored the images one by
one and wouldn't have restored recovery, so that you might be running
e.g. an AOSP recovery, which doesn't check against the same
signatures.

JBQ

Matthew Brideau

unread,
Dec 9, 2011, 7:46:12 PM12/9/11
to Android Building
I will try re-flashing recovery.

Is it possible you have any OS X instructions to install the images
because I had to use windows and I am not entirely familiar.

On Dec 9, 6:27 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I've tried to reproduce, but everything worked fine for me.
>
> The odd part is that the signature of an OTA gets verified twice: once
> after downloading (to avoid an unnecessary reboot) and once within
> recovery (defense in depth). In your case, the first verification
> succeeded, but the second one failed.
>
> Is there any possibility that you'd have restored the images one by
> one and wouldn't have restored recovery, so that you might be running
> e.g. an AOSP recovery, which doesn't check against the same
> signatures.
>
> JBQ
>
>
>
>
>
>
>
>
>
> On Fri, Dec 9, 2011 at 4:10 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > Let me try to reproduce. It's normal that you'd get ITL41F
> > immediately. It's not normal that ITL41F wouldn't apply.
>
> > JBQ
>

Jean-Baptiste Queru

unread,
Dec 9, 2011, 10:16:19 PM12/9/11
to android-...@googlegroups.com
I expect that the same script should work without difficulty on MacOS and Linux, though I have not tested it on a Mac. As long as you have fastboot in your path it should work fine.

JBQ

Matthew Brideau

unread,
Dec 10, 2011, 9:58:14 AM12/10/11
to Android Building
I got it to work just by flashing the recovery in the first image by
itself.

Don't know how it got messed up in the first place, thanks!

Jean-Baptiste Queru

unread,
Dec 10, 2011, 3:56:36 PM12/10/11
to android-...@googlegroups.com
All right, glad to know that was it. I'll keep an eye on this during my testing in case I ever see a situation where one of the partitions fails to flash.

JBQ

Samuel B. Quiring

unread,
Dec 10, 2011, 1:03:53 PM12/10/11
to android-...@googlegroups.com
Hi,

I have not learned much about git and repo, yet. So I apologize
if this is a question with an obvious answer.

Is there a way for me to "repo sync" the AOSP source from Google
into a directory tree e.g., .../<android root>, then set that
directory tree up as a local central repository from which I can
do further "repo init" and "repo sync" operations and then
"git commit" and "git push" back into? For example:

.../<android-root> -- from google (local repository)

.../<my-galaxy-nexus> -- repo sync from .../<android-root>
.../<my-emulator> -- ditto
.../<my-panda> -- ditto

I am envisioning this use case: I make a change to a file
in <my-panda>, "git commit", then "git push" it back to
<android-root>. Then I go into <my-emulator>, do a "repo sync",
pulling from <android-root> to get the change.

Is there documentation on how to set something like this up? I'm
working by myself on a single computer. I'm trying to simplify
my situation, so I don't need a complex solution that supports tens
of developers spread across the world. But I would love to have a
simple solution, even if it did support tens of developers spread
across the world :-) .

-Sam


Jean-Baptiste Queru

unread,
Dec 10, 2011, 4:10:53 PM12/10/11
to android-...@googlegroups.com
The first part is easy(sharing a common sync):

First sync a mirror. E.g. in /usr/local/android/mirror, run repo init -u http://android.googlesource.com/mirror/manufest ; repo sync - Note that this isn't your usual manifesT URI.

Then,  sync from that mirror: repo init -u /usr/local/android/mirror/platform/manifest.git ; repo sync.

Whenever you want to sync from the server, you first need to sync the mirror, then each client.

Now, the part I don't know about is how to push anything back to your local mirror to share it between clients.

JBQ

Eric Finseth

unread,
Dec 10, 2011, 10:01:50 PM12/10/11
to android-...@googlegroups.com
Since the local mirror is just a collection of git repositories, I
would think that local commits can just be pushed directly.

Three comments:
1. Create your own branch to work on so that the mirror can continue
to run repo sync without collisions
2. You will need to modify your manifest to point to your local
branch. Also, you probably want to rename your remote to be something
other than aosp.
3. repo forall -c '..' is your friend for dealing with branch management.

-Eric

Magnus Bäck

unread,
Dec 11, 2011, 10:02:14 AM12/11/11
to android-...@googlegroups.com
On Saturday, December 10, 2011 at 19:03 CET,

"Samuel B. Quiring" <s...@sbqsam.com> wrote:

I don't know of any documentation that goes through this step by step,
but most of it is basic Git, and there are several books about Git.

It's certainly possible to so what you want to do. As Eric has pointed
out in arecent message in this thread, you shouldn't push any updates to
the same branch from which you fetch from AOSP. If you do, upon the next
"repo sync" in your mirror your changes will be rewritten, or the fetch
from AOSP will fail (depending on how the mirrored gits are set up on
your machine).

For each git that you want to mirror and work in, you can either create
a branch in the same git or make another mirror somewhere else where you
keep your own changes. The latter might seem really stupid, but the
point is that you don't have to modify the manifest file -- it's the
Git URL that determines whether you fetch stock AOSP code or your own
modified copy. If you create a branch in the existing mirror git,
you'll also have to branch the manifest git and update the "revision"
atttribute so that the manifest points to the correct branch. This
isn't difficult to do, but it does mean that you'll have to merge the
manifest git when it's updated in AOSP (which doesn't happen that often).

What we do is sync all AOSP branches into a branch namespace of
their own, say, aosp/. In other words, AOSP's master branch becomes
aosp/master internally, AOSP's ics-mr0 branch becomes aosp/ics-mr0, and
so on. You could do it the other way around, i.e. place your branches
under mycompany/ and keep the original AOSP branches on the top level,
but this only works if you have a single upstream. With multiple
upstreams (hardware vendors or projects like android-x86.org) you'll
have to pick a single upstream to live at the top level.

I suggest any follow-ups in this thread to be to the repo-discuss
mailing list.

Also Samuel, please don't hijack other people's threads. If you want
to start a new topic, compose a new message. Don't reply to someone
else's message. This is basic mailing list etiquette.

--
Magnus B�ck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson

Developer

unread,
Dec 14, 2011, 7:29:44 PM12/14/11
to Android Building
@JBQ any news about factory images 53F (or newer) for yakju or mysid?

Thanks for your answer

Jean-Baptiste Queru

unread,
Dec 14, 2011, 9:24:27 PM12/14/11
to android-...@googlegroups.com
One step at a time :)

At the moment the ones that are available (ITL41D and ITL41F for
yakju) match what's officially available at retail. Those are enough
to restore to factory state, which can then receive OTAs, if you're so
impatient that I can't work fast enough for your use case.

As a note, please be sure to mention the full build code. The only
reason why we keep them that short is to make sure that people mention
them whole to avoid any ambiguity.

JBQ

On Wed, Dec 14, 2011 at 4:29 PM, Developer <michal....@gmail.com> wrote:
> @JBQ any news about factory images 53F (or newer) for yakju or mysid?
>
> Thanks for your answer
>

jojo ismael

unread,
Dec 15, 2011, 2:19:30 AM12/15/11
to android-...@googlegroups.com
thanks!!!

Michał Banszel

unread,
Dec 15, 2011, 5:06:03 AM12/15/11
to android-...@googlegroups.com
@JBQ I'm not impatient in any way. I just wanted to know if factory
images for yakju or mysid will be updated here.
I don't care about restoring to factory state, we are in
android-building group. So I was just expecting "3 days", "3 weeks",
"3 months" or whatever,
the thing with me being impatient was not needed here.

2011/12/15 Jean-Baptiste Queru <j...@android.com>:

Jean-Baptiste Queru

unread,
Dec 15, 2011, 10:25:09 AM12/15/11
to android-...@googlegroups.com
Sorry, I misunderstood your question. I thought you were asking
specifically about a future unreleased version, and since the factory
images that get released only match consumer releases, I was a bit
surprised.

It's hard to talk about the future with much certainty as it keeps
changing. I can very well think of certain questions that would have
had a different answer every day of the week so far.

My goal is to make factory images available as much as contract
constraints allow me to, within a reasonable timeframe after the
matching builds become available to a majority of users. That's just a
goal, though, and many factors in there are outside of my control.

JBQ

athompso

unread,
Dec 15, 2011, 4:07:39 PM12/15/11
to Android Building
I'm curious... when you say "officially available at retail", are you
implying that there *are* phones "officially available at retail"? (I
don't count buying sim-locked phones from my carrier as "retail".)

Does anyone here know if BestBuy in either USA or Canada will be
selling SIM-unlocked GSM-capable phones like the Nexus S? [Perhaps it
would be best to reply privately, I don't want to completely hijack
the thread...]


On Dec 14, 8:24 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> At the moment the ones that are available (ITL41D and ITL41F for
> yakju) match what's officially available at retail. Those are enough
> to restore to factory state, which can then receive OTAs, if you're so
> impatient that I can't work fast enough for your use case.

> [...]

-Adam Thompson
atho...@athompso.net

Jean-Baptiste Queru

unread,
Dec 15, 2011, 4:16:30 PM12/15/11
to android-...@googlegroups.com
I meant "sold to consumers", sorry if that was confusing. From where I
sit the logo on the store that sells the phone makes little
difference, forgive me for not paying much attention to those. I have
no visibility over the decisions that shape the exact availability of
devices.

JBQ

Adam

unread,
Dec 16, 2011, 10:12:04 AM12/16/11
to Android Building
Can I just ask what command to use in fastboot to flash the ITL41F
factory image using the flash-all.sh script?

Jean-Baptiste Queru

unread,
Dec 16, 2011, 10:20:55 AM12/16/11
to android-...@googlegroups.com
You can run the flash-all script directly (once the device is in
fastboot mode), or if you're feeling adventurous you can see what's in
the script and pick the commands you want to run one by one.

JBQ

On Fri, Dec 16, 2011 at 7:12 AM, Adam <adip...@gmail.com> wrote:
> Can I just ask what command to use in fastboot to flash the ITL41F
> factory image using the flash-all.sh script?
>

inf

unread,
Dec 18, 2011, 12:51:46 PM12/18/11
to android-...@googlegroups.com
I don't know what could be wrong, but every time i try to "install" these factory images this happens:

Everything is fine with ITL41D and ITL41F, but as soon as I update to ICL53F the problem starts. So when the phone boots, in the welcome/setup screen I get an FC from a process com.android.phone. This happens EVERY time I boot the phone, everything seems to work after I press to OK button to get rid of the problem.

This happens even if I update through OTA.

Any help would be appreciated...thanks

Kyle Brock

unread,
Dec 21, 2011, 9:39:12 PM12/21/11
to android-...@googlegroups.com
I know it's not your job or your fault.  But, as an unsuspecting customer, I purchased the unlocked GSM galaxy nexus with the expectation that I would be getting updates from Google.  After doing lots of reading, it now seems that this has never necessarily been the case.

It just seems impossible to get confirmation (from Google or Samsung) as to whether it is safe or not to flash the yakju build onto a phone that is built with yakjuxw.

Which is what I find to be quite frustrating.  I just wish someone from either Google or Samsung would step up and tell us for sure.  As I would like my volume issue to actually be fixed.  I'm not opposed to flashing the phone, I just don't want a phone that is completely useless.

It's one thing to read that no one has had any serious issues doing so.  But, what about issues that they haven't noticed yet?  That's why I think a confirmation is so important.

Jean-Baptiste Queru

unread,
Dec 22, 2011, 11:11:13 AM12/22/11
to android-...@googlegroups.com
If Samsung gives me that information, I'll be sure to pass it around.

JBQ

Michał Banszel

unread,
Dec 24, 2011, 12:25:38 PM12/24/11
to android-...@googlegroups.com
Why does ton of smali files in factory images have invoke-direct/range {p0 .. p0}, instead of invoke-direct {p0}? When building from source all is fine, but all factory images have this "issue".

Merry Christmas JBQ!

2011/12/22 Jean-Baptiste Queru <j...@android.com>:

Jean-Baptiste Queru

unread,
Dec 27, 2011, 12:39:45 PM12/27/11
to android-...@googlegroups.com
You're probably comparing .dex files that are is userdebug builds with
.odex files that are in user builds built on linux. The dexopt build
step fine-tunes the bytecode.

That's just my guess, though, I'm not a DVM expert.

JBQ

Danilo Pardo

unread,
Mar 15, 2012, 4:13:10 PM3/15/12
to android-...@googlegroups.com
Hi there Jean,

I own a Galaxy Nexus (X as i'm from Brazil) and after applying this factory image, it just changed my baseband to XXKK6 and the one for my region is UIKL3.
is there any way to have it here so i can apply it back?

The XXKK6 seems to no work quite well in Brasil... i'm experiencing lots of signal drops.

Thanks in advance,

Danilo P.

Em quinta-feira, 1 de dezembro de 2011 17h48min32s UTC-2, Jean-Baptiste Queru escreveu:
We've just made the factory image for Galaxy Nexus GSM/HSPA+ available
for download at the following URI:

http://code.google.com/android/nexus/images.html

This file, once unarchived, contains the bootloader, baseband, and the
rest of the system.

You'll need to have fastboot in your path, and to have the device in
fastboot mode before you can use it (either "adb reboot bootloader",
or press-and-hold both volume-up and volume-down then press-and-hold
power).

For convenience, a flash-all.sh script is provided as well, which
restores the entire phone to its factory state.

If you're only flashing some of the images, I strongly recommend
flashing things in the same order as flash-all.sh. Specifically, flash
the bootloader before the radio, and reboot after flashing the
bootloader or the radio.

Don't forget that after flashing back to a factory state, your
bootloader is still unlocked. Don't forget to lock it back in order to
secure your device ("fastboot oem lock").

Hopefully this'll be useful to people flashing custom AOSP builds, as
it provides a clean supported way to return to factory state.

JBQ

Danilo Pardo

unread,
Mar 15, 2012, 4:52:35 PM3/15/12
to android-...@googlegroups.com
Thanks 4 the replay Jean.

That factory image only has the XXKK6 radio.img... the one i need is the UILK3.

Where can i get it?

Hope you can help.

Thanks

--

Danilo Pardo

unread,
Mar 16, 2012, 11:20:13 AM3/16/12
to android-...@googlegroups.com
Jean,

The correct name of the baseband i need is UIKL3.

Do you believe you can provide it?

Thanks
Thanks

To post to this group, send email to android-building@googlegroups.com

To unsubscribe from this group, send email to

Jean-Baptiste Queru

unread,
Mar 20, 2012, 2:29:42 PM3/20/12
to android-...@googlegroups.com
Unfortunately I only have the files related to the plain yakju devices
(which comes with the XX GSM firmware), which is why those are the
only devices that I can support in AOSP.

JBQ

>>> To post to this group, send email to android-...@googlegroups.com


>>> To unsubscribe from this group, send email to

>>> android-buildi...@googlegroups.com


>>> For more options, visit this group at
>>> http://groups.google.com/group/android-building?hl=en
>>
>>

> --
> You received this message because you are subscribed to the "Android
> Building" mailing list.

> To post to this group, send email to android-...@googlegroups.com


> To unsubscribe from this group, send email to

> android-buildi...@googlegroups.com


> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en

--

Michal

unread,
Mar 29, 2012, 8:13:39 AM3/29/12
to android-...@googlegroups.com
@JBQ

If 4.0.4 OTA is now rolling out and source is out as well, new factory images will be available soon?

Jean-Baptiste Queru

unread,
Mar 29, 2012, 3:02:32 PM3/29/12
to android-...@googlegroups.com
Yes, they'll be available, as soon as I find time for that between the
various last-minute emergencies.

JBQ

Michal

unread,
Mar 30, 2012, 1:39:01 AM3/30/12
to android-...@googlegroups.com
One question here regarding latest OTA and factory image.

OTA package contains following command for flashing bootloader: assert(samsung.write_bootloader(package_extract_file("bootloader.img"), "/dev/block/platform/omap/omap_hsmmc.0/by-name/xloader", "/dev/block/platform/omap/omap_hsmmc.0/by-name/sbl"));

For me that means that bootloader image is being flashed to at least to 2 different partitions -  xloader and  sbl.

In factory image we use fastboot flash bootloader bootloader.img method. Are those two method the same with the same result?

Thanks for the answer!

Reply all
Reply to author
Forward
0 new messages