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.procha...@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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/adt-dev/CAHSVgSAJsZf9Vd7CdOEqWyjJoFqzJ4NTrXmgXnK%3DGpHOD7QmxA%40mail.gmail.com.

Reply via email to