Hi, I started looking at offering extension points for your need, and realized that the only way to be sure was to have an actual use case of the extension points. We also had a somewhat urgent need for this with an internal team moving to Gradle and nagging me about proper coverage support.
In the end, this it wasn't actually a lot of work after the original investigation, I ended up implementing code coverage (with Jacoco). It's built-in right now though I want to move it out later so that anyone can plugin their own solution if they want to use something else (yes, this would require changes to the test runner). The Jacoco plugin/extension are currently separate (But automatically applied) but the rest isn't, though it shouldn't be too hard to do when we decide to add an API to open it up. The code is here: https://android-review.googlesource.com/#/c/91712 and this will be part of the plugin version 0.10. On Mon, Apr 7, 2014 at 4:18 AM, Carl-Gustaf Harroch <[email protected]>wrote: > Sure, I can push to AOSP. We generally use github for code review > internally and have not pushed to AOSP. > > The deviceAction is mainly used to grab the coverage file prior to the > uninstallation of the APK. The file by default is held within > /data/data/<package>/files/coverage.ec. Given the SimpleTestCallable > uninstalls the app, we need a way to grab data prior to the uninstallation. > Ideally I would have it somewhere generic on the task side. > > The JaCoCo plugin is fully functional and we tested it on a rather large > project with instrumentation and espresso tests. The current JaCoCo plugin > could be pushed into the AOSP code but I could see some reasoning on having > it separated. If you rather have one PR for the JaCoCo instrumentation, I > could do so. > > > PS: to get Android full support to JaCoCo there is a need to change the > default InstrumentationTestRunner.java if one wants to remove deprecated > EMMA coverage ( > http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4.2_r1/android/test/InstrumentationTestRunner.java/#InstrumentationTestRunner.generateCoverageReport%28%29). > Currently JaCoCo wrap that call to get JaCoCo coverage without the need to > change the runner ( > https://github.com/jacoco/jacoco/blob/master/org.jacoco.agent.rt/src/com/vladium/emma/rt/RT.java). > Ideally one would change the runner but that is another task in its own > right. > > On Friday, 4 April 2014 19:09:47 UTC+1, Xavier Ducrohet wrote: > >> I would rather see this been done directly in AOSP than on github and >> then moved to AOSP so that we can keep all the discussion on the same place. >> >> I'm guessing the deviceaction is used by your jacoco plugin? >> >> We're going to work on code coverage very soon, so this is timely, but be >> aware that we're thinking about focusing first on jacoco support (emma >> seems to be mostly abandoned at this point). >> >> We may want to offer hooks for other third party solutions but we'll >> probably want jacoco to be built-in. What's your end goal with your current >> plugin? >> >> >> On Fri, Apr 4, 2014 at 8:52 AM, Carl-Gustaf Harroch <[email protected]>wrote: >> >>> Xavier, I have an initial Pull request available against latest idea33 >>> to provide instrumentaiton options to the plugin. I pushed it to Github to >>> give visibility and discussion: >>> https://github.com/novoda/android-tools-base/pull/2 >>> >>> It does touch on a couple of files and notions (especially the idea of >>> DeviceAction which could be explored further). >>> >>> The actual code coverage is done separately here and is still being >>> worked on: >>> https://github.com/novoda/gradle-android-jacoco-plugin >>> >>> Let me know your thoughts. Happy to push it back into aosp if it meets >>> criteria. >>> >>> >>> On Monday, 17 March 2014 22:24:42 UTC, Xavier Ducrohet wrote: >>> >>>> We haven't started work there. We would definitively accept >>>> contributions. thanks. >>>> >>>> >>>> On Mon, Mar 17, 2014 at 3:19 PM, Carl-Gustaf Harroch <[email protected] >>>> > wrote: >>>> >>>>> I managed to get JaCoCo running within Gradle (preDex, postCompile) >>>>> while running a manual "adb am instrument..." as Exec command. This suits >>>>> my needs but was wondering what the current status is? I could provide a >>>>> patched version of DeviceProviderInstrumentTestTask that would add >>>>> instrumentation functionality as part of the testOptions similar to >>>>> testOptions { coverage: true }. This could be extended to take any >>>>> argument as defined >>>>> here<http://developer.android.com/reference/android/test/InstrumentationTestRunner.html>. >>>>> Is this a work in progress ATM? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "adt-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Xavier Ducrohet >>>> Android SDK Tech Lead >>>> Google Inc. >>>> http://developer.android.com | http://tools.android.com >>>> >>>> Please do not send me questions directly. Thanks! >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "adt-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Xavier Ducrohet >> Android SDK Tech Lead >> Google Inc. >> http://developer.android.com | http://tools.android.com >> >> Please do not send me questions directly. Thanks! >> > > On Friday, 4 April 2014 19:09:47 UTC+1, Xavier Ducrohet wrote: > >> I would rather see this been done directly in AOSP than on github and >> then moved to AOSP so that we can keep all the discussion on the same place. >> >> I'm guessing the deviceaction is used by your jacoco plugin? >> >> We're going to work on code coverage very soon, so this is timely, but be >> aware that we're thinking about focusing first on jacoco support (emma >> seems to be mostly abandoned at this point). >> >> We may want to offer hooks for other third party solutions but we'll >> probably want jacoco to be built-in. What's your end goal with your current >> plugin? >> >> >> On Fri, Apr 4, 2014 at 8:52 AM, Carl-Gustaf Harroch <[email protected]>wrote: >> >>> Xavier, I have an initial Pull request available against latest idea33 >>> to provide instrumentaiton options to the plugin. I pushed it to Github to >>> give visibility and discussion: >>> https://github.com/novoda/android-tools-base/pull/2 >>> >>> It does touch on a couple of files and notions (especially the idea of >>> DeviceAction which could be explored further). >>> >>> The actual code coverage is done separately here and is still being >>> worked on: >>> https://github.com/novoda/gradle-android-jacoco-plugin >>> >>> Let me know your thoughts. Happy to push it back into aosp if it meets >>> criteria. >>> >>> >>> On Monday, 17 March 2014 22:24:42 UTC, Xavier Ducrohet wrote: >>> >>>> We haven't started work there. We would definitively accept >>>> contributions. thanks. >>>> >>>> >>>> On Mon, Mar 17, 2014 at 3:19 PM, Carl-Gustaf Harroch <[email protected] >>>> > wrote: >>>> >>>>> I managed to get JaCoCo running within Gradle (preDex, postCompile) >>>>> while running a manual "adb am instrument..." as Exec command. This suits >>>>> my needs but was wondering what the current status is? I could provide a >>>>> patched version of DeviceProviderInstrumentTestTask that would add >>>>> instrumentation functionality as part of the testOptions similar to >>>>> testOptions { coverage: true }. This could be extended to take any >>>>> argument as defined >>>>> here<http://developer.android.com/reference/android/test/InstrumentationTestRunner.html>. >>>>> Is this a work in progress ATM? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "adt-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Xavier Ducrohet >>>> Android SDK Tech Lead >>>> Google Inc. >>>> http://developer.android.com | http://tools.android.com >>>> >>>> Please do not send me questions directly. Thanks! >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "adt-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Xavier Ducrohet >> Android SDK Tech Lead >> Google Inc. >> http://developer.android.com | http://tools.android.com >> >> Please do not send me questions directly. Thanks! >> > -- > You received this message because you are subscribed to the Google Groups > "adt-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Xavier Ducrohet Android SDK Tech Lead Google Inc. http://developer.android.com | http://tools.android.com Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
