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