|
ApkSourcesDependency
Pulling Java source code, Android resources and assets, in to your apk project as Maven dependencies.
DeprecationYou should probably use Android Library Projects (ApkLib) instead. ApkSourcesDependency was introduced in Android Maven Plugin long before Google supplied a way to use libraries in Android development. Now that both the official Android tools and Android Maven Plugin support proper Android Library Projects, use will probably want to use that instead: ApkLib IntroductionThis is useful if you develop apk's which share some code, but still have some different content. The purpose is to share identical code through a "common-stuff" project, instead of copy/pasting it between two projects. It might look like this: myapp-common-stuff
- contains common java source, res resources, assets and aidl files. typically all domain objects, business logic, common strings and common UI elements.
- 'mvn install' in this project generates myapp-common-stuff.apksources, which is used by the other specific projects.
myapp-for-phoneA
- depends on myapp-common-stuff.
- contains extra UI elements, and perhaps code, specific to phoneA.
- 'mvn install' in this project generates myapp-for-phoneA.apk, for deployment on phoneA devices.
myapp-for-tabletB
- depends on myapp-common-stuff.
- contains extra UI elements, and perhaps code, specific to tabletB.
- 'mvn install' in this project generates myapp-for-tabletB.apk, for deployment on tabletB devices.Note: It is of course recommended (as far as possible) to keep everything in the same apk and just make it work dynamically on every device. When that's not possible, for example when the functionality and UI differs too much, this kind of dependency setup can be nice to do. Detailsmyapp-common-stuffIn the apk project you wish to make available to other project as sources, declare the pom.xml as: <packaging>apk</packaging> Also, add this to the android-maven-plugin's <configuration> tag: <attachSources>true</attachSources> Then do mvn install in that project. Its source code, res and assets directories will be collected and stored in your local Maven repo. myapp-for-phoneA and myapp-for-tabletBIn the apk projects where you wish to use the src/main/java, res and assets directories of the dependency project, add this to the <dependencies> tag of the pom: <dependency>
<groupId>enter.groupid.here</groupId>
<artifactId>myapp-common-stuff</artifactId>
<type>apksources</type>
</dependency>All projects must be <packaging>apk</packaging>. Note the use of <type>apksources</type> when declaring how you depend on the common source project. When you build these projects, they will pull in the sources from the first project, and include them. A new R.java and new .java files from .aidl files will be built, based on the entire codebase and the entire collection of resources. Overwrite vs. OverlayBe aware of the names you give to res files, for example strings.xml. Make sure they don't collide, because then they will be overwritten when copied on top of each other. Use for example commonStrings.xml in the project with common code and resources, and other specific names in each project. res-overlayIf you don't want a certain resource file to overwrite a dependency resource file with the same name, you can put it in a res-overlay directory instead of the res directory. That way, only the specific XML tags you specify in the overlay resource file, will overwrite those specific xml tags in its dependency resource counterpart. | |
Note that myapp-common-stuff, myapp-for-phoneA, and myapp-for-tabletB must all use the same android package name or things won't work!
Is there a way to use different android package name? I have a 'core' apk with common things, but I want to build to variant applications, with distince android package names. Thoughts?
I have the same problem as @tdsproule. The android app store doesn't let you deploy two different apps with the same package name
Same problem here with the package name
I don't have a thorough enough understanding yet of how package ids affect apksources projects, and the proejcts which depend on them. Now that Google have created the possibility to use Android Library Projects, I think that will be solved as soon as we have time to add support for it in maven-android-plugin too. Tracked as Issue 96 , so "Star" that and you will be kept in the loop.
Do we need a new "apksources" type: couldn't we just use "apk" as the POM packaging string and as the dependency type string for the overlay feature? Otherwise we proliferate all these different terms?
Also the overwrite "problem" is could actually be a feature in some situations. The ability to over-write files such as in the Maven WAR plugin overlay feature is actually a powerful way to overwrite functionality from upstream blobs for customisation.
@ricardo.gladwell Yes, unfortunately for apksources to work, the separate packaging type is needed. An apk is compiled and contains only stuff useful in runtime for a Dalvik VM. What we need with apksources (and now Android Library projects, tracked as Issue 96 ) we need a separate type from apk, so that it can hold the actual Android resources (res) and the java source code.
Hi, I solved package name problem. https://sites.google.com/site/s70487s/android-research/maven in the "How to depend on other Android project" chapter I hope I have been of some assistance.