Failing to install on device doesn't break the build

fdasoghe commented 13 years ago

During the androidInstall task, if the install command fail installing on the physical device, the build completes successfully but it shouldn't to.

Running Gradle with -d -S flags shows this line:

[INFO] [org.gradle.api.internal.project.ant.AntLoggingAdapter] [ant:exec] Failure [INSTALL_FAILED_INSUFFICIENT_STORAGE]

Any clue about why the error is seen as an INFO from Gradle?

mttkay commented 13 years ago

Maybe it's writing to stdout instead of stderr? Just a hunch.

Interesting to note though that the maven-android-plugin has suffered form the same issue from day one, and they still didn't manage to solve it (but then again, not sure how hard they tried -- I for myself think it's definitely an issue)

Ladicek commented 13 years ago

Yeah, on rare occasions, build succeeds while the installation actually fails. You can easily reproduce it on emulator by filling the /data partition up with some data so that the apk can be copied there, but not installed.

I digged into it and found out that:

the error is really written to stdout (but I think it really doesn't matter)
exit code is 0 (that would be the problem)
installation itself is run on the device and adb just displays all it gets (it just doesn't know that there was a failure)
pm install on the device also returns exit code 0 in case of failure, so even if adb returned the exit code it got back from device (which it doesn't and maybe it doesn't get the exit code at all), it wouldn't help

To sum up: we're screwed. The only option I can think of is capturing stdout and looking for "failure".

Or, in the very spirit of open source, trying to contribute to AOSP :-) I was able to find adb source, it's in platform/system/core repository, but I have no idea where is the source of pm. Necessary changes would probably be backwards incompatible, so... I don't know.

fdasoghe commented 13 years ago

Great analisys!! It seems we're really screwed. Contributing to AOSP would be cool, but it doesn't seem easy to me. Maybe, for a fast solution that works, we could just do as you suggest: parsing the output searching for some smart strings.

Ladicek commented 13 years ago

Gradle is capable of capturing stdout/stderr, because it does that for logging. I digged into the source and it seems that it really isn't meant to be used by plugins to do some work -- I'll probably try to ask on the mailing list.

Ladicek commented 13 years ago

Glad to say I was wrong, we can easily capture stdout/stderr using an Exec task (http://gradle.org/0.9.1/docs/dsl/org.gradle.api.tasks.Exec.html). We are currently running adb by ant.exec -- I'll try to convert it to Gradle's own exec and we'll see.

Ladicek commented 13 years ago

OK, so I did some preliminary work on this in my detect_unreported_adb_failures branch (https://github.com/Ladicek/gradle-android-plugin/tree/detect_unreported_adb_failures). I'm not entirely satisfied with it, but it pretty much works (see details in commit message).

jvoegele commented 13 years ago

I've gone ahead and merged Ladicek's detect_unreported_adb_failures branch into master. There is still the issue of the spurious failure when uninstalling a non-existant package, but at least it works for most cases.

mttkay commented 13 years ago

Related to this (sorry for taking this slightly off-topic again, but unless there's a discussion group, what can I do), I noticed that gradle-android is in general a wee bit too quiet about failures communicating with the device.

For instance, if there's more than one emulator or device running, adb will enter the 'wait for device' state unless you invoke it with -d/-e/-s. From the perspective of the build script, the build is locked up at that point, with no indication what exactly went wrong.

To detect these issues, one has to run Gradle with the -i flag, to enable info logging. In general, I find it difficult to see what gradle(-android) is currently doing, and why it fails (if it fails). I'd like to vote for an option to make the build more verbose, especially in error situations. Even with info level logging, the commands issued by gradle-android (e.g. with which parameters it invoked adb, or that it even invoked adb at all!), is simply invisible to the user.

jvoegele commented 13 years ago

Can you create a separate issue for a verbose setting? I'd like to close this issue once the fix is confirmed, but don't want to lose your request in the process.

mttkay commented 13 years ago

done, filed as issue #18.

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 / gradle-android-plugin

Failing to install on device doesn't break the build #12