In the recent use of MAVEN, encountered a problem, with Maven launched the APK has problems can not start, but the idea of packaging is normal.
The problem with the log is that there is a problem with one of the resources in the Apklib form of a dependency package. Anti-compilation vs. maven package and idea package to find out where the problem lies.
Assumption: The main module package is named Com.android.main
apklib Dependency package named Com.android.apklib
the problematic resource (layout) is named MyView
Problem: apk Package apklib resource files that depend on the package are integrated with the resources of the main module, and the dependent package reference resource is actually looking for the corresponding resource in the R file of the main module.
1) in Maven package: The value of MyView in the R file under Com.android.main is 0x7f050001, while the MyView value in R file under Com.android.apklib is 0x7f070001, and it is used within the program The index at the source is also 0x7f070001. When the program runs to this code, it will go to the main module R file to find 0x7f070001, but the main module 0x7f070001 the corresponding resource is not a layout, so there will be an error.
2) Idea Package: The value of MyView in the two R files is the same, so the resources can be found correctly, the program will not be wrong.
So you know the problem, but how does the problem arise?
After reviewing the MAVEN print log, a package process is organized as follows:
1) Copy all dependent packages to the project/target/unpacked-libs, consolidate the resource files, and then generate the main module and the R.java of each dependent package.
2) Compile the class file, including the R file for the corresponding package you just generated. Note: When compiling a Java file under Com.android.apklib, the index of the corresponding resource in the code is consistent with the R file under the Com.android.apklib package generated by (1)
3) Generate Dex
4) Build apk
This allows us to note that while the runtime dependency package looks for resources in the main module R file, it compiles at compile time according to the R file under its own package.
Use MAVEN to process resources only (MVN clean android:generate-sources) to view the generated R.java files and discover the cause of the problem:
The generated R.java file, the main module is conflicting with the dependency package, and the same resource corresponds to a different index. This makes it problematic to rely on resource indexes in package code when compiling, which can lead to problems. That means Maven has a problem generating the R.java file.
Continue to view the MAVEN print log and find the log section for generating the R,java file, which is the command that executed the AAPT. As follows:
Aapt.exe package-f--no-crunch-i D:\AndroidSDK\sdk\platforms\android-16\android.jar-M d:\ project directory \androidmanifest.xml- S d:\ project directory \res-s d:\ project directory \target\unpacked-libs/Dependency package name/res-a d:\ project directory \target\generated-sources\combined-assets\assets-m -j d:\ project directory \target\generated-sources\r--output-text-symbols d:\ project directory \target--auto-add-overlayaapt.exe Package-- Non-constant-id-m-j d:\ project directory \target\generated-sources\r--custom-package main module package name-M d:\ project directory \target\unpacked-libs\ dependency package name \ Androidmanifest.xml-s d:\ Project directory \target\unpacked-libs\ Dependency package name \res--auto-add-overlay-a d:\ project directory \target\unpacked-libs\ Dependent package name \combined-assets-i D:\AndroidSDK\sdk\platforms\android-16\android.jar;
The first command is to generate the main module R file, and the second command generates a dependent package R file. See the R file that found the main module everything is OK, so that's the problem with the second command. Because I have not studied packaging before, the AAPT command is very unfamiliar, so I do not know how to modify. After searching on the internet, slowly familiarize yourself with the function of each part of this command. The second command simply generates a dependent R file, which is not associated with the main module, which is actually generated separately and therefore conflicts. The modification is simple, as follows:
Aapt.exe Package--non-constant-id-m-j d:\ project directory \target\generated-sources\r--custom-package main Module pack name-M d:\ project directory \target\ Unpacked-libs\ Dependency Package name \androidmanifest.xml-s d:\ project directory \res-s d:\ project directory \target\unpacked-libs\ Dependency package name \res--auto-add-overlay-a D:\ project directory \target\unpacked-libs\ dependent package name \combined-assets-i D:\AndroidSDK\sdk\platforms\android-16\android.jar;
Add the main module's res in, so that the generated dependency R file is the same as the main module, which contains all the resources, not just the resources that depend on the package. In this way, there will be no conflicting behavior.
But this is just a matter of solving at the command level, and MAVEN packaging uses Android-maven-plugin (Com.jayway.maven.plugins.android.generation2), which is executed by the plugin. But fortunately this plugin is open source, can be found on GitHub. Find this open source project on GitHub, find the corresponding part of the code and found that the build command is correct, the original has been a master in mid-May to solve the problem ...
It turns out that my plugin version is behind, go to the central warehouse to see the latest version of Android-maven-plugin is 3.9.0-RC.3, this version has been resolved the bug. Update the packaging test, everything is OK.
Although the final version is only updated to solve the problem, but also learned a lot of things, familiar with the packaging process, but also interested to see the corresponding part of GitHub code,