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.
