EMMA Code Coverage Issues

[Tyler Shopshire]

In the past I have built an AOSP 4.2.2 instrumented code coverage build. Using Tradefederation, I set up my test harness to automatically collect coverage data and the use emma to generate a coverage report. However, I have recently attempted to build a code coverage build and after going through my test harness the numbers contained in the code coverage report are obviously incorrect. I have traced this back to a specific problem.

In the past, .em files (EMMA metadata files) were generated in out/**/APPS/${APP_NAME}_intermediates/coverage.em and also out/**/JAVA_LIBRARIES/${package name}_intermediates/coverage.em. However, currently the build system is only generating metadata files in paths containing "APPS", and no metadata is being placed in directories containing "JAVA_LIBRARIES". There are certain commits I can point to that change the Android build system, but I don't want to waste any people's time looking at the incorrect files. I'm wondering if anyone has an understanding of the build system when attempting to build a full instrumented build, and how this problem could have arisen.

If you would like more information, I am glad to help.

Thanks.

[Ying Wang]

No, emma_mata.zip still contains both APP and JAVA_LIBRARY coverage.em files.

To run a full emma build, run:

$ rm -rf out/   # need a clean build

$ make -j64 showcommands dist EMMA_INSTRUMENT=true

--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-buildi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tyler Shopshire]

I believe the problem actually exists in build/core/java_library.mk. In package.mk there is a check

ifdef EMMA_INSTRUMENT, true

LOCAL_EMMA_INSTRUMENT=true

whereas in java_library.mk

ifdef EMMA_INSTRUMENT, true

# doesn't set LOCAL_EMMA_INSTRUMENT

ifdef LOCAL_EMMA_INSTRUMENT, true

I added LOCAL_EMMA_INSTRUMENT=true in one of my makefiles before building the java library, and the .em files were generate in JAVA_LIBRARIES.

[Tyler Shopshire]

After adding this change, I'm now hitting the limitations of the dex format. I'm going to post a CR to AOSP to fix this bug but now have another problem worth mentioning.

Dex has a restriction of 64k method id's (stored in 16 bit field) This is most likely related to our build system and the patches we have introduced. I believe Emma adds to the overall method count, and wonder if anyone can confirm this? We will most likely break apart some namespaces to another dex file to ensure we are under the limit. Another random question, anyone know if the work to extend this limitation has gained any traction?

[Ying Wang]

On Tue, Aug 6, 2013 at 8:25 PM, Tyler Shopshire <tshop...@gmail.com> wrote:

After adding this change, I'm now hitting the limitations of the dex format. I'm going to post a CR to AOSP to fix this bug but now have another problem worth mentioning.

Hmm, that might be the reason emma is disabled by default on libraries. 

Dex has a restriction of 64k method id's (stored in 16 bit field) This is most likely related to our build system and the patches we have introduced. I believe Emma adds to the overall method count, and wonder if anyone can confirm this? We will most likely break apart some namespaces to another dex file to ensure we are under the limit. Another random question, anyone know if the work to extend this limitation has gained any traction?

Yes, the Dalvik guys are working on it.