Source for tools r17

[Radim Kubacki]

Hello,

where can I find sources for recently released version of tools? Is
there a branch in aosp repository / tag?

I am trying to find why dex is not adding my libraries to the output
and what seems to be working in simple setup is not working for my
bigger project.
http://tools.android.com/recent/dealingwithdependenciesinandroidprojects
is not a solution - I see the problem when building from command line.
And I have a report where the build is different when started from IDE
or started from command line so I suspect some strange bug.

-Radim

[Xavier Ducrohet]

We don't have the our r17 branch pushed externally yet (Because it was done internally), but if you look at master you'll get the same as r17 as far as build system is concerned.

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

Please do not send me questions directly. Thanks!

[Radim Kubacki]

Nevermind, I found the problem why 'dex' is sometimes not adding
libraries to the output: it depends on current working directory.

This works when executed in a project directory:
ant clean debug

This will fail and all MyAndroidApp/libs/*.jar files are ignored here:
cd ..
ant -f MyAndroidApp/build.xml clean debug

Now I need to find whether I will be able to set (mock) working
directory when performing build from NBAndroid plugin. Or is there a
chance to see SDK tools update soon?

-Radim

2012/3/22 Xavier Ducrohet <x...@android.com>:

[Manfred Moser]

When are you going to push the r17 branch ?

[Xavier Ducrohet]

arg, that's crappy.

I'm not sure we'll be able to update the tools again very soon.

Our next tentative date for another update is end of April.

[Xavier Ducrohet]

It's now available. You'll have to manually edit your main manifest to map sdk.git and external/qemu.git to the "tools_r17" branch.

[Radim Kubacki]

2012/3/23 Xavier Ducrohet <x...@android.com>:

> It's now available. You'll have to manually edit your main manifest to map
> sdk.git and external/qemu.git to the "tools_r17" branch.
>

I've seen these branches pop up when 'repo sync' was running. What
exactly do I need to do to switch to these branches? I suppose I need
to edit something in .repo dir but I can't find any documentation.
Thanks.

-Radim

[Xavier Ducrohet]

edit .repo/manifest.xml (which is a symlink to .repo/manifests/default.xml)

And edit the line <project path="sdk" name="platform/sdk" /> to add branch="tools_r17" and then do a repo sync.

do the same for external/qemu

[Radim Kubacki]

2012/3/23 Xavier Ducrohet <x...@android.com>:

> edit .repo/manifest.xml (which is a symlink to .repo/manifests/default.xml)
>
> And edit the line <project path="sdk" name="platform/sdk" /> to add
> branch="tools_r17" and then do a repo sync.
>
> do the same for external/qemu
>

Thanks. I can build anttasks.jar now. Build of full SDK fails for me
because I do not have 32-bit version of x11-dev library (and probably
others too). I do not know where to get them for my Linux Mint Debian
Edition and it is not critical now.

Back to original problem: some JARs are not passed to dex. Should I
file a bug report somewhere? Can you notify this list when you have
fix? I can try to build a patched version of anttasks.jar and use it
when building in NetBeans. (We cannot change working directory because
the build runs in the same VM as the IDE.)

BTW: I expect that some users will hit it with their Jenkins builds
too as they often do 'ant -f path/to/project/in/scm/build.xml release'

-Radim

[Xavier Ducrohet]

The fix is in the internal tree. should be pushed to AOSP within an hour or so.

sha1 is 7a10e408bbada4ff9374eacfae3e5801ab1e0f0a

[Ievgenii Nazaruk]

Still can't see the change with 7a10e408 (or I'm doing something wrong).

Quick question: Is your fix is in NewSetupTask.java:564

-  File libsFolder = new File(SdkConstants.FD_NATIVE_LIBS);
+ File libsFolder = new File(antProject.getBaseDir(), SdkConstants.FD_NATIVE_LIBS);

For me this bug either breaks the build or builds application without including some libraries (which causes NoClassDefFoundError at runtime).

Also I found that this can be fixed in ${sdk.dir}/tools/ant/build.xml by adding next lines:

270a271,273
>                       <path>
>                               <fileset dir="${jar.libs.absolute.dir}" includes="*.jar" />
>                       </path>
676a680
>                       <fileset dir="${jar.libs.absolute.dir}" includes="*.jar" />

This might be helpful if someone can't wait for next release and doesn't want to rebuild anttasks.jar.

[Xavier Ducrohet]

yes this is my change. Looks like it hasn't made it to AOSP yet.

The strange part is that it broken different type of builds but not all of them.

I've put a new build of anttasks.jar at http://tools.android.com/anttasks.jar

I'm taking a quick look at other possible breaking issues before figuring out when we can push a fix to everyone.

[Ievgenii Nazaruk]

I've been playing with this thing. And it looks like it always breaks the build for test projects at -compile (because javac task doesn't see *.jars from project's "libs" folder). While for usual apps the failure occurs only at -dex step ("failure" meaning it builds ok, but libraries from "libs" folder are not picked up; apps then crashes at runtime).

By the way, while we at this, I've noticed another similar issue with emma. When "ant -f app-test/build.xml instrument" is run, the "coverage.em" is generated in working folder instead of being generated in "app-test" folder. This can be fixed by:

(build.xml:715)
<emma ... >
     <instr outfile="${basedir}/coverage.em" ... />
</emma>