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 <[email protected]> > 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 <[email protected]> >>> 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 <[email protected]> >>>>>>> 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 < >>>>>>>>> [email protected]> 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 < >>>>>>>>>>> [email protected]> 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 [email protected]. >>>>>>>>>>>> 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 [email protected]. >>>>>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>> 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 [email protected]. >> > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/adt-dev/1d22642d-3d74-456e-af8b-8e17eda0d055n%40googlegroups.com.
