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+unsubscr...@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.
