I'm giving it up for now. I found a way how to fix my old setup, so it now works on 4.0, 4.1 and even on 4.2. I don't need to put it on a different folder, it simply uses a standard location like build\outputs\apk\full\release\ and there it creates unsigned and signed APK like this:
gradle-plugin-build-sample-1.9.0-alpha2-SNAPSHOT-374-768e633-m-app,full,release,unsigned.apk gradle-plugin-build-sample-1.9.0-alpha2-SNAPSHOT-374-768e633-m-app,full,release.apk And it works for AAB and test apk. Dne pátek 26. června 2020 v 18:00:41 UTC+2 uživatel Jerome Dochez napsal: > you need to continue doing that, I just filed a bug : > > https://b.corp.google.com/issues/159993210 > > On Thu, Jun 25, 2020 at 11:20 PM Tomáš Procházka <tomas.p...@gmail.com> > wrote: > >> And is there a way how to force also 'assemble' task to create signed APK >> already? >> >> Currently, I'm doing this >> >> variant.assembleProvider.configure { >> it.dependsOn(signTask) >> } >> >> >> >> Dne čtvrtek 25. června 2020 v 22:33:28 UTC+2 uživatel Jerome Dochez >> napsal: >> >>> all tasks that consume APK will automatically be wired to your output >>> because your task became the final provider for the public APK type, so >>> install will use *your* signed APK without you having to do anything. >>> >>> you must use a different output folder, if this does not work with some >>> of our tasks then it's a bug and we will look into it urgently. >>> >>> >>> On Thu, Jun 25, 2020 at 12:49 PM Tomáš Procházka <tomas.p...@gmail.com> >>> wrote: >>> >>>> I think that *onVariantProperties* is called only when the variant >>>> is actually created. >>>> In my previous implementation, I'm using >>>> *project.android.applicationVariants.each* >>>> which works even after evaluation. >>>> >>>> And I need to replace the APK, I cannot put it to a different folder, >>>> because I'm not at the end of the chain. There is mostly plugin to publish >>>> APK to play store or to the internal maven artifactory. Or just install >>>> task which uploads it to device, or connectedDeviceTest which all needs to >>>> use properly signed APK in the same way how internal sign mechanism works. >>>> Also directly from Android studio must be still possible to run/debug >>>> release build directly. So everything must be really transparent. >>>> >>>> But currently, I stuck that my Task is never called. I trying to find >>>> out why examples work and mine not. >>>> >>>> Dne čtvrtek 25. června 2020 v 17:29:29 UTC+2 uživatel Jerome Dochez >>>> napsal: >>>> >>>>> yes it will not necessarily work if you call from the afterEvaluate >>>>> because that's where we hook up the AGP in Gradle and the order matters >>>>> (you are coming after us) >>>>> >>>>> you need to find a way to move your code out. >>>>> btw, do NOT use the same folder for input and output, one is to read >>>>> the unsigned APK, the other is to write out the signed, you should not >>>>> use >>>>> the same folder. >>>>> >>>>> On Thu, Jun 25, 2020 at 7:04 AM Tomáš Procházka <tomas.p...@gmail.com> >>>>> wrote: >>>>> >>>>>> But it looks that not understanding this API is smaller problem. >>>>>> I found that *android.onVariantProperties* is never called when I >>>>>> call it inside of *project.afterEvaluate* >>>>>> I'm doing it because I have own configuration extension inside of my >>>>>> plugin. >>>>>> So setup looks like >>>>>> >>>>>> apply ..... >>>>>> >>>>>> myConfigExtension { >>>>>> mysetup >>>>>> } >>>>>> >>>>>> And in the time od signing configuration I need to know about values >>>>>> in myConfigExtension >>>>>> >>>>>> Without it it at least run the first println, but it never call >>>>>> RemoteSignTask >>>>>> >>>>>> android.onVariantProperties { >>>>>> ApplicationVariantProperties v -> >>>>>> >>>>>> println 'xxxxx' + "remoteSign" + v.name.capitalize() >>>>>> + "Apk" >>>>>> >>>>>> TaskProvider singingTaskProvider = >>>>>> project.tasks.register( >>>>>> "remoteSign" + v.name.capitalize() + "Apk", >>>>>> RemoteSignTask) >>>>>> >>>>>> //def transformationRequest = >>>>>> v.artifacts.use(singingTaskProvider) >>>>>> .wiredWithDirectories( >>>>>> { it.apkFolder }, { it.apkFolder } >>>>>> ) >>>>>> .toTransformMany(ArtifactType.APK.INSTANCE) >>>>>> >>>>>> >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> Dne čtvrtek 25. června 2020 v 2:23:37 UTC+2 uživatel Jerome Dochez >>>>>> napsal: >>>>>> >>>>>>> we do not have such a thing as an unsigned APK (even internally >>>>>>> because we package and sign simultaneously). >>>>>>> what you need to do is disable signing alltogether for your app by >>>>>>> turning off v1 and v2 signing through the DSL, then your APK would be >>>>>>> unsigned... >>>>>>> >>>>>>> On Wed, Jun 24, 2020 at 1:35 PM Tomáš Procházka < >>>>>>> tomas.p...@gmail.com> wrote: >>>>>>> >>>>>>>> I'm sorry, but this API doesn't make sense at all for me. >>>>>>>> This WorkerEnabledTransformation example just takes the final APK >>>>>>>> and copy it somewhere else. >>>>>>>> But I need to replace the default sign mechanism provided by the >>>>>>>> Android plugin and nobody else (a different plugin) should know about. >>>>>>>> So technically I need to tell that my task needs unsigned APK on >>>>>>>> input and final APK on output. >>>>>>>> If I understand correctly this talk >>>>>>>> https://youtu.be/OTANozHzgPc?t=1023 >>>>>>>> With new API I should not care about the actual task which is >>>>>>>> responsible o signing. I should care just about input and output >>>>>>>> artifacts. >>>>>>>> So I should tell that I have a task that can handle unsigned APK on >>>>>>>> the input and can sign it. And I want to replace any other task, which >>>>>>>> would like do the same. >>>>>>>> The replace mechanism described in the talk at >>>>>>>> https://youtu.be/OTANozHzgPc?t=1023 gives much more sense for me. >>>>>>>> I would expect something like this: >>>>>>>> >>>>>>>> artifact.use(signTaskProducer).toCreate(ArtifactType.APK.INSTANCE).from(ArtifactType.UNSIGNED_APK.INSTANCE) >>>>>>>> >>>>>>>> >>>>>>>> Dne středa 24. června 2020 v 21:54:32 UTC+2 uživatel Jerome Dochez >>>>>>>> napsal: >>>>>>>> >>>>>>>>> toCreate API is used to create an artifact from its input, so here >>>>>>>>> that would mean creating the APK file from dex, merged manifests, >>>>>>>>> resources, etc... >>>>>>>>> >>>>>>>>> what you want is transform : >>>>>>>>> >>>>>>>>> val transformationRequest = artifacts.use(singingTaskProvider) >>>>>>>>> .wiredWithDirectories( >>>>>>>>> SigningTask::inputApkFolder, >>>>>>>>> SingingTas::outputAPKFolder) >>>>>>>>> .toTransformMany(ArtifactType.APK) >>>>>>>>> >>>>>>>>> >>>>>>>>> look at WorkerEnabledTransformation, it should be very similar >>>>>>>>> except you copy and sign the files instead of just copying >>>>>>>>> >>>>>>>>> you can do AAB but I need to add test APK which right now are not >>>>>>>>> available through the public artifact types. >>>>>>>>> >>>>>>>>> On Wed, Jun 24, 2020 at 8:32 AM Tomáš Procházka < >>>>>>>>> tomas.p...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I'm still not sure how to use it exactly, can you help a little >>>>>>>>>> bit. Currently, I have this code: >>>>>>>>>> >>>>>>>>>> android.onVariantProperties { >>>>>>>>>> ApplicationVariantProperties v -> >>>>>>>>>> TaskProvider signTaskProducer = tasks.register( >>>>>>>>>> "remoteSign" + variant.name.capitalize() >>>>>>>>>> + "Apk", >>>>>>>>>> RemoteSignTask) >>>>>>>>>> >>>>>>>>>> v.artifacts.use(signTaskProducer) >>>>>>>>>> .wiredWith( ? ) >>>>>>>>>> .toCreate(ArtifactType.APK.INSTANCE) >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> But I'm not sure what is responsible for produce unsigned task. >>>>>>>>>> And I need to sign APK, AAB and also test APK >>>>>>>>>> And inside of RemoteSignTask task I need to get location of all >>>>>>>>>> files which should be fixed. >>>>>>>>>> >>>>>>>>>> My original code working until 4.0.0 was looking like this: >>>>>>>>>> >>>>>>>>>> project.android.applicationVariants.each { >>>>>>>>>> ApplicationVariant variant -> >>>>>>>>>> if (!isReleaseBuildType(variant)) { >>>>>>>>>> project.logger.info("Skipping signing, '$ >>>>>>>>>> variant.name' is not release.") >>>>>>>>>> return >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> variant.outputs.all { ApkVariantOutput output -> >>>>>>>>>> // hack to keep proper final name also when >>>>>>>>>> assemble task will be skipped >>>>>>>>>> output.outputFileName = >>>>>>>>>> RemoteSignTask.renameToSignedName(output.outputFileName) >>>>>>>>>> } >>>>>>>>>> variant.setOutputsAreSigned(true) >>>>>>>>>> >>>>>>>>>> // Regular APK signing >>>>>>>>>> def apk = >>>>>>>>>> variant.getFinalArtifact(InternalArtifactType.APK.INSTANCE) >>>>>>>>>> InternalArtifactType.APK.INSTANCE >>>>>>>>>> def signTask = project.tasks.register( >>>>>>>>>> "remoteSign" + variant.name.capitalize() >>>>>>>>>> + "Apk", RemoteSignTask, >>>>>>>>>> new RemoteSignTask.ConfigAction(variant, >>>>>>>>>> apk)) >>>>>>>>>> >>>>>>>>>> // FIXME: IT should be completely outside this >>>>>>>>>> task, but it is not possible now >>>>>>>>>> def folderManifestTaskForApk = >>>>>>>>>> project.tasks.register( >>>>>>>>>> "folderManifest" + >>>>>>>>>> variant.name.capitalize() + "Apk", FolderManifestTask, >>>>>>>>>> new >>>>>>>>>> FolderManifestTask.ConfigAction(variant, apk)) >>>>>>>>>> >>>>>>>>>> variant.assembleProvider.configure { >>>>>>>>>> it.dependsOn(signTask) >>>>>>>>>> it.dependsOn(folderManifestTaskForApk) >>>>>>>>>> } >>>>>>>>>> signTask.configure { >>>>>>>>>> folderManifestTaskForApk.get().dependsOn(it) >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> // App bundle signing >>>>>>>>>> def bundle = >>>>>>>>>> variant.getFinalArtifact(InternalArtifactType.BUNDLE.INSTANCE) >>>>>>>>>> def bundleSignTask = project.tasks.register( >>>>>>>>>> "remoteSign" + variant.name.capitalize() >>>>>>>>>> + "Bundle", RemoteSignTask, >>>>>>>>>> new RemoteSignTask.ConfigAction(variant, >>>>>>>>>> bundle)) >>>>>>>>>> >>>>>>>>>> // FIXME: IT should be completely outside this >>>>>>>>>> tak, but it is not possible now >>>>>>>>>> def folderManifestTaskForAAB = >>>>>>>>>> project.tasks.register( >>>>>>>>>> "folderManifest" + >>>>>>>>>> variant.name.capitalize() + "Bundle", FolderManifestTask, >>>>>>>>>> new >>>>>>>>>> FolderManifestTask.ConfigAction(variant, bundle)) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> variant.getVariantData().getTaskContainer().bundleTask.configure { >>>>>>>>>> it.dependsOn(bundleSignTask) >>>>>>>>>> it.dependsOn(folderManifestTaskForAAB) >>>>>>>>>> } >>>>>>>>>> bundleSignTask.configure { >>>>>>>>>> folderManifestTaskForAAB.get().dependsOn(it) >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> if (variant.testVariant != null ) { >>>>>>>>>> // Test APK signing >>>>>>>>>> def testApk = >>>>>>>>>> variant.testVariant.getFinalArtifact(InternalArtifactType.APK.INSTANCE) >>>>>>>>>> def testSignTask = project.tasks.register( >>>>>>>>>> "remoteSign" + >>>>>>>>>> variant.name.capitalize() + "AndroidTest", RemoteSignTask, >>>>>>>>>> new >>>>>>>>>> RemoteSignTask.ConfigAction(variant.testVariant, testApk)) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> variant.testVariant.assembleProvider.configure { >>>>>>>>>> dependsOn(testSignTask) >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> variant.testVariant.connectedInstrumentTestProvider.configure { >>>>>>>>>> dependsOn(testSignTask) >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Dne středa 24. června 2020 v 7:00:11 UTC+2 uživatel Jerome Dochez >>>>>>>>>> napsal: >>>>>>>>>> >>>>>>>>>>> yes, just replace the artifact type with APK. >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 23, 2020 at 3:12 PM Tomáš Procházka < >>>>>>>>>>> tomas.p...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> But it looks that replace Sign mechanism should be done in the >>>>>>>>>>>> same way as replace manifest merger which is shown here >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/android/gradle-recipes/blob/master/Groovy/manifestReplacementTest/app/build.gradle >>>>>>>>>>>> >>>>>>>>>>>> right? >>>>>>>>>>>> >>>>>>>>>>>> Dne čtvrtek 11. června 2020 v 20:33:23 UTC+2 uživatel Tomáš >>>>>>>>>>>> Procházka napsal: >>>>>>>>>>>> >>>>>>>>>>>>> This is super useful https://github.com/android/gradle-recipes >>>>>>>>>>>>> >>>>>>>>>>>>> Would be possible to add there how to >>>>>>>>>>>>> >>>>>>>>>>>>> - rename output apk/aab to a custom name >>>>>>>>>>>>> - write custom apk/aab signer >>>>>>>>>>>>> >>>>>>>>>>>>> Please. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Dne čtvrtek 21. května 2020 8:56:13 UTC+2 Tomáš Procházka >>>>>>>>>>>>> napsal(a): >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi. Thanks. An example would be really great. So in 3.6 is >>>>>>>>>>>>>> the only possible way to found last one *task *which >>>>>>>>>>>>>> produces APK and do my stuff in the doLast {} closure, right? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Dne pátek 6. března 2020 19:02:36 UTC+1 Jerome Dochez >>>>>>>>>>>>>> napsal(a): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> it's not possible to do this in 3.6. We are hoping to >>>>>>>>>>>>>>> deliver most of this during the 4.1 and 4.2 releases. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> for your second question, you probably will just need to get >>>>>>>>>>>>>>> the PublicArtifactType.APK artifacts and have a task that >>>>>>>>>>>>>>> depend on them. >>>>>>>>>>>>>>> this should actually already work in 4.0 with relatively (!) >>>>>>>>>>>>>>> stable APIs, I can slap an example next week if you are >>>>>>>>>>>>>>> interested >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Mar 6, 2020 at 8:50 AM Tomáš Procházka < >>>>>>>>>>>>>>> tomas.p...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If. Understand it correctly. >>>>>>>>>>>>>>>> New variant API is mentioned here >>>>>>>>>>>>>>>> https://youtu.be/OTANozHzgPc?t=995 >>>>>>>>>>>>>>>> It is currently possible with 3.6.0 ? >>>>>>>>>>>>>>>> Is there some more advanced article or video about this API >>>>>>>>>>>>>>>> or documentation somewhere? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For example, I'm not sure if I should use *replace *or >>>>>>>>>>>>>>>> *transform* to replace the default sign mechanism? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And I also need one new thing. I would like to count hash >>>>>>>>>>>>>>>> of all APK and AAB produced during the build. >>>>>>>>>>>>>>>> So I maybe can use *register, *but I don't want to force >>>>>>>>>>>>>>>> production of APK or AAB. I want just wait when it happens so >>>>>>>>>>>>>>>> when user >>>>>>>>>>>>>>>> call bundle or assemble I need to know about every apk or >>>>>>>>>>>>>>>> bundle that will >>>>>>>>>>>>>>>> be produced. >>>>>>>>>>>>>>>> It is possible? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Dne pondělí 21. října 2019 18:15:13 UTC+2 Jerome Dochez >>>>>>>>>>>>>>>> napsal(a): >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> yes there will be : >>>>>>>>>>>>>>>>> 1. disable all signing in the DSL (v1 and v2) >>>>>>>>>>>>>>>>> 2. obtain the built APK with new variant API >>>>>>>>>>>>>>>>> 3. sign them. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sun, Oct 20, 2019 at 12:16 PM Tomáš Procházka < >>>>>>>>>>>>>>>>> tomas.p...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Jerome. Thanks. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Btw. Best would be if there will be a direct way how to >>>>>>>>>>>>>>>>>> replace default sign mechanism, just by implementing some >>>>>>>>>>>>>>>>>> interface ;-) >>>>>>>>>>>>>>>>>> Without modifying tasks and dependencies between them. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Dne pátek 18. října 2019 19:43:29 UTC+2 Jerome Dochez >>>>>>>>>>>>>>>>>> napsal(a): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Tomas >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> we are getting closer to provide a new API that will be >>>>>>>>>>>>>>>>>>> stable so you want have to handle such changes. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Oct 15, 2019 at 7:26 AM Tomáš Procházka < >>>>>>>>>>>>>>>>>>> tomas.p...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I will reply myself. The correct form of >>>>>>>>>>>>>>>>>>>> getFinalArtifact parameter is InternalArtifactType.APK. >>>>>>>>>>>>>>>>>>>> INSTANCE >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Dne neděle 13. října 2019 23:56:14 UTC+2 Tomáš >>>>>>>>>>>>>>>>>>>> Procházka napsal(a): >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Please, I need help again. >>>>>>>>>>>>>>>>>>>>> My custom sign mechanism is again broken in plugin >>>>>>>>>>>>>>>>>>>>> 4.6.0. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> InstallableVariantImpl.getFinalArtifact now return a >>>>>>>>>>>>>>>>>>>>> different value, insead of BuildableArtifact it is >>>>>>>>>>>>>>>>>>>>> there now Provider<FileCollection>. >>>>>>>>>>>>>>>>>>>>> It is also necessary to call it in this way from >>>>>>>>>>>>>>>>>>>>> Groovy now variant.getFinalArtifact(new >>>>>>>>>>>>>>>>>>>>> InternalArtifactType.APK()) >>>>>>>>>>>>>>>>>>>>> I get Provider instance correctly, but the collection >>>>>>>>>>>>>>>>>>>>> is always empty. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> @TaskAction >>>>>>>>>>>>>>>>>>>>> void sign() { >>>>>>>>>>>>>>>>>>>>> println '>>>>>>>>>>>>>> A2 sign task: ' + >>>>>>>>>>>>>>>>>>>>> inputFiles.get().files.size() >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> This is always 0. >>>>>>>>>>>>>>>>>>>>> I'm calling get() in my task, which is registered in >>>>>>>>>>>>>>>>>>>>> this way >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> variant.assembleProvider.configure { >>>>>>>>>>>>>>>>>>>>> dependsOn(signTask) >>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Dne čtvrtek 17. ledna 2019 12:40:06 UTC+1 Tomáš >>>>>>>>>>>>>>>>>>>>> Procházka napsal(a): >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> So, here is my final solution: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> https://gist.github.com/tprochazka/457c7eebd044c0210dcc8ba49301cda9 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> It's quite complicated. I'm using not public API, but >>>>>>>>>>>>>>>>>>>>>> it looks that it works currently. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I created a new feature request to make it possible >>>>>>>>>>>>>>>>>>>>>> in some easier way >>>>>>>>>>>>>>>>>>>>>> https://issuetracker.google.com/issues/122883577 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> adt...@googlegroups.com. >>>>>>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>>>>>> https://groups.google.com/d/msgid/adt-dev/55e89d8f-5216-4ff5-b2e0-765f80025438%40googlegroups.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/adt-dev/55e89d8f-5216-4ff5-b2e0-765f80025438%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> 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 adt...@googlegroups.com. >>>>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>>>> https://groups.google.com/d/msgid/adt-dev/cae178f3-d127-4803-9062-8bacbeebd250%40googlegroups.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/adt-dev/cae178f3-d127-4803-9062-8bacbeebd250%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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 adt...@googlegroups.com. >>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>> https://groups.google.com/d/msgid/adt-dev/76a13511-fa1b-4737-9c20-8f5425867438%40googlegroups.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/adt-dev/76a13511-fa1b-4737-9c20-8f5425867438%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>> 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 adt-dev+u...@googlegroups.com. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/d/msgid/adt-dev/0d56caca-91f4-40d7-8069-055051881948n%40googlegroups.com >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/d/msgid/adt-dev/0d56caca-91f4-40d7-8069-055051881948n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> 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 adt-dev+u...@googlegroups.com. >>>>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/adt-dev/2bb989c1-97d1-4d7c-9603-53eaf0ce66dcn%40googlegroups.com >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/d/msgid/adt-dev/2bb989c1-97d1-4d7c-9603-53eaf0ce66dcn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>>>> 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 adt-dev+u...@googlegroups.com. >>>>>>>> >>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/adt-dev/1d22642d-3d74-456e-af8b-8e17eda0d055n%40googlegroups.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/adt-dev/1d22642d-3d74-456e-af8b-8e17eda0d055n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>> 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 adt-dev+u...@googlegroups.com. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/adt-dev/4113877e-5987-4d9c-bc5e-d008fdc14e6fn%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/adt-dev/4113877e-5987-4d9c-bc5e-d008fdc14e6fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> 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 adt-dev+u...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/adt-dev/2367a793-57b5-40c9-a4c8-590e9726df75n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/adt-dev/2367a793-57b5-40c9-a4c8-590e9726df75n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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 adt-dev+u...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/adt-dev/3f28e3c0-1f54-4fec-8ee6-0a761b9dec3cn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/adt-dev/3f28e3c0-1f54-4fec-8ee6-0a761b9dec3cn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 adt-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/adt-dev/36fac0b6-4050-4911-8296-b2fd6ad46f31n%40googlegroups.com.
