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
> <javascript:>> 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 <javascript:>.
>> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/adt-dev/e9f0d056-2703-4172-ae1b-3148b33a476e%40googlegroups.com.
