Is it possible to build SDK tools and platform-tools from AOSP?

[Tomislav Vujec]

I was trying to create an RPM package for SDK tools and platform-tools by compiling AOSP. Looking at the content of out/host/linux-x86/sdk, I can see most of the pieces there (except for the llvm-rs-cc renderscript compiler), so it shouldn't be a problem to do this. However, since I wanted to stay as close to the google's binary distribution as possible, I need some help with the following issues:

1) How do I find which branch/tag/change corresponds to the actual google release - e.g. tools_r10 and platform-tools_r3? Analyzing comments in the repository.xml that gets downloaded by the android tool, I did find references to branches, but I have no idea on what to do with the number that's present in the comment as well.

2) Since there is no make target that'll build just tools, I had to compile the whole sdk, which is extremely time consuming and resource intensive, both for the checkout and compilation. Since I am trying to make the whole process automated, this is something I would like to avoid if possible. Short of running make with targets for each file needed in tools, is there any target that'll get me there in a more portable way (e.g. that'll still work when google adds/removes files from the future versions of tools)? If not, would Google be likely to accept the patch to the build system that would add a target to package (and possibly build) only the stuff referenced from sdk/build/tools.atree?

3) This probably should have been the first question, but nevertheless. Is Google planning to keep tools completely open source in the future (or at least close), or should we expect more important pieces (like renderscript compiler) to come in the future, rendering OSS version of tools undesirable for separate distribution? There is still a value in distributing tools as part of an OS, even when one doesn't plan to use the SDK. E.g. adb can have wider applications.

Any help with the above would be much appreciated.

[Xavier Ducrohet]

1) We normally tag the git repo when releasing plug-ins and tools but
we haven't done so recently. I'll try to fix that.

2) I think it would be great to have a target that only does the
tools, one that does the platform-tools, one that does the platform,
etc... (I think there's already a target called offline-docs or
something) and have the "sdk" target do them all. As long as the patch
is good (and changing Android makefiles is not my area of expertise)
we should be able to accept it. I would post a proposal on
android-contrib before moving further.

3) I'm not sure I understand the question, but here goes: tools (the
content of $SDK/tools) will remain open source and development is
happening in the open. Tools under $SDK/platform-tools are revisioned
with the platform and will therefore follow the development model of
the platform (which currently is develop internally and push to the
open when released).
An issue with creating an RPM package and possibly bundling them with
an distrib is making sure they are up to date always. I really don't
want to have users complain that their distribution come with obsolete
tools that no longer work. We do change things quite a bit in the
tools and newer platforms usually requires the most recently tools.
Also, the SDK folder is designed to be a self contained folder with
everything in it (tools, platform-tools, platforms, ...) so you'd have
to make sure the included sdk tools would be in a folder that is user
writeable so that they can install new platforms as they are released,
etc... (and this can potentially create issues in multi-user
environments...)

Xav

> --
> 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
>

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Samuel B. Quiring]

Greetings,

I just built a Nexus S image (GRI40 2.3.3) from source and flashed it onto
the phone. The Keyboard settings screen:

Settings -> Language & keyboard -> Keyboard settings section

has 3 items under it:

1. two lines of asian letters (Japanese?), the 2nd line ends with "settings"

2. Japanese IME
Japanese IME settings

3. Android keyboard
Android keyboard settings

I have a retail Nexus S (GRH78 2.3.2) and it only has the 3rd item.

Does anyone know what I need to do to make my build match the retail phone?

-Sam

[Jean-Baptiste Queru]

Remove PinyinIME, OpenWnn and the libWnn* packages from
build/target/product/full.mk

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 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.