Android SDK r17 libs folder issue

Hi.



The latest update of the Android SDK seems to have broken support for the “libs” folder somehow. This is true for all android projects, command-line, SDK or eclipse created. If anybody has an idea on how to make support for jar libraries in the libs folder work again it would be appreciated. You might want to check (android sdk)/tools/ant/build.xml which is used for the android projects across all development environments including the SDK and Eclipse.



What the SDK build script does at the moment is calling the “debug” target and then the “installd” target for running the application and calling the “release” target for releasing, just like outlined in the android SDK manual :?



Cheers,

Normen

@normen



I have provided a link to the changes that they made to the android.



Link



It seems they made changes the way jars are handled by two projects referencing the same jars.

Thanks, but here is only one project, the one in /mobile… I checked their docs, basically they say handling of external libs should be better now (which is obviously not the case) ^^

I found out that when running the build of the mobile project from command line, the libraries seem to be copied into the release apk, if its called from another script or nbandroid or eclipse it doesn’t… :? – seems google’s dex tool is messed up…



Edit: So, as a workaround you can for now replace all “ant” calls in nbproject/mobile-impl.xml with a call to the command line ant if you have it installed. Add the following to your main build.xml (the one in the BasicGame project root) to override the targets in mobile-impl.xml:



[xml]

<target name=“run-android” depends="-flag-no-android, jar, -test-android-enabled, -copy-android-libs" if=“is.android.enabled”>

<echo>Building debug android application version.</echo>

<!–ant dir=“mobile” target=“debug”/–>

<exec executable=“ant” dir=“mobile”>

<arg value=“debug”/>

</exec>

<antcall target="-start-android-device"/>

<!–ant dir=“mobile” target=“installd”/–>

<exec executable=“ant” dir=“mobile”>

<arg value=“installd”/>

</exec>

<antcall target="-run-android-device"/>

</target>



<target name="-mobile-deployment" depends="-test-android-enabled, -copy-android-libs" if=“is.android.enabled” unless=“no.android.build”>

<!–ant dir=“mobile” target=“release”/–>

<exec executable=“ant” dir=“mobile”>

<arg value=“release”/>

</exec>

<copy todir=“dist” verbose=“false” flatten=“true”>

<fileset dir=“mobile/bin/”>

<include name="**/*.apk"/>

</fileset>

</copy>

</target>

[/xml]

1 Like

this is great thank you :slight_smile:

but now i got a new error:

The following error occurred while executing this line:

Target “-test-android-enabled” does not exist in the project “MyGame”. It is used from target “-mobile-deployment”.



sorry i have my difficulties with this :confused:

Well you have to enable android deployment… Also make sure you add the targets after the import statement in the build.xml

Thanks a ton for the work around. I was wondering why things weren’t working after I updated the SDK.

@cheshirekow said:
Thanks a ton for the work around. I was wondering why things weren't working after I updated the SDK.

Np, if anyone finds out how to circumvent this without having to rely on command line ant it'd be appreciated.
@normen said:

[xml][/xml]
<target name="run-android" depends="-flag-no-android, jar, -test-android-enabled, -copy-android-libs" if="is.android.enabled">
<echo>Building debug android application version.</echo>



i add the xml to build in BaseGame and run as Android, but that's an error shows
Building debug android application version.
D:JMonkeyworkspaceBasicGamebuild.xml:78: Execute failed:
java.io.IOException: Cannot run program "ant" (in directory "D:JMonkeyworkspaceBasicGamemobile"):

what's wrong?

@denzel: I have the same error. I think you should install “ant” seperately and add it to your path.

1 Like

Thanks for the workaround! However, when I build my program for android, I get this message:



[dx] trouble processing “javax/net/ServerSocketFactory.class”:

[dx]

[dx] Ill-advised or mistaken usage of a core class (java.* or javax.*)

[dx] when not building a core library.



and the build fails. I don’t believe I am using any library that includes ServerSocketFactory.java. Any tips to fix this?



Thanks in advance!

Probably that class doesn’t exist on android, where is it used?

I have added Ant to my path, but I still get the cannot run Ant error. When I type “ant” in a DOS box ant runs.



Does anybody have a suggestion what can be wrong ?

@normen: Isn’t this something we’re looking for ?

http://android.foxykeep.com/dev/how-to-fix-the-classdefnotfounderror-with-adt-17

@Vortex said:
@normen: Isn't this something we're looking for ?
http://android.foxykeep.com/dev/how-to-fix-the-classdefnotfounderror-with-adt-17

Not really, that guy was using a specially assigned folder for his libraries called "lib", the property that was used for this kind of library folder was deprecated however, making this not work anymore. We used the default "libs" folder of android projects from the start which doesn't need any special configuration, so this doesn't help us much I'm afraid :/

As said, the projects are technically working, just the custom ant task that google uses seems to fail to get the correct root path from the ant environment, I do specify it when calling the android project ant script from the main projects script. I guess google uses some non-default way to find out about the current path that ant runs in and then probably finds the main project folder (from where the main ant script is run).. Which makes me think.. what happens when you copy the "mobile/libs" folder with its contents to the project root..? Maybe we can find some workaround that doesn't involve command line ant..

I just updated the Android SDK to r18 and the issue seems to be gone, no more command line ant needed. Can anyone confirm this for windows?

1 Like

Workaround solved my problems, thanks normen.

Just tested, after updating Android SDK to rev 18, it worked without the workaround.

No need to update IDE.

Thank you again, normen.

1 Like