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.
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
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
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
>
--
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
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
*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
JBQ
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
>
--
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>:
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
>
--
JBQ
Sorry if the question has an obvious answer, this is new to me.
JBQ
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
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?
JBQ
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
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
>
Don't know how it got messed up in the first place, thanks!
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
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
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
Thanks for your answer
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
>
2011/12/15 Jean-Baptiste Queru <j...@android.com>:
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
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
JBQ