branches again 1.5 now

[Rajesh S]

Hi,
Now that android-1.5 branch is available on the repo, could somebody
tell us what the branches mean at this stage?

How suitable is android-1.5 branch for the device (dream)?
Like how far is 1.5 merged into master?
What about cupcake and donut?

And could you please ensure a open-source branch almost in sync with
your official release of 1.5 sans the binaries and close sourced
stuff? Something that could compile to the same level as the release
for dream?

Sorry for repeating the last request.

Thanks in advance,
Rajesh.S

[Rajesh S]

Just downloaded android-1.5 with the "-b" on init. But seemingly it is
a tag and not exactly a branch? Is that a tag on a open branch (like
master)?

[Jean-Baptiste Queru]

At the moment repo doesn't support tagged manifests, so we had to
create a branch in the manifest repository to be able to make 1.5
available with repo -b.

Here's the current situation:

-in each "code" repository:
*release-1.0 is the branch for 1.0 as it was originally released. It
should be considered read-only (i.e. we don't normally accept
submissions into it).
*cdma-import is the branch that was used by Teleca (a member of OHA)
to work on CDMA support in Android. read-only.
*cupcake is the branch that follows the cupcake source tree that
exists inside Google. it's read-only.
*donut is the branch for the first named project after cupcake.It's
still in the process of being set up. At the moment it's still
identical to cupcake. We might accept limited contributions into it at
some point in the future (as we transition away from the model that we
used for cupcake).
*master is the branch for all projects after donut. We accept
contributions into it.

*android-1.0 tags the original 1.0 code drop.
*android-sdk-1.5-pre tags the 1.5 preview SDK. It's the open-source
part of the exact source that was used to build the SDK, so it can be
used e.g. to match stack traces.
*android-1.5 tags the official 1.5 release of the Android Open-Source
Project. It's the one that should be used by people porting Android
1.5 to devices.

-within the "manifest" repository:
*there are the same branches as in the "code" repositories, which
point to the matching branches in all the code repositories.
*there are branches for android-1.5 and android-sdk-1.5-pre, which
point to the matching tags in all the code repositories (those have to
be branches as an artifact of the way repo currently works).

*there are the same tags as in the "code" repositories.

In summary, for practical purposes:
-globally:
*use repo init -b {release-1.0,cupcake,donut,master} to track the
state of those projects (though obviously release-1.0 and cupcake
aren't going to see much more action at this point).
*use repo init -b {android-sdk-1.5-pre,android-1.5} to get the frozen
state of those releases.

-locally in a "code" repository:
*the korg/{release-1.0,cupcake,donut,master} remotes branches point to
the matching upstream branches.
*the {android-sdk-1.5-pre,android-1.5} tags point to those specific releases.

I hope that makes sense.

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]

Thanks a lot JBQ for a very useful explanation.
But one question still lingers. Is any branch other than 'master'
ready for 'dream'?
'Building for dream' provides a sequence but I fear it won't work with
1.5 as that might need a newer kernel even on the device.
Master still seems to lag behind 1.5 . Would 1.5 get into master in
near future?

And would we be able to build android-1.5 for producing a dream-
firmware sans the proprietary stuff to match the upcoming release?

Thanks and regards,
Rajesh.S

[Jean-Baptiste Queru]

At this point the "building for dream" instructions have fallen a fair
bit behind. They used to apply to 1.0, but were semi-maintained
halfway between 1.0 and 1.5, and as a result don't really apply to
any.

Once the 1.5 dust settles, it'll hopefully be possible to put
instructions back together that apply to it and produce a working
result.

JBQ

[Rajesh S]

JBQ, 'building for dream' sequence still happens to produce working
firmware out of master branch for ADP1.. but that branch is too
volatile.
Something for release-1.5 (android-1.5) and updates for subsequent
releases would be very helpful.

Without that, a development phone (ADP1 from google) and open source
ideology gets a mild set back.

While others porting to other hardware would have to take care of it
for themselves, google might have to do more justice for 'dream'
platform.
JBQ, especially since that is the hardware development platform for
you all too inside google, I tend to believe that the open source part
of the sequence is just sharing-effort away and won't cost much of
development-effort.

Yes it of course needs to be isolated from proprietary stuff and
tested to some extent. But .. well.. please provide it soon :)...
that's the only request.
Thanks,
Rajesh.S

[Jean-Baptiste Queru]

Yes, the ADP1 situation is currently unfortunate. We've had to pick
priorities, the priority went to open-sourcing code out of Google, as
that's something that only Googlers can do.

The truth is, ADP1 isn't a phone from Google. While Google has some
influence on it (and provides a number of proprietary apps), It's
neither manufactured nor distributed by Google, and that puts limits
on the ways Google can support it (and espcially on how Google can not
redistribute some of the ADP1-specific files).

We've already shared everything that's not proprietary. All the
missing files fall in the "proprietary" category, and that's why we
have to deal with extract_files.sh and the associated ugliness. None
of the issues are technical: getting fired and then sued by both
Google and the owners of the files in question is indeed just one
sharing-effort away.

If we had been able to share those files, we'd have done so back in
December when ADP1 first shipped.

JBQ

[Chih-Wei]

Thank you for the detailed explanations.
I really hope such information can be put to the webpage or faq
to help beginners like me.

I still have one question.
As a developer, what is the branch should I follow?
What's your suggestion?

Basically I think I should follow the master branch, like other OSS
projects.
However, it seems to me the master branch is so unstable.
I always struggle with it during these two weeks of trying.
For example, the external/qemu just failed to compile:

external/qemu/sockets.c: In function 'sock_address_init_resolve':
external/qemu/sockets.c:637: error: 'EAI_NODATA' undeclared (first use
in this function)
external/qemu/sockets.c:637: error: (Each undeclared identifier is
reported only once
external/qemu/sockets.c:637: error: for each function it appears in.)
make: *** [out/host/linux-x86/obj/EXECUTABLES/emulator_intermediates/
sockets.o] Error 1

After a survey, I believe it is broken by the merge

commit 377da6eeb05aed6b54935b7a45b5426077762121
Merge: ce69b78... ecd65c2...
Author: The Android Open Source Project <initial-
contri...@android.com>
Date: Fri Apr 24 13:54:57 2009 -0700

Merge commit 'korg/donut'

Just curious. If you said donut is almost identical to cupcake at this
moment,
why we have merges from donut?

[Jean-Baptiste Queru]

If the change that broke the build for you in master was merged from
donut (and in turn from cupcake), you can assume that it's broken
identically in cupcake and donut.

As far as I can tell it's working fine on our machines, and since the
error is in a file that's compile in th host environment, I have to
assume that the breakage is related to the specific environment that
you're trying to compile under.

Which branch you want to follow depends very much on what you intend to do.

If you want to contribute to Android, master will give you to least
restrictive environment, at the cost of a longer lead time to see your
changes on consumer devices. Working in donut would allow your changes
to ship earlier, at the cost of seeing more restrictions.

If you're working toward integrating Android on a phone, you probably
want to stick with the latest tagged release (i.e. android-1.5 at
this point) if it has all the features you need, or the earliest named
branch that has the features you need.

If you're an application developer trying to get a "feel" for what
future versions of Android will look like, each version might make
sense depending on your goals.

JBQ

2009/4/26 Chih-Wei <cwh...@linux.org.tw>:

[Rajesh S]

Agree with you JBQ. Though ADP1 is distributed by brightstar, google
market provides a link from within to buy it. A little more
coordination with HTC could possibly help.

[joel]

JBQ, thanks for the info on the various branches. I think I understand
from your summary that the 'cupcake' and 'master' branches are
currently the best ones for building for ADP1, with 'cupcake' being
stable? And I guess 'android-1.5' doesn't have working build
instructions for ADP1? I am focused on what is supported for the ADP1.

The proprietary module issue is not a concern for me at this point.

Thanks,
Joel

[Jean-Baptiste Queru]

Things are changing very rapidly those days, and we haven't had time
to work (yet) on setting up the tools to be able to run the "building
for dream" instructions on 1.5. That's high on my priority list.

JBQ

[Rajesh S]

Thanks JBQ thats all I was asking for .. not the binaries..
that is available from htc for 1.5 (of course with help from you /
your team)
http://www.htc.com/www/support/android/adp.html
Now the building for dream sequence suitable for 1.5 would shut me up.
No urgency though!

[joel]

Thanks yes I got that, but since 1.5 is not an option then what other
branch(es) would you recommend to build & deploy on ADP1 today?

[Jean-Baptiste Queru]

Right now I don't think I can recommend any. I'll be focusing my
efforts on android-1.5, but at the moment it's not building.

JBQ

[Jean-Baptiste Queru]

I've put in a few fixes (mostly, the issue is that the cupcake branch
in vendor/htc/dream was grossly outdated). the build-for-dream
instructions should now work for both cupcake and android-1.5.

Unfortunately the result is still quite far off, and the open-source
build is currently missing ~100 files that exist in the ADP1. build.
I'm trying to figure that out.

JBQ

[SPD]

JBQ-

As I'm seeing this error as well (and I have absolutely no connection
to the below person) I have to suspect a few things.

1) That Google is not using the same distribution of Ubuntu as the
rest of us and
2) That Google is not publishing the precise specs for the build
environment.

I know there may be lots of reasons for this... but I would have to
believe it would be a good thing to get in the habit of publishing
these specs right along side the latest release.

For example, I would believe that having a specific set of notes that
details precisely what JDK, RUBY, and other versions of build
dependencies in a specific place, might be good for the people you are
working with...

What do you think?

Certainly I understand that the "latest" code isn't for general
consumption... in which case do you think it would be a good idea to
publish notes about what release is for general consumption? Or setup
standards, revision names, etc?

It is quite likely I'm just ignorant in these areas... so please feel
free to clue me in where I might be off-base above...


All the Best,
SPD

On Apr 27, 8:03 am, Jean-Baptiste Queru <j...@android.com> wrote:
> If the change that broke the build for you in master was merged from
> donut (and in turn from cupcake), you can assume that it's broken
> identically in cupcake and donut.
>
> As far as I can tell it's working fine on our machines, and since the
> error is in a file that's compile in th host environment, I have to
> assume that the breakage is related to the specific environment that
> you're trying to compile under.
>
> Which branch you want to follow depends very much on what you intend to do.
>
> If you want to contribute to Android, master will give you to least
> restrictive environment, at the cost of a longer lead time to see your
> changes on consumer devices. Working in donut would allow your changes
> to ship earlier, at the cost of seeing more restrictions.
>
> If you're working toward integrating Android on a phone, you probably
> want to stick with the latest tagged release (i.e. android-1.5 at
> this point) if it has all the features you need, or the earliest named
> branch that has the features you need.
>
> If you're an application developer trying to get a "feel" for what
> future versions of Android will look like, each version might make
> sense depending on your goals.
>
> JBQ
>

> 2009/4/26 Chih-Wei <cwhu...@linux.org.tw>:

>
>
>
> > Thank you for the detailed explanations.
> > I really hope such information can be put to the webpage or faq
> > to help beginners like me.
>
> > I still have one question.
> > As a developer, what is the branch should I follow?
> > What's your suggestion?
>
> > Basically I think I should follow the master branch, like other OSS
> > projects.
> > However, it seems to me the master branch is so unstable.
> > I always struggle with it during these two weeks of trying.
> > For example, the external/qemu just failed to compile:
>
> > external/qemu/sockets.c: In function 'sock_address_init_resolve':
> > external/qemu/sockets.c:637: error: 'EAI_NODATA' undeclared (first use
> > in this function)
> > external/qemu/sockets.c:637: error: (Each undeclared identifier is
> > reported only once
> > external/qemu/sockets.c:637: error: for each function it appears in.)
> > make: *** [out/host/linux-x86/obj/EXECUTABLES/emulator_intermediates/
> > sockets.o] Error 1
>
> > After a survey, I believe it is broken by the merge
>
> > commit 377da6eeb05aed6b54935b7a45b5426077762121
> > Merge: ce69b78... ecd65c2...
> > Author: The Android Open Source Project <initial-

> > contribut...@android.com>

[SPD]

Well, just to get the code to compile (even the android-1.5 version
has this issue) I commented out the EAI_NODATA field from the source
code. The rest of the build is blazing along. It looks like someone
tweaked the source but forgot to include a header file.

There is definitely no reason in my mind to suspect that this is build
environment related. This is likely a configuration management issue.

All the Best,
SPD.

On Apr 27, 8:03 am, Jean-Baptiste Queru <j...@android.com> wrote:

> If the change that broke the build for you in master was merged from
> donut (and in turn from cupcake), you can assume that it's broken
> identically in cupcake and donut.
>
> As far as I can tell it's working fine on our machines, and since the
> error is in a file that's compile in th host environment, I have to
> assume that the breakage is related to the specific environment that
> you're trying to compile under.
>
> Which branch you want to follow depends very much on what you intend to do.
>
> If you want to contribute to Android, master will give you to least
> restrictive environment, at the cost of a longer lead time to see your
> changes on consumer devices. Working in donut would allow your changes
> to ship earlier, at the cost of seeing more restrictions.
>
> If you're working toward integrating Android on a phone, you probably
> want to stick with the latest tagged release (i.e. android-1.5 at
> this point) if it has all the features you need, or the earliest named
> branch that has the features you need.
>
> If you're an application developer trying to get a "feel" for what
> future versions of Android will look like, each version might make
> sense depending on your goals.
>
> JBQ
>

> 2009/4/26 Chih-Wei <cwhu...@linux.org.tw>:

>
>
>
> > Thank you for the detailed explanations.
> > I really hope such information can be put to the webpage or faq
> > to help beginners like me.
>
> > I still have one question.
> > As a developer, what is the branch should I follow?
> > What's your suggestion?
>
> > Basically I think I should follow the master branch, like other OSS
> > projects.
> > However, it seems to me the master branch is so unstable.
> > I always struggle with it during these two weeks of trying.
> > For example, the external/qemu just failed to compile:
>
> > external/qemu/sockets.c: In function 'sock_address_init_resolve':
> > external/qemu/sockets.c:637: error: 'EAI_NODATA' undeclared (first use
> > in this function)
> > external/qemu/sockets.c:637: error: (Each undeclared identifier is
> > reported only once
> > external/qemu/sockets.c:637: error: for each function it appears in.)
> > make: *** [out/host/linux-x86/obj/EXECUTABLES/emulator_intermediates/
> > sockets.o] Error 1
>
> > After a survey, I believe it is broken by the merge
>
> > commit 377da6eeb05aed6b54935b7a45b5426077762121
> > Merge: ce69b78... ecd65c2...
> > Author: The Android Open Source Project <initial-

> > contribut...@android.com>

[Jean-Baptiste Queru]

We're primarily using MacOS 10.4 and 10.5 as well as Ubuntu 8.04. The
build works for us. We don't know what's different between our
environments and those where the build doesn't work.

We're not in a position to be able to know exact specs for the build
environment, especially as the availability of specific components
comes and goes, and some of those components can't be redistributed or
downgraded back to known versions.

I understand that there's a wiki being put together somewhere, this is
exactly the kind of information that can be efficiently gathered and
maintained by the community much more than by a single entity that
works in fairly uniform environments.

JBQ

2009/4/27 SPD <sdick...@gmail.com>:

[Chih-Wei]

Hello JBQ, thank you for the explanation.

My primary goal is to port android to other platform
like x86 and embedded devices.
What branch do you suggest me to use?

I'm just trying to checkout android-1.5 tag.
By the way, is there any way to quickly switch between branches or
tags?
As you said before, it seems I have to repo init -b for each branch or
tag I'm interesting.
I'm not a git expert. But from my limited knowledge,
all the branches should already exist in my local git repository
and I can switch between them on-fly, even without internet
connectivity.
Am I right?
However, I don't see how to do that for the android tree.
'repo checkout' seems doesn't work.

[Jean-Baptiste Queru]

Well, the key question here is about the screen characteristics.
Android-1.5 only supports HVGA screens with a size around 3" to 3.5" -
if your target screen matches that, android-1.5 is a good bet,
otherwise you'll have to go for something newer - future versions are
planned to support different pixel counts on the same screen size.

Within an individual project, it is possible to switch between
branches and/or tags. The challenge is that at the scale of Android,
the list of projects varies from one manifest to another, so the
switch isn't such a simple operation (and the tool that we use, repo,
doesn't fully support such a switch at this point).

JBQ

[Chih-Wei]

Thank you again, JBQ.

A more question.
What is the branch that most core developers actively work on now?
Does the main development move from cupcake to donut?

[Rajesh S]

JBQ, Thanks a bunch for the update.
Regards,
Rajesh.S

> ...
>
> read more »

[Jean-Baptiste Queru]

Right now I'd say it's evenly split between Google's internal copies
of donut and master.

JBQ

[Rajesh S]

JBQ shouldn't the 'Building for dream' page also be updated to use a
new kernel with 1.5?
Or is the kernel version same across 1.5 and 1.1?

On Apr 28, 1:35 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> Right now I'd say it's evenly split between Google's internal copies
> of donut and master.
>
> JBQ
>

[Jean-Baptiste Queru]

Well, it's not as much the web page as the prebuilt kernel in
vendor/htc/dream. There's a cupcake kernel there, but it's about 4
months old and I suspect that's one of the reasons why home-built
versions are unstable on Dream.

I'm looking at ways to extract the kernel from a "live" device, but
it's not as simple as adb pull. This way we won't be dependent on
potentially outdated kernel binaries.

JBQ

[Farida Khan]

Hi JBQ,

I downloaded the latest release of android SDK 1.5, but unable to give the credentials for the "Google Login Service" from devTools. Clicking on the Google button or any other button crashes. I need to specify the google credentials to access the calendar application so that I can customize it as per the requirements. Can you please let me know if there is any other work around of doing this and accessing the calendar application?

Thanks
Farida

[joel]

FYI I noticed the EAI_NODATA issue is being discussed over here:
http://groups.google.com/group/android-platform/browse_thread/thread/bf053c4b4df3d055

[Chih-Wei]

Hi,
I just tried to download the android-1.5 tag, and rebuilt everything.
But I'm still no lucky. It didn't work, as the master branch.

As you said, I suspects my environment(fedora 10) has problem.
So I installed ubuntu 8.10 and tried to build android-1.5 on it.
However, it didn't help at all. All the problems still the same.
* The EAI_NODATA issue still happened. I have to patch it myself.
* After fixed that error, the code compiled ok. But the emulator still
didn't work. It booted, and hung at the small android logo.
(here is the screenshot: http://218.211.38.204/emulator-hang.png )
'adv devices' showed the emulator is offline

On the other hand, I am sure I can have the emulator run well
using code from one or two weeks ago.
I just reverted my code back to that time to check it.

Anyone can help me?

[Lim,GeunSik]

As you said, I suspects my environment(fedora 10) has problem

I my case, I am still using fedora 9(office) and 10(home) for building
android full source normally.
Chih-Wei, I think that your problem is not related linux distribution.

[Chih-Wei]

On 4月29日, 上午10時27分, "Lim,GeunSik" <lee...@gmail.com> wrote:
> Chih-Wei, I think that your problem is not related linux distribution.

I think so. Thank you!
Do you have a solution?
Anybody has similar problem like me?

[/dev/null]

I had the same problem. However it appeared only after upgrading to
Ubuntu 9.04 (from 8.10). Before that I had no issues with EAI_NODATA.

Some quick Googling yields that the EAI_NODATA macro was removed from
the getaddrinfo API by RFC 3493, published in 2003. To get the code to
build regardless if EAI_NODATA is defined or not change the code to
look something like this;

+#if defined(EAI_NODATA) && EAI_NODATA != EAI_NONAME
case EAI_NODATA:
+#endif
case EAI_NONAME:
err = ENOENT;
break;

See http://www.kaffe.org/pipermail/kaffe/2003-December/181989.html

null

On 28 Apr, 02:32, SPD <sdickey2...@gmail.com> wrote:
> Well, just to get the code to compile (even the android-1.5 version

> has this issue) I commented out theEAI_NODATAfield from the source

[Chih-Wei]

Yes, the EAI_NODATA issue is easy to fix.

But how about the emulator not work issue?
It just hung at the android logo screen.

[Woogie Jeong]

Did you make AVD file ?

Are you using android SDK 1.5?

If you use 1.1, download and change the setting to 1.5.

Also check this following link out for AVD file.

http://developer.android.com/guide/developing/tools/avd.html

2009/4/30 Chih-Wei <cwh...@linux.org.tw>

[Chih-Wei]

Thank you for the reply. I compiled everything from sources.
The steps are like
* repo init ...
* repo sync
* make -j4
* . build/envsetup.sh
* lunch 1
* emulator

I've tried the branches master, cupcake and tag android-1.5.
Basically the results are the same. (the emulator hung at booting)

I'm sure the above steps give me a workable emulator
from the sources about two weeks ago.
(ya, I checked that by reverting back to that revision.
If someone hope to see, I can publish the manifest file of that
revision)
But after updating the source by repo sync, it was broken.

By the way, to answer your question directly,
yes, I've also tried the prebuilt SDK 1.5pre downloaded from net,
and create an avd configuration. The emulator works.
Furthermore, I've done more testing by using the emulator binary
I compiled with the image files from the prebuilt SDK.
(I specified -sysdir directly to the avd directory)
In this way, the emulator also works.
So my conclusion is, my compiled emulator binary
is NOT broken itself, but the image files.

Any idea?

[Amit E]

JBQ,

Thanks for updates. Can you share us more on building for Dream with
1.5 changes.
Which branch would be the best one to use for dream ?. Master /
Cupcake / android 1.5...

Thanks
Amit

> ...
>
> read more »

[michae...@gmail.com]

Thank you very much