search

simpligility / android-maven-plugin

Maven Plugin for Android Application development and more
http://simpligility.github.io/android-maven-plugin/
Apache License 2.0
1.05k stars 395 forks source link

Zipalign has moved from tools to build-tools #399

Closed Shusshu closed 10 years ago

Shusshu commented 10 years ago

To fix it properly we need #303 as some code from the latest library is needed. AndroidSdk line 196 needs to change

A workaround is to copy the zipalign from build-tools\20.0.0 and put it in tools

WonderCsabo commented 10 years ago

This is a serious issue. Unfortunately i see this won't be fixed soon because of the referenced issue is not an easy one. Thanks for the workaround, though.

toonetown commented 10 years ago

Google seems to always be moving their binaries around...would it be possible to just search in all tools paths (i.e. ${SDK}/tools:${SDK}/platform-tools:${SDK}/build-tools/${BT_VERS}) for any binary that gets used?

william-ferguson-au commented 10 years ago

I've been thinking the same thing as @toonetown. Why don't we use a collection of potential bin paths?

toonetown commented 10 years ago

It would also be good to just take from the system PATH variable if none of the other locations match.

Shusshu commented 10 years ago

I think if we use the builder library SdkConstants class it should be fine until they brake everything for their own users too (gradle).

updating the library would fix it if they would be foolish enough to break the backwards compatibility for their own users too.

amp should try to use the latest builder lib maybe even releasing a new amp when a new builder is out.

william-ferguson-au commented 10 years ago

When it deletes zipalign from the tools folder, doesn't it add it to another folder? Or does it just remove it? (NB I haven't updated the SDK lately to avoid this kind of pain).

On Tue, Jul 8, 2014 at 6:01 PM, Benoit Billington notifications@github.com wrote:

Looking into different path won't solve the problem. When you update the SDK tools it currently delete the zipalign from the tools folder.

I think if we use the builder library SdkConstants class it should be fine until they brake everything for their own users too (gradle)

— Reply to this email directly or view it on GitHub https://github.com/jayway/maven-android-plugin/issues/399#issuecomment-48282826 .

Shusshu commented 10 years ago

It adds zipalign to the build-tools/20.0.0 folder (also present in 19.1.0)

Note: I edited the github post so what you received by mail is different than what I wrote 5 min later ;)

toonetown commented 10 years ago

Amp does currently use the sdkconstants class, doesn't it? The problem is that zip align was moved from the tools folder to the build-tools folder.

Shusshu commented 10 years ago

Yes but it is using a 'very' old version of the sdkconstants where at that time zipalign was located in tools.

toonetown commented 10 years ago

But I think that's the question of this bug...why not look for all binaries in the three "main" places (tools, platform-tools, and build-tools...and I would argue, fallback to using the system's $PATH variable)? That way, we don't have to worry about updating the AMP if we want to update the SDK

Shusshu commented 10 years ago

It previously worked like that but then we decided to use the builder lib and use it to load every tool/platform-tool/build-tool with it.

I think they will not make breaking changes in the future.

zipalign got duplicated when build-tools 19.1.0 was released (which means it was in 2 locations: tools & build-tools\19.1.0) it was mentioned in the release note.

with the release of build-tools 20.0.0 they deleted it from tools and made a new one in build-tools\20.0.0

zipalign in the tools folder was first deprecated with the release 19.1.0 and then removed with 20.0.0 which gaves everyone time to move to the new builder version. But because of #303 we didn't use the new builder.

So I don't think we'll face a breaking change in the future.

malachid commented 10 years ago

@Shusshu Well, zipalign is just the most recent breaking change they've made. I think it would be safer to assume that random build tools will move over time. adb was moved. fastboot was removed. etc.

Shusshu commented 10 years ago

Yes but they since they moved to gradle they didn't break it immediately. They had 2 locations for a while

abhijitnukalapati commented 10 years ago

@Shusshu instead of copying it, a simpler workaround would be to have a symlink using the following commands:

cd android-sdk-location/tools
ln -s ../build-tools/20.0.0/zipalign zipalign
malachid commented 10 years ago

The concern I have with modifying the SDK is that I work on a lot of projects that use different build-tools. Any hardcoded one would need replaced every time I switch projects, wouldn't it?

Malachi de Ælfweald http://www.google.com/profiles/malachid

On Fri, Sep 5, 2014 at 1:51 PM, abhijitnukalapati notifications@github.com wrote:

@Shusshu https://github.com/Shusshu instead of copying it, a simpler workaround would be to have a symlink using the following commands:

cd android-sdk-location/tools ln -s ../build-tools/20.0.0/zipalign zipalign

— Reply to this email directly or view it on GitHub https://github.com/jayway/maven-android-plugin/issues/399#issuecomment-54679891 .

mosabua commented 10 years ago

Master is using the latest sdk libraries now.. please test with it.

mosabua commented 10 years ago

This is failing .. e.g try on the samples

cd morseflash mvn clean install -P release

mosabua commented 10 years ago

I am hoping someone can send a pull request while I work on the tests ;-)

Shusshu commented 10 years ago

Got it. I'll submit a PR and close this Almost I first gotta find why this happens: ZipalignMojoIntegrationTest.testBasic:62 [[ERROR] Failed to execute goal com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.5.1:zipalign

Shusshu commented 10 years ago

See #453

zayass commented 10 years ago

Now it doesnt work with old build tools (<19.1.0) I understand its too old and no reasons to use it.

But maybe this would be better

Google seems to always be moving their binaries around...would it be possible to just search in all tools paths (i.e. ${SDK}/tools:${SDK}/platform-tools:${SDK}/build-tools/${BT_VERS}) for any binary that gets used?

malachid commented 10 years ago

While I could see it being possible to scan for all possible tool locations; the bigger issue is when we have to change code to be compliant with new tool expectations (file formats, command line options, etc). Rather than have the plugin maintain backward compatibility with all the outdated tools, it seems like it would be better to pair the older revision of plugin to the older toolchain and allowing the newer revision of the plugin to be paired with the newer toolchain.

Malachi de Ælfweald http://www.google.com/profiles/malachid

On Mon, Nov 17, 2014 at 10:41 AM, Anton notifications@github.com wrote:

Now it doesnt work with old build tools (<19.1.0) I understand its too old and no reasons to use it.

But maybe this would be better

Google seems to always be moving their binaries around...would it be possible to just search in all tools paths (i.e. ${SDK}/tools:${SDK}/platform-tools:${SDK}/build-tools/${BT_VERS}) for any binary that gets used?

— Reply to this email directly or view it on GitHub https://github.com/simpligility/android-maven-plugin/issues/399#issuecomment-63352767 .

Shusshu commented 10 years ago

Yes that sounds like a better plan :)