The APK builder filters these resources and doesn't include them into the apk. This leads to bad behaviour of dependent libraries relying on these resources, for instance service discovery doesn't work.
By specifying this pattern, the android plugin adds these resources to the final apk.

The pattern is relative to META-INF, i.e. one must use

<apkMetaIncludes>
    <metaInclude>services/**</metaInclude>
</apkMetaIncludes>

<apkMetaIncludes>
    <metaInclude>META-INF/services/**</metaInclude>
</apkMetaIncludes>

See also Issue 97

Whether to attach the normal .jar file to the build, so it can be depended on by for example integration-tests which may then access R.java from this project.

Only disable it if you know you won't need it for any integration-tests. Otherwise, leave it enabled.

Whether to attach sources to the build, which can be depended on by other apk projects, for including them in their builds.

Enabling this setting is only required if this project's source code and/or res(ources) will be included in other projects, using the Maven <dependency> tag.

Classifier to add to the artifact generated. If given, the artifact will be an attachment instead.

Allows to detect and extract the duplicate files from embedded jars. In that case, the plugin analyzes the content of all embedded dependencies and checks they are no duplicates inside those dependencies. Indeed, Android does not support duplicates, and all dependencies are inlined in the APK. If duplicates files are found, the resource is kept in the first dependency and removes from others.

Root folder containing native libraries to include in the application package.

The Android NDK to use.

Looks like this:

<ndk>
    <path>/opt/android-ndk-r4</path>
</ndk>

The <path> parameter is optional. The default is the setting of the ANDROID_NDK_HOME environment variable. The parameter can be used to override this setting with a different environment variable like this:

<ndk>
    <path>${env.ANDROID_NDK_HOME}</path>
</ndk>

or just with a hardcoded absolute path. The parameters can also be configured from command-line with parameter -Dandroid.ndk.path.

Rewrite the manifest so that all of its instrumentation components target the given package. This value will be passed on to the aapt parameter --rename-instrumentation-target-package. Look to aapt for more help on this.

A possibly new package name for the application. This value will be passed on to the aapt parameter --rename-manifest-package. Look to aapt for more help on this.

The Android SDK to use.

Looks like this:

<sdk>
    <path>/opt/android-sdk-linux</path>
    <platform>2.1</platform>
</sdk>

The <platform> parameter is optional, and corresponds to the platforms/android-* directories in the Android SDK directory. Default is the latest available version, so you only need to set it if you for example want to use platform 1.5 but also have e.g. 2.2 installed. Has no effect when used on an Android SDK 1.1. The parameter can also be coded as the API level. Therefore valid values are 1.1, 1.5, 1.6, 2.0, 2.01, 2.1, 2.2 and so as well as 3, 4, 5, 6, 7, 8... 16. If a platform/api level is not installed on the machine an error message will be produced.

The <path> parameter is optional. The default is the setting of the ANDROID_HOME environment variable. The parameter can be used to override this setting with a different environment variable like this:

<sdk>
    <path>${env.ANDROID_SDK}</path>
</sdk>

or just with a hard-coded absolute path. The parameters can also be configured from command-line with parameters -Dandroid.sdk.path and -Dandroid.sdk.platform.

How to sign the apk.

Looks like this:

<sign>
    <debug>auto</debug>
</sign>

Valid values for <debug> are:

• true = sign with the debug keystore.
• false = don't sign with the debug keystore.
• both = create a signed as well as an unsigned apk.
• auto (default) = sign with debug keystore, unless another keystore is defined. (Signing with other keystores is not yet implemented. See Issue 2.)

Can also be configured from command-line with parameter -Dandroid.sign.debug.

Additional source directories that contain resources to be packaged into the apk.

These are not source directories, that contain java classes to be compiled. It corresponds to the -df option of the apkbuilder program. It allows you to specify directories, that contain additional resources to be packaged into the apk.

<configuration>
  ...
   <sourceDirectories>
     <sourceDirectory>${project.basedir}/additionals</sourceDirectory>
  </sourceDirectories>
  ...
</configuration>

Whether to undeploy an apk from the device before deploying it.

Only has effect when running mvn android:deploy in an Android application project manually, or when running mvn integration-test (or mvn install) in a project with instrumentation tests.

It is useful to keep this set to true at all times, because if an apk with the same package was previously signed with a different keystore, and deployed to the device, deployment will fail becuase your keystore is different.