Android SDK Code Coverage Generation Issue

[CommunityUser]

After integrating the AppDynamics Android SDK, we're no longer able to generate code coverage reports when doing a build with the command line below:

./gradlew clean build connectedAndroidTest createDebugCoverageReport

Running that command-line results in the error below.  I confirmed that all our tests are passing, and if I remove AppDynamics entirely, everything works properly again.

:app:connectedAndroidTest

03:15:41 E/Device: Error during Sync: Remote object doesn't exist!

null

java.io.IOException: Failed to pull /data/data/<app_package>/coverage.ec from device

at com.android.builder.testing.ConnectedDevice.pullFile(ConnectedDevice.java:114)

at com.android.builder.internal.testing.SimpleTestCallable.call(SimpleTestCallable.java:185)

at com.android.builder.internal.testing.SimpleTestCallable.call(SimpleTestCallable.java:48)

at java.util.concurrent.FutureTask.run(FutureTask.java:262)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

at java.util.concurrent.FutureTask.run(FutureTask.java:262)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:745)

Caused by: com.android.ddmlib.SyncException: Remote object doesn't exist!

at com.android.ddmlib.SyncService.pullFile(SyncService.java:314)

at com.android.ddmlib.Device.pullFile(Device.java:874)

at com.android.builder.testing.ConnectedDevice.pullFile(ConnectedDevice.java:107)

... 8 more

:app:connectedAndroidTest FAILED

Our build uses the Android 21.0.2 build tools, Gradle 2.1, and the Android Tools Gradle Plugin version 0.13.2.  To reproduce, the following are needed: an Android project which has tests, an Android virtual device emulator running at the time when the build is executed, and "testCoverageEnabled true" added to the "android { buildTypes { debug {" section of the app's build.gradle file.

Are there any recommendations to work around this so that we can continue to have code coverage reports?

[Arun_Dasetty]

Hi Eric,

While Mobile team got chance to look into this issue, see if the below information helps:

- from exception message it looks like the env. variable app_package is not retrieved and check the file <app_package>/coverage.ec exists or not 

Few related forum links:

- http://stackoverflow.com/questions/14301645/java-app-package-pathname-variable-not-working

- https://code.google.com/p/android/issues/detail?id=69174

- http://stackoverflow.com/questions/23396985/jacoco-with-gradle-0-10-0-remote-object-doesnt-exist

Please ignore and wait for Android/Mobile team to respond if the above information does not help or not related here.

Regards,

Arun

[CommunityUser]

Thanks for looking into it!

Just to be clear, "<app_package>" was a string that I added to replace our real app package name.  It wasn't in the actual output (the actual output had our "com.xxxx.yyyyy" app package string there).  The coverage.ec file was not generated when using AppDynamics.

Also, a couple of the stackoverflow articles you link to are about issues which existed in previous versions of the Android build tools, but are fixed in the current version.  We are able to successfully generate the coverage.ec file and code coverage reports when no AppDynamics injection is happening as part of the build.

[Arun_Dasetty]

Hi Eric,

Can you please check if the followig information from our Dev team helps here:

"Our eum's gradle plugin introduces indirect dependency on a particular version of google's build plugin. Please confirm whether you have followed the instructions mentioned in the documentation. If you look in the documentation here: 

https://docs.appdynamics.com/display/PRO39/Instrument+an+Android+Application

under the gradle example, you should see something like this:

configurations.classpath.resolutionStrategy.force('com.android.tools.build:gradle:0.8.3')

Where '0.8.3' should be replaced with the plugin version of yours . We suspect, you are seeing this issue because our gradle plugin is introducing dependency on a older version of android's gradle plugin. 

Can you please check whether your build.gradle file is configured properly and let us know how it goes. "

Regards,

Arun

[CommunityUser]

Sorry for the late response.

I do have the following line in my build.gradle file and I'm still able to reproduce the issue:

configurations.classpath.resolutionStrategy.force('com.android.tools.build:gradle:0.13.2')

In the build.gradle file, is there a way to disable injection for the debug build (so that injection will only happen for the release build)?  I realize that will result in AppDynamics not doing any monitoring for the debug build, but that's fine since the debug build would only be used for testing anyways.  Please let me know.

[Arun_Dasetty]

Hi Eric,

Please find our response from our Dev team regarding your query:

"Unfortunately our plugin automatically runs for both debug and release builds. I don't see an easy way around it without providing a custom build for the customer. 

Besides the customer's response does not mention under which element 'configurations.classpath.resolutionStrategy.force('com.android.tools.build:gradle:0.13.2')" was applied. It has to be inside the 'buildscript' element."

Regards,

Arun

[CommunityUser]

Thanks Arun.

Just to confirm, we do have the configurations.classpath.resolutionStrategy.force(...) in the "buildscript" element.

Would it be possible to have the ability to disable injection for particular build types in the next version of the Android plugin?  Or alternately, a fix for the code coverage generation issue when injection is enabled?

[Arun_Dasetty]

Hi Eric,

We understood that you have mentioned as per syntax at doc section, let us know if any disconnect:

https://docs.appdynamics.com/display/PRO39/Instrument+an+Android+Application#InstrumentanAndroidAppl... .

We appreciate your pointers on product enhancement/customization. Can you please help us raise feature request at help.appdynamics.com Or send email with feature requirement to help/@appdynamics.com for better tracking of possibilities of the request ?

Regards,

Arun