search

jvoegele / gradle-android-plugin

Android plugin for the Gradle build system.
Apache License 2.0
406 stars 95 forks source link

Doesn't work with Android SDK downloaded in December, 2010. #14

Closed alximik00 closed 13 years ago

alximik00 commented 13 years ago

Part of gradle console output:

As I found today, Google little changed ant tasks, so "aaptexec" and "aptbuilder" doesn't work with old attributes.

Will be much appreciate for help.

fdasoghe commented 13 years ago

I think you're talking about the new Gingerbread SDK... if it's that, you're right: the new SDK changed quite a bit, so there is need to add explicit support for it.

Stay tuned, it will be fixed in the next few days.

Cheers,

Fabio

fdasoghe commented 13 years ago

Digged into the usual ant_rules_r2.xml file...

About apptexec, they changed some names: from "basename" to "apkbasename"; from "resources" to inner element <res path="" > from "outfolder" to "apkfolder"

About ApkBuilder, the changes I see are: from "apkfilepath" to... none from none to "basename" (are the same? not sure) from <dex> to <file>

Jason, do you think it's a good idea to create two subclasses instead of AaptExecTask, for example AaptExecTask_r7 and AaptExecTask_r8? ...maybe r_07 and r_08, they are near 10 ;o)

fdasoghe commented 13 years ago

Mmmhh... it seems that ApkBuilderTask_r6 is quite near the new ApkBuilder ant task specifications... maybe we can reuse it to supply compatibility for the new SDK? (on master branch it misses the sourcefolder parameter - that causes the resource files to not be included in the final apk).

mttkay commented 13 years ago

Just trying to understand the issue here: does gradle-android depend on Ant in order to build an APK? Wouldn't it be safer to invoke the platform tools directly from Gradle instead of going through Ant?

fdasoghe commented 13 years ago

I understand your point. Premise: I don't know why Jason made that choice (I hope he will reply here).

For what I've seen, there are not particular guarantees of one choice over the other: it seems the platform tools interface changes as well... maybe the Ant tasks are more "stable" because they are wrapped by the default build script provided with the sdk itself (that is, the script that is generated by the android tool).

We are going to write to Google on the official channels (lists, forums, etc.) to ask some type of "official" support, at least a safer direction to follow in order to not be badly broken at every release of the platform.

Do you have a different experience with the sdk tools? Are they really more secure and stable in their interface?

jvoegele commented 13 years ago

The gradle-android-plugin does indeed depend on Ant and the Ant scripts that are packaged with the SDK. I chose this mechanism since it seemed the most straightforward at the time, but if there is a better mechanism then I'd be happy to use that instead. I'm not tied to the current implementation in any way.

mttkay commented 13 years ago

ok, valid points. I assumed that the command line tools have been stable in terms of use ever since and only the ant build scripts would change once in a while, which apparently is not the case.

Ladicek commented 13 years ago

I ran into this problem too and decided to solve it. Two evenings of looking into the source of Android SDK and I managed to build my super-simple Android application (only signing with debug key, didn't try to do the "release"), install it on the device (emulator and real phone too) and uninstall.

You can find the code in my fork in sdk_r8_support branch (https://github.com/Ladicek/gradle-android-plugin/tree/sdk_r8_support). I took the easiest way, so I added ApkBuilderTask_r8 and split AaptExecTask into AaptExecTask_r7 and _r8. Also the adb tool was moved from tools/ to platform-tools/; I'm pretty sure my solution is not great, but the change is small at least.

I would be glad to make whatever changes you think are necessary.

One thing I'm not satisfied with and don't know how to solve: when gradle androidInstall fails to install package to the device (presumably because adb server is not running as root), the error message really isn't much of help. But this is totally unrelated.

As to using Ant: I think we can stick with it for the time being, but using sdklib directly and calling the tools by hand is probably better alternative for the future (supporting NDK, libraries projects, etc.). I'm no expert in this field though, maybe Ant tasks will suffice.

More informations about Android SDK tools is at http://tools.android.com/, its git repository is platform/sdk.git (http://android.git.kernel.org/?p=platform/sdk.git;a=summary).

Hope this helps someone, and thanks for building Gradle Android plugin!

jvoegele commented 13 years ago

Thank you. I'll take a look at the diffs over this weekend and assuming there are no problems I'll get it merged with master.

fdasoghe commented 13 years ago

Wow! Great! This is the power of Open Source: I was working on this same exact issue and you were faster ;-)

I'll do some testing too and report here my esage experience.

About the "thing you're not satisfied with": I've noticed it too and reported it in the issue #12.

Cheers!

mttkay commented 13 years ago

by the way: regarding my earlier remark, about using Ant instead of the command line tools, I understand your rationale now. I have had a closer look at how maven-android-plugin is implemented, and also how the build.xml generated by android create project is structured, and as far as I understand, the only way to build an APK these days is by going through Android's ApkBuilder.java, since the apkbuilder tool has been deprecated.

I suppose that means that basing gradle-android on the Android Ant targets is the way to go.

UPDATE: maybe I have to revise again. It looks as if the aapt tool is also capable of creating APKs. This is so odd. Why are there 3 different ways of building an APK?

fdasoghe commented 13 years ago

I've done some testing with your branch (sdk_r08_support) and all works fine for me. I've built my production project (that is, a real world application) and the package is ok!

Anyway, I updated Gradle to latest version (0.9.1) and I got a new error, reported in this issue: http://jira.codehaus.org/browse/GRADLE-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel

Am I the only seeing this bug?

We should bypass it with the simplified patch you just submitted ;-)

About the aapt, yes, it seems a little mess the Android tools universe... for this reason I think it should be worth to ask "ufficially" some type of support from Google with open source toolkits like the gradle-android-plugin.

Thank you again, cheers,

Fabio

jvoegele commented 13 years ago

I merged the changes from Ladicek into master. I'll cut a 0.9.7 release based on it.

What do you guys think about 1.0 release? Any major issues you'd like to see resolved before 1.0?

fredgrott commented 13 years ago

Okay, good work guys..I look forward to the 0.9.7 release..

Integrating some code QA on top and some plumbing for vogar(google's internal tool made public at google code to drive caliper, etc, tests)..

Any idea when this week? Thanks..

jvoegele commented 13 years ago

I have released 0.9.7 with all the latest fixes. Thanks to all who've contributed time and patches.

fdasoghe commented 13 years ago

Look, they talk about the latest release on the web: http://mobilebytes.wordpress.com/2011/01/11/gradle-android-plugin-0-9-7/

About you question, Jason, for the 1.0 release I would expect:

fredgrott commented 13 years ago

Yes, I know as its my blog post :)

I should have some posts shortly on tutorials on how to use the plugin..complicated stuff like enabling a NDK/JNI c++ compile before the java compile, etc..

Great plugin...once things settle down will turn some of my own code into a code contribution to the plugin

fdasoghe commented 13 years ago

Happy to see the use of full-fledged build systems spreading in the Android platform! :o)

mttkay commented 13 years ago

as to the 1.0 release requirements:

From my (short) time with Gradle, I had the impression that there's no target to run instrumentation tests. Is that true? If so, will a Gradle build at least run the tests as part of the default build target?

mttkay commented 13 years ago

Also: I can't see how you can tell gradle-android which device to target. Had a quick peek at the sources, and also couldn't find anything in there. On my dev machine I usually run at least 2 emulators and have my phone plugged in, so the build just sits there and hangs.

That would be a definitive 1.0 requirement from my point of view.

Ladicek commented 13 years ago

It works like adb without an argument ("adb install ..."). There is adb.device.arg variable, which is currently set to empty string, but shouldn't be hard to set to something else. Not sure about user interface though (maybe cmdline arguments like adb? E.g. gradle androidInstall -e?). Filing another issue would be probably better, as this one should be closed I believe.

fdasoghe commented 13 years ago

Yes, I agree, I completely forgot the testing part. And it's a tool I really count on.

Maybe, without the testing support, we could make a 0.10 release, and doing a full-fledged 1.0 with testing capability?

mttkay commented 13 years ago

Would it make sense to set up a Google mailing list for discussion or something? It would be good to have a gradle-android-dev list/group to discuss things before filing tickets.

fdasoghe commented 13 years ago

It makes much sense to me. There are several projects that use GitHub for source hosting and Google Code for issue tracking/discussing/documentation. For example one of our competitor, maven-android-plugin ;-)

Jason, what do you think about it? I volunteer to open a Google Code project for hosting issues, documentation and discussion list/forum (migrating the current content).

jvoegele commented 13 years ago

That approach sounds very good to me. Fabio, please do create a Google Code project for us and send along invitations to everyone on this thread and also ncarroll (Nick Carroll).

fdasoghe commented 13 years ago

Ok, I'll try this evening (I say try because currently I'm sick :-( )

fdasoghe commented 13 years ago

Hello.

I've created a Google Code hosting for this project, and two linked Google Groups (user and developer).The intent is to use Google's facilities for every aspect regarding discussions, issue tracking, documentation, wiki, and keeping using GitHub for source code repository, forking and merging.

The project is here: http://code.google.com/p/gradle-android-plugin/

Please, don't open new issues on GitHub but on the new hosting project.

Cheers,

Fabio

jvoegele commented 13 years ago

Gingerbread compatibility is in the latest version.