Outstanding cupcake -> master merge

[Jean-Baptiste Queru]

[bcc android-platform, android-framework, android-porting]

I'm working on merging the latest cupcake code drop into master. The
task is quite hairy, so the following two guidelines probably apply:

-please don't submit anything in gerrit, as you'll just get in my way.
-now is a good time to repo sync master, as I'm going to have to
submit the result of the merge in a state where it doesn't build, and
I have no idea how long it'll take to get it to build again after
that.

Thanks,
JBQ

--
Jean-Baptiste M. "JBQ" Queru
Android Engineer, 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.

[Rajesh S]

That sounds great.. every minor change on cupcake has been breaking
the build. With your efforts to push it into master am sure things
would be sorted out.
Hope it would build for htc_dream. Currently extract_files.sh and the
corresponding make in both branches are incomplete from 'htc_dream'
point of view.

Thanks. And thanks .. repo synced master safely. Shall wait to hear
from you before syncing master again. Exciting.

[Jean-Baptiste Queru]

I expect to start submitting the changes in about an hour, i.e.
between 1:30pm and 2pm PDT.

Starting right now, you may want to avoid initiating a new repo sync,
unless you're OK ending up with a tree that might not even compile.

JBQ

[Jean-Baptiste Queru]

I've submitted the merge (106 projects!), and I believe that the tree
is in the state that it should be.

Caveats:

-THE BUILD IS BROKEN. You've been warned. There's been some drift
around OpenCORE (probably situations where new code was written in
cupcake that uses OpenCORE 1, or where APIs were removed in cupcake
that OpenCORE 2 relies on).

The proper command to try to merge the OpenCORE code should be "git
merge remotes/korg/cupcake" (I'm typing from memory).

-I'm not 100% sure that the server contains exactly what it should.
I've had a filesystem failure right as I was trying to verify it, and
I'm not gonna be able to verify until at least sometime tomorrow.

JBQ

[Jean-Baptiste Queru]

I've put together a hack that allows the system to compile and start
all the way to the home app. I worked with the delicateness of
open-heart surgery performed with a chainsaw.

Steps:

-remove the opencore files ( rm -rf external/opencore
.repo/projects/external/opencore.git ). Remove opencore from your
.repo/manifest.xml if you intend to repo sync the entire world but
don't want to have to remove opencore every single time.

-patch in change 9300 ( repo download platform/frameworks/base 9300/1 )

-most probably do a clean build ( rm -rf out/ ; make )

I've "tested" on a device/release/generic/userdebug build. On my
machine, it compiles, launches. The media process dies (which probably
means that downloads are busted too), as well as the music player. The
browser starts and can access the network.

JBQ

[Rajesh S]

Tried it out on emulator. Boots, throws a media force close error
while unlocking the screen.

Did u try on a real device? Could I expect it to work? Let me try
'building for dream' sequence with this tomorrow.

[Jean-Baptiste Queru]

I have it working on Dream (starting from ADP1 1.1) but I had to hack
through the dream and msm7k projects. I'll try to put patches up on
gerrit so that people can repo download them.

JBQ

[Rajesh S]

That would be very helpful JBQ and much appreciated (by many).
And for ADP1 firmware release, please ensure that we could rebuild but
for binaries to the same level from sources by repo syncing to a
particular change set / date.
Thanks and regards,
Rajesh.s

[Jean-Baptiste Queru]

All right, if you remove opencore and properly interleave changes
9300, 9307 and 9308 in the 'build for dream' sequence, I believe that
you end up with a build that boots, at least if you start from an ADP1
running 1.1. I did a device/release/dream/userdebug build.

In addition to everything that's broken on the emulator, wifi doesn't
work (but 3G data does). It can place phone calls but not receive
them. The orientation system is busted. Contacts crash. The SD card
doesn't seem to be recognized. I've had a few random restarts. But,
hey, it's the latest open-source tree running on real hardware :)

JBQ

[Rajesh S]

thats excellent for the single day you spent merging the branches!!
am baffled it boots! rest of my requests were for the time you
actually have a release for ADPs. But yes I would be very glad to have
the master branch working fully with more features on ADP even
earlier.

'Building for dream' sequence has this extract files (binaries) stuff.
But it doesn't really help bring the source build to the same level as
the release. If possible enhance that and the corresponding
Android*.mk to extract and push the closed apks (mail, maps, market,
youtube, ..) etc too from the released firmware if running on the
device.

Thanks a lot for all the stuff contributed.
Rajesh.S

[Jean-Baptiste Queru]

The apks in question are far more fragile than the low-level native
binaries, compatibility-wise, as they use plenty of non-SDK APIs, and
the 1.1 apks most probably aren't going to work on master.

If you could have a source tree that exactly matches a released
device, that'd be possible, though very fragile as there are still
plenty of things you couldn't change in the system (e.g. you couldn't
add or remove system resources).

Unless Google reverses its position on providing its applications for
open-source builds, we need to assume that master builds just won't
have access to Google's apps.

JBQ

[Rajesh S]

It could be as fragile as it could be but all am asking for is a
particular date or tag to repo sync to so that the firmware built out
of master is as close as possible to the release for ADP. Hopefully at
least in this case, the proprietary binaries (apks too) would be
compatible.

Even if the 1.1 or later APKs use non-SDK APIs, it must be possible to
patch (at least in some binary fashion) to use the extracted APKs
after building on master.
Else one of the critical purposes of the master branch as open source
for developers is defeated.
That would unfortunately motivate us to stick to the firmware from
Google and not use our own build for want of Google APKs on ADP1s.

[Jean-Baptiste Queru]

I don't expect master (which is bleeding edge by definition) to ever
become stable enough to have official releases cut out of it (ADP1 or
otherwise). Releases will come out of branches from master (or, much
more likely, 2 or 3 levels away). I'm hoping that the exact platform
source code that is used to build ADP1 releases and SDK releases can
be made available, but I can't quite promise it.

Your point remains, it'd be nice if Google could make their apps
available for the Android Open-Source Project. I've relayed that
request several times, so I know that the people who can make such a
decision know about it.

Personally, I'm more concerned about getting the code from the Android
Open-Source Project to reliably work on some flashable and commonly
available hardware.

JBQ

[Rajesh S]

Yes JBQ, it would be nice to have the level 2 or 3 branched platform
source not necessarily through git .. may be as a tarball with
proprietary stuff given as binaries only.

We won't even need the second option suggested by you. As long as we
can extract the binaries and APKs from a phone flashed with your
latest release and reuse with the specific branch/tarball, we are
fine. Let the close sourced stuff remain so, just help it work with
some open source build while releasing.

And am are very very glad about you helping the master branch work
with some hardware (ADP1 today). Thanks a lot.

Regards,
Rajesh.S

On Mar 20, 1:26 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I don't expect master (which is bleeding edge by definition) to ever
> become stable enough to have official releases cut out of it (ADP1 or
> otherwise). Releases will come out of branches from master (or, much
> more likely, 2 or 3 levels away). I'm hoping that the exact platform
> source code that is used to build ADP1 releases and SDK releases can
> be made available, but I can't quite promise it.
>
> Your point remains, it'd be nice if Google could make their apps
> available for the Android Open-Source Project. I've relayed that
> request several times, so I know that the people who can make such a
> decision know about it.
>
> Personally, I'm more concerned about getting the code from the Android
> Open-Source Project to reliably work on some flashable and commonly
> available hardware.
>
> JBQ
>

> ...
>
> read more »

[Jean-Baptiste Queru]

I really expect that future source drops would be done through git.
It's just much more efficient at several levels.

JBQ

[Rajesh S]

Thanks JBQ as long as firmware built from sources could accommodate
binary packages too. Thanks a lot for your time. I'll stop disturbing
on this, as you have very well acknowledged my request, so that you
could work and give us a good stable master branch for ADP1 ;-)

On Mar 20, 2:54 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I really expect that future source drops would be done through git.
> It's just much more efficient at several levels.
>
> JBQ
>

> >> >> >> >> >> >cupcakethat uses OpenCORE 1, or where APIs were removed incupcake

> >> >> >> >> >> > that OpenCORE 2 relies on).
>
> >> >> >> >> >> > The proper command to try to merge the OpenCORE code should be "git
> >> >> >> >> >> > merge remotes/korg/cupcake" (I'm typing from memory).
>
> >> >> >> >> >> > -I'm not 100% sure that the server contains exactly what it should.
> >> >> >> >> >> > I've had a filesystem failure right as I was trying to verify it, and
> >> >> >> >> >> > I'm not gonna be able to verify until at least sometime tomorrow.
>
> >> >> >> >> >> > JBQ
>
> >> >> >> >> >> > On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> >> >> >> I expect to start submitting the changes in about an hour, i.e.
> >> >> >> >> >> >> between 1:30pm and 2pm PDT.
>
> >> >> >> >> >> >> Starting right now, you may want to avoid initiating a new repo sync,
> >> >> >> >> >> >> unless you're OK ending up with a tree that might not even compile.
>
> >> >> >> >> >> >> JBQ
>
> >> >> >> >> >> >> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >> >> >> >> >> >>> [bcc android-platform, android-framework, android-porting]
>

> >> >> >> >> >> >>> I'm working on merging the latestcupcakecode drop into master. The

> >> >> >> >> >> >>> task is quite hairy, so the following two guidelines probably apply:
>
> >> >> >> >> >> >>> -please don't submit anything in gerrit, as you'll just get in my way.
> >> >> >> >> >> >>> -now is a good time to repo sync master, as I'm going to have to
> >> >> >> >> >> >>> submit the result of the merge in a state where it doesn't build, and
> >> >> >> >> >> >>> I have no idea how long it'll take to get it to build again after
> >> >> >> >> >> >>> that.
>
> >> >> >> >> >> >>> Thanks,
> >> >> >> >> >> >>> JBQ
>
> >> >> >> >> >> >>> --
> >> >> >> >> >> >>> Jean-Baptiste M. "JBQ" Queru
> >> >> >> >> >> >>> Android Engineer, 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.
>
> >> >> >> >> >> >> --
> >> >> >> >> >> >> Jean-Baptiste M. "JBQ" Queru
> >> >> >> >> >> >> Android Engineer, Google.
>
> >> >> >> >> >> >> Questions sent directly to me that have no reason for being private
> >> >> >> >> >> >> will likely get ignored or forwarded
>

> ...
>
> read more »

[Jean-Baptiste Queru]

I've put in a few fixes that should help run the master branch on ADP1
(makes it build without the need for 9307 and 9308, and adds wifi
support).

The need to remove opencore and patch in 9300 is still there, though.
I was hoping for a better solution before the week-end, but somehow
trying to replicate 9300 "cleanly" didn't quite work and I can't spot
the difference.

JBQ

[Rajesh S]

Hi JBQ,
Thanks for the merged code.. many things work. But there are a few
bugs.. some that have always been there on master.
Not worth mentioning as bugs since this is in between a merge.
But just in case if it is going to help, here are some observations:
- wifi, soft-keyboard, transitions, spare parts, ... work well.
- as expected media error reports for all triggers (start-up, volume,
music app, ...)
- not sure if i have the wrong version of radio but even on
completion of a sms sequence, i get to see the flashing android
logo .. probably the init process restarts, and gets back to home
screen within a 10 seconds.
- camera crashes on app start.. (libOmxCore...?)
- home button has no effect
- messaging/browser app orientation gets stuck when hardware keyboard
is shut and soft-keyboard is used.

- and of course none of the proprietary apps work if pushed in
through system.img

Regards,
Rajesh.S

On Mar 21, 2:59 am, Jean-Baptiste Queru <j...@android.com> wrote:
> I've put in a few fixes that should help run the master branch on ADP1
> (makes it build without the need for 9307 and 9308, and adds wifi
> support).
>
> The need to remove opencore and patch in 9300 is still there, though.
> I was hoping for a better solution before the week-end, but somehow
> trying to replicate 9300 "cleanly" didn't quite work and I can't spot
> the difference.
>
> JBQ
>
>
>
> On Thu, Mar 19, 2009 at 4:54 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > All right, if you remove opencore and properly interleave changes
> > 9300, 9307 and 9308 in the 'build for dream' sequence, I believe that
> > you end up with a build that boots, at least if you start from an ADP1
> > running 1.1. I did a device/release/dream/userdebug build.
>
> > In addition to everything that's broken on the emulator, wifi doesn't
> > work (but 3G data does). It can place phone calls but not receive
> > them. The orientation system is busted. Contacts crash. The SD card
> > doesn't seem to be recognized. I've had a few random restarts. But,
> > hey, it's the latest open-source tree running on real hardware :)
>
> > JBQ
>

[Jean-Baptiste Queru]

Thanks for the feedback. Yes, that matches my observations.

JBQ

[Jean-Baptiste Queru]

I've been working on a "better" batch of patches (now it feels more
like open-heart surgery with a meat cleaver):

-no need to delete the opencore directory or to remove it from the manifest.

-you need to repo download changes 9355, 9356 and 9357. No need to
take 9300. I know it's 3 changes instead of 1, because I had to touch
a few more parts of the system, but those are much cleaner.

-only tested on the emulator, so those might very well cause
regressions on dream.

JBQ

[André Oriani]

Hi JBQ,

I would suggest to apply a tag so we can know what is the last stable
piece of code on master branch before doing a repo sync and getting a
broken build. That would certainly help.

Thanks,
André Oriani

[Rajesh S]

JBQ does this 'repo' script have support for tagging at all?
I could not find much in the docs.. am I missing it?

And I'll try the 3 instead of 9300 on the device.

Regards,
Rajesh.S

[Jean-Baptiste Queru]

Well, repo could be used to do a repo forall -c git checkout <tag>,
but that'd require to tag every single project, which would really
only be practical for admins. On top of that I believe that we only
want to tag actual long-term releases, and whatever state master was
on before the merge last Wednesday wasn't a release.

The real process would have been to do a "repo manifest -r -o -" in a
synced tree before the merge, and post this manifest here on the
group. This can still be done today by someone who has a synced tree
in the state as of Wednesday noon PDT. I don't have such a tree, and
my top priority at this point is to help people move ahead, not to
help them stay behind.

The breakage wasn't supposed to last that long. I expected a day at
most, and it's been 3 days already. I'm really sorry about that. I've
been trying to fix things, but it turned out to be much harder than I
had anticipated, at several different levels.

If you'd like to help, my current sticky point is to find out why my
LOCAL_CFLAGS in
https://review.source.android.com/Gerrit#patch,sidebyside,9356,1,media/libmediaplayerservice/Android.mk
doesn't seem to get passed to the compiler, so that I've had to
temporarily use #if 0 instead of #ifndef opencore in the source tree.
We'll also need a better fix for 9357, as I guess it should be
possible to prevent that crash without having to modify the phone app.

JBQ

[Rajesh S]

is it because you have defined
BUILD_WITHOUT_PV := true
and you are checking for negative

ifneq ($(BUILD_WITHOUT_PV),true)
LOCAL_CFLAGS := -DNO_OPENCORE
endif

were you actually wishing for 'ifeq' instead?

Regards,
Rajesh.S

On Mar 22, 12:15 am, Jean-Baptiste Queru <j...@android.com> wrote:
> Well, repo could be used to do a repo forall -c git checkout <tag>,
> but that'd require to tag every single project, which would really
> only be practical for admins. On top of that I believe that we only
> want to tag actual long-term releases, and whatever state master was
> on before the merge last Wednesday wasn't a release.
>
> The real process would have been to do a "repo manifest -r -o -" in a
> synced tree before the merge, and post this manifest here on the
> group. This can still be done today by someone who has a synced tree
> in the state as of Wednesday noon PDT. I don't have such a tree, and
> my top priority at this point is to help people move ahead, not to
> help them stay behind.
>
> The breakage wasn't supposed to last that long. I expected a day at
> most, and it's been 3 days already. I'm really sorry about that. I've
> been trying to fix things, but it turned out to be much harder than I
> had anticipated, at several different levels.
>
> If you'd like to help, my current sticky point is to find out why my

> LOCAL_CFLAGS inhttps://review.source.android.com/Gerrit#patch,sidebyside,9356,1,medi...

[Jean-Baptiste Queru]

*facepalm*

Doh. Doh. Doh. Doh.

JBQ

[Rajesh S]

Not worth a *facepalm*. We understand how much volume you are dealing
with. Well.. you deserve a weekend break :-).
I have a master repo synced of Wednesday (that you pointed at).. but
haven't got a public server to host it. Is there someway it could be
made useful?

Regards,
Rajesh.S

[Jean-Baptiste Queru]

If you could run "repo manifest -r -o -" on your pre-merge master and
just copy-paste the output in a new thread here, that'd be great.

JBQ

[Rajesh S]

Thanks, I wasn't aware of that manifest extract syntax.
Posted it through
http://groups.google.com/group/android-platform/browse_thread/thread/9c3b92928d13bfdb

Regards,
Rajesh.S

[Jean-Baptiste Queru]

[still bcc android-platform, android-framework, android-porting]

Latest status:

-we're back to one patch: 9356.

-build with "BUILD_WITHOUT_PV=true make"

-quickly tested both on emulator and dream, and seems to work well
enough to not have the phone app crash in a loop.

-I expect to submit 9356 on Monday morning PDT.

JBQ

[michael m.]

thanks for your patch! i'm really new to this git stuff so whats the
command for downloading this patch? repo always wants to have some
project with the download command...

[Jean-Baptiste Queru]

The proper command is repo download platform/frameworks/base 9356/4

(you can get it from http://r.android.com/9356 where there's even a
magic "copy" button for it)

JBQ

[Vladimir]

Try this:
repo download platform/frameworks/base 9356/4

It can be found here:
https://review.source.android.com/Gerrit#change,9356

[Jean-Baptiste Queru]

9355 and 9357 aren't needed any more.

You need to get 9356 and compile with "BUILD_WITHOUT_PV=true make"

JBQ

On Mon, Mar 23, 2009 at 6:27 AM, Breno <breno....@gmail.com> wrote:
>
> Hey JBQ,
>
> I can't find the changes 9355 and 9357. I download the change 9356
> patch 4, and still now compiling. Where can i find this others patch?
>
> Thanks a lot
>
> Breno

>> >> >>brokenbuild. That would certainly help.

>> >> >> > >> -THE BUILD ISBROKEN. You've been warned. There's been some drift

>> >> >> > >> around OpenCORE (probably situations where new code was written in

>> >> >> > >>cupcakethat uses OpenCORE 1, or where APIs were removed incupcake

>> >> >> > >> that OpenCORE 2 relies on).
>>
>> >> >> > >> The proper command to try to merge the OpenCORE code should be "git
>> >> >> > >> merge remotes/korg/cupcake" (I'm typing from memory).
>>
>> >> >> > >> -I'm not 100% sure that the server contains exactly what it should.
>> >> >> > >> I've had a filesystem failure right as I was trying to verify it, and
>> >> >> > >> I'm not gonna be able to verify until at least sometime tomorrow.
>>
>> >> >> > >> JBQ
>>
>> >> >> > >> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> >> > >>> I expect to start submitting the changes in about an hour, i.e.
>> >> >> > >>> between 1:30pm and 2pm PDT.
>>
>> >> >> > >>> Starting right now, you may want to avoid initiating a new repo sync,
>> >> >> > >>> unless you're OK ending up with a tree that might not even compile.
>>
>> >> >> > >>> JBQ
>>
>> >> >> > >>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>> >> >> > >>>> [bcc android-platform, android-framework, android-porting]
>>

>> >> >> > >>>> I'm working on merging the latestcupcakecode drop into master. The

[Scott Tsai]

Since 9356 was recently merged, I repo sync'ed and can verify that
"BUILD_WITHOUT_PV=true make" gives me a successful build.

Now if only some kind soul would help me get these gcc-4.4 build
patches reviewed:
https://review.source.android.com/9326
https://review.source.android.com/9327
https://review.source.android.com/9329
I'll be a happy man ;)

[Jean-Baptiste Queru]

I'll have a look at those.

JBQ

[Brad Larson]

Hey JBQ,

Sorry if this has been addressed elsewhere... should we expect better
list scrolling performance on the G1 compared to the cupcake build?
Lists seem to scroll much smoother on the G1. Is this due to GL or is
there some other factor?

Thanks!
-Brad

[Jean-Baptiste Queru]

There seem to be some issues with the open-source master tree that
make it slower than it should be. I don't know what the root cause is.

JBQ

[Jean-Baptiste Queru]

Done, thanks for the contributions :)

JBQ

[Scott Tsai]

Thanks for the reviews! :)
With 9326, 9327 and 9329 merged, I could complete a:
TARGET_ARCH:=x86
TARGET_PRODUCT:=eee_701
build on my Fedora 11 machine.

I got encouraged and tried a build with:
TARGET_ARCH:=x86
TARGET_PRODUCT:=sim
and produced a couple more gcc-4.4 build patches:
https://review.source.android.com/9368
https://review.source.android.com/9369
before bump into this "interesting" problem:

The Android prebuilt toolchains don't have STL as part of libstdc++
but Webkit needs it so a partial copy of the header files is included
under "external/webkit/WebKit/android/stl". When doing a simulator
build with the gcc-4.4 toolchain that comes with Fedora this then
fails with
In file included from external/webkit/WebCore/WebCorePrefixAndroid.h:
54,
from <command-line>:2:
external/webkit/WebKit/android/stl/algorithm:79: error: redefinition
of ‘template<class _Tp> void std::swap(_Tp&, _Tp&)’
/usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../../../include/c++/4.4.0/
bits/move.h:81: error: ‘template<class _Tp> void std::swap(_Tp&,
_Tp&)’ previously declared here

( .. >_<... paragraphs below are going to read like a rant ...)

.... So the next time an engineer working on the android code base
wants to integrate a third party C++ library that needs STL they'll
include another copy and when porting Android to another embedded
Linux platform which already comes with a toolchain I'll need to build
a bionic toolchain first which increases the difficulty of porting to
non-Arm and x86 platforms substantially.

I sure hope the benefits of using bionic are worth all the extra
effort it causes ;)

On Mar 24, 6:28 am, Jean-Baptiste Queru <j...@android.com> wrote:
> Done, thanks for the contributions :)
>
> JBQ
>
>
>
> On Mon, Mar 23, 2009 at 2:04 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > I'll have a look at those.
>
> > JBQ
>

[Jean-Baptiste Queru]

[still bcc android-platform, android-framework, android-porting]

We're now one step closer. Change 9356 was submitted, so that the
source tree "as is" can be compiled.

You still need to set BUILD_WITHOUT_PV=true.

JBQ

[Rajesh S]

Thanks JBQ & Scott, am trying it out but what could be expected 'not
to work' on this branch? Would like to see if the expected to work
components are fine enough.

And could you give a rough idea of the differences between this branch
and a typical release. There are some apparent ones. Some aren't. Like
somebody had a good point about not so smooth scrolling on this
branch. Anyway it would be very useful to see even the obvious list of
differences from somebody in the Android team.

Thanks,
Rajesh.S

> >>>>cupcakethat uses OpenCORE 1, or where APIs were removed incupcake

> >>>> that OpenCORE 2 relies on).
>
> >>>> The proper command to try to merge the OpenCORE code should be "git
> >>>> merge remotes/korg/cupcake" (I'm typing from memory).
>
> >>>> -I'm not 100% sure that the server contains exactly what it should.
> >>>> I've had a filesystem failure right as I was trying to verify it, and
> >>>> I'm not gonna be able to verify until at least sometime tomorrow.
>
> >>>> JBQ
>
> >>>> On Wed, Mar 18, 2009 at 12:43 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>>>> I expect to start submitting the changes in about an hour, i.e.
> >>>>> between 1:30pm and 2pm PDT.
>
> >>>>> Starting right now, you may want to avoid initiating a new repo sync,
> >>>>> unless you're OK ending up with a tree that might not even compile.
>
> >>>>> JBQ
>
> >>>>> On Tue, Mar 17, 2009 at 6:35 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> >>>>>> [bcc android-platform, android-framework, android-porting]
>

> >>>>>> I'm working on merging the latestcupcakecode drop into master. The

[好 祝]

[Jean-Baptiste Queru]

The master branch is definitely not a release. It's the mainline, the
trunk, the unstable. As such, almost by definition, it has issues
(and, in this case, very major issues).

At this point, nobody on the Android team has any visibility over its
exact state beyond what can be seen in a few minutes (media is busted,
orientation doesn't switch properly, several apps crash at launch, the
runtime crashes frequently...).

Cupcake is probably a lot more stable, though even in that case we
have little visibility over the exact state of the open-source tree.

JBQ

[Johan de Koning]

But am I right that the cupcake branch cannot be deployed on a real
device?

Yesterday I build the master branch and flashed my ADP1 with it but it
does not boot. One time it booted but then i got errors of the
com.android.phone process. I am interested in the on screen keyboard
and was also looking at the widget framework for the home screen.

[Jean-Baptiste Queru]

Cupcake can be deployed on devices (as a general statement) though
it's not production-quality yet. However, at the moment, the matching
proprietary files necessary to make it run "as is" on dream aren't
available (and we believe that the versions of those files that can be
extracted from a 1.1 phone are unlikely to be compatible - I haven't
had time to try that myself, though).

JBQ

[Rajesh S]

Even on master you can test out the soft keyboard etc merged from
cupcake before this month.
That used to be pretty stable in comparison to the current shape.
You may need this:
http://groups.google.com/group/android-platform/browse_thread/thread/9c3b92928d13bfdb

[Jean-Baptiste Queru]

[still bcc android-platform, android-framework, android-porting]

Final status on this:

-BUILD_WITHOUT_PV=true is now the default in master, so that a plain
"make" should work again. This is still only a temporary hack and
we'll have to fix this the right way in the future, but it'll let
people build "out of the box".

-Sorry for the delay in getting this done. Everything has been hectic.

JBQ

[Mikael Bourges-Sevenier]

Will this code work on G1 yet?

Mike

[Jean-Baptiste Queru]

I haven't tested it on Dream after last Friday's code drop. It did
work after the drop from the previous week.

JBQ