! Usage examples for Android Maven Plugin

Hi Manfred,

I have added a simple morse flash test class using UI Automator and the new UI Automator goal.

It works, but still, uiautomator.jar should be deployed to maven central.

• added support demo for v4 compatibility library
• updated apidemos to android 10 supplied demos
• a bunch of little name changes for the modules

You will need to install the android jar files with the Maven Android SDK Deployer to get the compatibility libraries and 4.0 android into your maven repo for this to work. I tested this and the complete build is working with a 2.3.3 emulator.

I will add some readme once you got it green on jenkins..

manfred

NB the plugin is NOT WORKING as of this commit.

This commit introduces the AarMavenLifecycleParticipant which is invoked after the project is read but before any Mojos have been executed. It has been suggested by Igor that this is where we need to add the dependent Aar lib classes to the compile classpath. That means we need to extract the libs here and THEN add the Aar classes to the compile classpath. IMHO this is also where we should be adding any apklib sources to the compileSourceRoot too. NB the AarMavenLifecycleParticipant actually works and successfully extracts the libs, nut doesn't add the classes to the compile classpath.

Also introduces the AarMavenLifecycleParticipantPlayground which is a testing ground for altering the compile classpath. It is currently failing because it is not being successfully injected with the

This commit also includes BuildHelper which does all the heavy lifting of extracting the libs into target\unpacked-libs. It was a necessary addition because we need this func in the MavenLifecycleParticipant, and this functionality was originally in ConsumeAarMojo and AbstractAndroidMojo. They both now delegate to the BuildHelper.

Final class is MavenDependencyInjector which is just a copy from Tycho of a class that Igor suggested should how to inject classes into the compile classpath. I have left it there as reference. It should be deleted before release.

What needs to be done is to get AarMavenLifecycleParticipantPlayground to alter the compile classpath. Once that is proven we should push that into the AarMavenLifecycleParticipant and remove AarMavenLifecycleParticipantPlayground. At that point ConsumeAarMojo becomes redundant.

I have also updated the libraryproject samples to provide good coverage across all the use cases we want to support.

Hi Hugo,

Here are a whole bunch of changes that should make the different samples stand more on their own and make things easier to rip out for users and understand.

There is also more documentation and a bunch of clean up things in there.

I am not sure if the current setup works for the release process. Could you have a look or let me know how to test that myself? I will use the examples from my clone for my presentation next week in Toronto at AndroidTO but ultimately I think this sort of approach should make it into the next release.

Let me know if you want me to change anything...

manfred

Small sample of aar. Unfortunately it doesn't work correctly :(

If

<type>aar</type>

is changed for

<type>apklib</type>

it works.

Adds the necessary architectures to also allow build for multiple architectures.

APKLIB support is still sketchy and currenly only supports a single architecture.

Small example showing how to do the screenshot stuff. There are some bug fixes in pull request 105 on the android-maven-plugin that will make this example run much better, so it's worth merging that before running this!

https://github.com/rtyley/android-screenshot-lib#readme

Before you pull this in you have to update the dependencies available on jenkins with the maven android sdk deployer.. pull in whenever convenient and you got that done..

It has zero effect as all child POMs do not inherit and explicitly define the AMP version. And having it there is confusing as you expect changing it to have some effect.

...in and updated the test accordingly, activated test even though it currently fails, this will serve as discussion base in the pull request and the mailing list

The app now looks like this screenshot in my Nexus 5.

Currently this fails so we need to figure out how to get instrumentation tests with Robotium to work again. Here is command line output I get

[INFO] [INFO] --- android-maven-plugin:3.8.3-SNAPSHOT:internal-integration-test (default-internal-integration-test) @ libraryprojects-tests --- [INFO] android.devices parameter not set, using all attached devices [INFO] Device 03dd80410939aa47_LGE_Nexus5 found. [INFO] 03dd80410939aa47_LGE_Nexus5 : Running instrumentation tests in com.jayway.maven.plugins.android.generation2.samples.libraryprojects.mainapp.tests [INFO] 03dd80410939aa47_LGE_Nexus5 : Run started: com.jayway.maven.plugins.android.generation2.samples.libraryprojects.mainapp.tests, 1 tests: [INFO] 03dd80410939aa47_LGE_Nexus5 : Start [1/1]: android.test.suitebuilder.TestSuiteBuilder$FailedToCreateTests#testSuiteConstructionFailed [INFO] 03dd80410939aa47_LGE_Nexus5 : ERROR:android.test.suitebuilder.TestSuiteBuilder$FailedToCreateTests#testSuiteConstructionFailed [INFO] 03dd80410939aa47_LGE_Nexus5 : java.lang.RuntimeException: Exception during suite construction at android.test.suitebuilder.TestSuiteBuilder$FailedToCreateTests.testSuiteConstructionFailed(TestSuiteBuilder.java:238) at java.lang.reflect.Method.invokeNative(Native Method) at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:191) at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:176) at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:554) at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1701) Caused by: java.lang.reflect.InvocationTargetException at java.lang.reflect.Constructor.constructNative(Native Method) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at android.test.suitebuilder.TestMethod.instantiateTest(TestMethod.java:87) at android.test.suitebuilder.TestMethod.createTest(TestMethod.java:73) at android.test.suitebuilder.TestSuiteBuilder.addTest(TestSuiteBuilder.java:262) at android.test.suitebuilder.TestSuiteBuilder.build(TestSuiteBuilder.java:184) at android.test.InstrumentationTestRunner.onCreate(InstrumentationTestRunner.java:379) at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4335) at android.app.ActivityThread.access$1500(ActivityThread.java:135) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1256) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:136) at android.app.ActivityThread.main(ActivityThread.java:5017) at java.lang.reflect.Method.invokeNative(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595) at dalvik.system.NativeStart.main(Native Method) Caused by: java.lang.NoClassDefFoundError: com.jayway.maven.plugins.android.generation2.samples.libraryprojects.mainapp.MainActivity at com.jayway.maven.plugins.android.generation2.samples.libraryprojects.mainapp.MainActivityTest.(MainActivityTest.java:16) ... 18 more

[INFO] 03dd80410939aa47_LGE_Nexus5 : End [1/1]: android.test.suitebuilder.TestSuiteBuilder$FailedToCreateTests#testSuiteConstructionFailed [INFO] 03dd80410939aa47_LGE_Nexus5 : Run ended: 11 ms [ERROR] 03dd80410939aa47_LGE_Nexus5 : FAILURES!!! [INFO] Tests run: 1, Failures: 0, Errors: 1 [INFO] 03dd80410939aa47_LGE_Nexus5 : Report file written to /Volumes/mac-data/dev/github/jayway/maven-android-plugin-samples/libraryprojects/libraryprojects-tests/target/surefire-reports/TEST-03dd80410939aa47_LGE_Nexus5.xml

This pull request adds sample projects to the native directory to demonstrate working with apklibs containing native libraries.

This goes along with my recent pull request to maven-android-plugin of the same title.