search

kingdom578 / maven-android-plugin

Automatically exported from code.google.com/p/maven-android-plugin
0 stars 0 forks source link

APK doesn't include libs folder from APKLIB #444

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Create an APK project
2. Let it depend on an APKLIB project with native libs (ie containing 
/libs/armeabi-v7a/libsomething.so)
3. Build the APK project

What is the expected output?
An APK containing a /lib folder with the APKLIB's architecture(s) folders in it.

What do you see instead?
An APK with no lib folder.

What version of maven-android-plugin are you using?
3.6.x, 3.7.x and 3.8.x

What are the complete output lines of "mvn -version" on your machine?
Used mvn 3.0.4 for plugin 3.5.x and mvn 3.1.1 for plugin 3.6.x and up.

Please provide any additional information below.
3.5.x work as expected.

Original issue reported on code.google.com by j.bros...@gmail.com on 5 Feb 2014 at 10:23

GoogleCodeExporter commented 9 years ago 
I have done some testing and it seems that the error is in NativeHelper.java. 
The regex pattern is flawed, if I change the unit test to reflect a file path 
with 'armeabi-v7a' in it, the test fails. I am in no way a regex guru but this 
should be simple fix. In any case the regex could be more strict, like 
including an ignore case rule.

I have now patched the NativeHelper by removing the check altogether and my APK 
builds fine again (including the *.so files from the armeabi-v7a folder in the 
APKLIB project.

Original comment by j.bros...@gmail.com on 5 Feb 2014 at 3:14

GoogleCodeExporter commented 9 years ago 
Replying to myself: the regex pattern should read "^.*(?<!(?i)\.jar)$"

It can be explained as: match only when the end of the string is not preceded 
by the case insensitive substring ".jar"

Original comment by j.bros...@gmail.com on 6 Feb 2014 at 2:04

GoogleCodeExporter commented 9 years ago 
Fix is in master, will be going out with 3.8.3+

Original comment by mosa...@gmail.com on 7 Feb 2014 at 6:00

GoogleCodeExporter commented 9 years ago 
Please correct me if I'm wrong, but tested the commit using the current master 
(9ca7c082e31c64c3a61812f4dd14f1f2ea88db54). 

It seems to me that the used path is incorrect:
NativeHelper.java, line 176
File libsFolder = new File( AbstractAndroidMojo.getLibraryUnpackDirectory( 
unpackDirectory, artifact ), "libs" );

The problem sees that getLibraryUnpackDirectory in AbstractAndroidMojo does 
return a path containing only the artifactId, but in fact the dependent 
libraries are unpacked in a directory like "groupId_artifactId". So the check 
can never be true, as the libsFolder.exists() condition should always fail.

I tested this using a rather large project which has a native library in a 
libs/armeabi folder inside a dependent apklib, but was only able to get it into 
the lib folder after patching AbstractAndroidMojo.getLibraryUnpackDirectory to 
use the groupId too.
The issue is somewhat covered in the NativeHelperTest in 
shouldIncludeLibsFolderAsNativeDependenciesSourceWhenNativeLibsInside and 
shouldNotIncludeLibsFolderAsNativeDependenciesSourceWhenNoNativeLibsInside so 
I'm not sure if there is something wrong with my build (the apklib was created 
using maven-android 3.6.0).

If needed, I can create a pull request changing 
AbstractAndroidMojo.getLibraryUnpackDirectory and fixing the tests.

Original comment by RenePlo...@gmail.com on 18 Feb 2014 at 3:39

GoogleCodeExporter commented 9 years ago 
Can you provide a projects that shows the failure?

Original comment by william....@xandar.com.au on 27 Feb 2014 at 10:27

GoogleCodeExporter commented 9 years ago 
Rene, unless you can provide a project showing the failure I'm going to close 
the issue.

Original comment by william....@xandar.com.au on 10 Mar 2014 at 11:48

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Sorry for the long delay ...

I used the test projects to reproduce against the current master 
(0c07c4ee9f3c2a4c366dabf2a3b2b798a5e93a60)

In the zip are two projects, and apklib project which is meant to be installed 
via mvn install, and an apk project which is depending on the first.

When doing this, the apk will not contain the lib (foo.so) from the apklib 
project. When switching to 3.8.1 as plugin version the bug does not occur (so 
in fact it seems to be a regression - 3.8.1 does unzip with version, 
3.9.0-SNAPSHOT does not). As mentioned, the NativeHelperTest might be invalid 
as they do not cover that case.

Original comment by RenePlo...@gmail.com on 12 Mar 2014 at 4:40

Attachments:

GoogleCodeExporter commented 9 years ago 
Rene, I can't reproduce this.

Using the libraryprojects.zip you attached building against 3.9.0-SNAPSHOT 
(0c07c4ee9f3c2a4c366dabf2a3b2b798a5e93a60) both projects build just fine.

Original comment by william....@xandar.com.au on 15 Mar 2014 at 2:00

GoogleCodeExporter commented 9 years ago 
Hi, I created a build script to cleanly reproduce this without outside 
interference (e.g. no settings.xml / existing Maven repositories etc):

This script will:
0. Cleanup old files from previous runs (if any)
1. Download Maven 3.2.1 from remote
2. Download current master.zip from github
3. Set the Maven repository to a directory named "repo" in the current working 
directory
4. Build current plugin and install it into "repo"
5. Build libraryprojects-apklib1 and install into "repo"
6. Package "libraryprojects-apk-with-deps"
7. Check whether foo.so does exist in apklib and apk

Using this script foo.so is not inside the apk, but in apklib, I get:
foo.so found in apklib
foo.so not found in apk

Prerequisites:
- GNU coreutils (rm, mkdir), tar, unzip, wget, awk, grep
(probably only relevant if using Windows / Cygwin - most Linux distributions 
will have this installed)

Attached:
- libraryprojects.zip from above + build.sh
- (zipped) build.log for an initial run so you can diff your results against 
mine if needed

Original comment by RenePlo...@gmail.com on 18 Mar 2014 at 4:21

Attachments:

GoogleCodeExporter commented 9 years ago 
Hi Renee,

To start simple, I am trying the libraryprojects without the build.sh first.  I 
want to eliminate the build environment as part of the problem.

Building each directory *said* they worked.

Using apktool on the resulting apk, it did not contain the foo.so

The apklib did contain the foo.so

libraryprojects-apk-with-deps/target/unpacked-libs/cjmpagsl_libraryprojects-apkl
ib1/libs/armeabi also contained the foo.so

So with this particular project (even without your build.sh) it appears that 
the apk failed to include the foo.so from the unpacked-libs directory.

Original comment by malac...@gmail.com on 22 Mar 2014 at 3:19

GoogleCodeExporter commented 9 years ago 
Confirmed that it is looking in 
libraryprojects-apk-with-deps/target/unpacked-libs/libraryprojects-apklib1/libs 
instead of 
libraryprojects-apk-with-deps/target/unpacked-libs/cjmpagsl_libraryprojects-apkl
ib1/libs

Original comment by malac...@gmail.com on 22 Mar 2014 at 4:05

GoogleCodeExporter commented 9 years ago 
Ok, I have a pull request for this. apktool now shows foo.so being included in 
the apk.

https://github.com/jayway/maven-android-plugin/pull/313

Basic jist of it is I switched it from using the static 
AbstractAndroidMojo.getLibraryUnpackDirectory to getUnpackedLibNativesFolder on 
the mojo.

Original comment by malac...@gmail.com on 22 Mar 2014 at 4:42