Android 2.3.5 is available
Jean-Baptiste Queru
The manifest is android-2.3.5_r1, the build number is GRJ90. It is
also merged into the master branch.
Updated proprietary binaries are available at
http://code.google.com/android/nexus/drivers.html
Worth mentioning:
-It might be possible to experimentally build 2.3.5 on 32-bit systems.
-Crespo4g (Nexus S 4G hardware) is supported directly in the tagged release.
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.
Linux Box Solutions
www.LinuxBoxSolution.com
www.YouTube.com/user/linuxboxsolution
www.Krzyview.com
www.Email-Marketers.com
> --
> 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
repo forall -p -c 'if git rev-parse android-2.3.4_r1 > /dev/null 2>&1
; then git log --no-merges android-2.3.4_r1..android-2.3.5_r1 ; else
git log --no-merges android-2.3.5_r1 ; fi'
(To be run as a single line).
I don't know the details off-hand other than what I mentioned earlier.
JBQ
Linux Box Solutions
Linux Box Solutions
www.LinuxBoxSolution.com
www.YouTube.com/user/linuxboxsolution
www.Krzyview.com
www.Email-Marketers.com
On Jul 31, 2011, at 12:09 AM, Jean-Baptiste Queru <j...@android.com> wrote:
Yuanjie
on the page. It seems akm and cypress are missing, and therefore
libakm.so and cypress-touchkey.bin are not included. Is it due to some
policy or just a mistake?
Yuanjie
On Jul 31, 3:39 am, Jean-Baptiste Queru <j...@android.com> wrote:
> Android2.3.5has been released into the Android Open-Source Project.
> also merged into the master branch.
>
>
> Worth mentioning:
> -It might be possible to experimentally build2.3.5on 32-bit systems.
Samuel B. Quiring
I've been building the Gingerbread 2.3.5 successfully for
a Nexus-S (thanks). I wanted to test my changes on a Nexus-One,
so I added a vendor/htc/... area to my build area then
switched to the Nexus-One by doing this:
$ lunch full_passion-userdebug
$ make -j2
The result booted on the Nexus-One and a lot of stuff worked,
but the wi-fi drivers can't be loaded and HierarchyViewer
cannot start ViewServer (I've never seen this before).
In the past, I've always maintained totally separate build
areas for separate targets. This time I decided to try and
share.
Question 1: when you use a build area for multiple targets,
do you have to do more than "lunch" when you switch to a
new target? E.g., "make clean"?
Question 2: What do you recommend? Is it easier to maintain
separate build areas or easier to share? If you are changing
the source in one build area, then to test the other you have
to copy your changes over. That's kind of a pain.
Thanks.
-Sam
PS: bonus question. I downloaded the 2.3.4 Nexus-One image
from HTC, flashed it onto the Nexus-One, and extracted the
drivers from it to build the 2.3.5 Nexus-One image described
above. Are the 2.3.4 drivers compatible with 2.3.5?
Magnus Bäck
"Samuel B. Quiring" <s...@sbqsam.com> wrote:
[...]
> Question 1: when you use a build area for multiple targets,
> do you have to do more than "lunch" when you switch to a
> new target? E.g., "make clean"?
No, the build system will deal with this. Different products have
different build output directories for stuff that can be different
(out/target/product/<productname>) while stuff that's shared between
products, like Java .class files, is placed in out/target/common.
However, if switch between different variants (userdebug and eng,
for example) of the same product, some parts will be rebuilt.
> Question 2: What do you recommend? Is it easier to maintain
> separate build areas or easier to share? If you are changing
> the source in one build area, then to test the other you have
> to copy your changes over. That's kind of a pain.
Yes. I recommend sharing, unless you switch between variants and
want to avoid paying that price too often.
--
Magnus B�ck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson