Status Update
Comments
je...@google.com <je...@google.com> #2
Information redacted by Android Beta Feedback.
bi...@google.com <bi...@google.com> #3
Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
je...@google.com <je...@google.com> #4
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
I got the March update but I still haven't 5G.
Debugging information
Servicios de Google Play
com.google.android.gms
Version 240713038 (24.07.13 (190400-607434947))
System App (Updated)
Android System WebView
com.google.android.webview
Version 626106433 (122.0.6261.64)
System App (Updated)
Network operator: Digi.Mobil
SIM operator: Digi.Mobil
Filed by Android Beta Feedback. Version (Updated): 2.40-betterbug.external_20240103_RC06 (DOGFOOD)
To learn more about our feedback process, please visit
bi...@google.com <bi...@google.com> #5
Information redacted by Android Beta Feedback.
bi...@google.com <bi...@google.com> #6
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
I have gotten the April update and I still haven't 5G in my phone. That's disappointing!!
When will be it fixed?
Debugging information
Servicios de Google Play
com.google.android.gms
Version 240914038 (24.09.14 (190400-617895654))
System App (Updated)
Android System WebView
com.google.android.webview
Version 631204033 (123.0.6312.40)
System App (Updated)
Network operator: Digi.Mobil
SIM operator: Digi.Mobil
Filed by Android Beta Feedback. Version (Updated): 2.41-betterbug.external_20240221_RC01 (DOGFOOD)
To learn more about our feedback process, please visit
bi...@google.com <bi...@google.com> #7
Information redacted by Android Beta Feedback.
je...@google.com <je...@google.com> #8
using reflection is not a silver bullet, if the API changes, the reflection calls will do too.
ca...@gmail.com <ca...@gmail.com> #9
ig...@jetbrains.com <ig...@jetbrains.com> #10
We haven't started working on that yet, so there's no details I can share, but I'll try to keep you updated. Just thought you should know.
bi...@google.com <bi...@google.com> #11
Thanks for letting us know! Do you have plan to integrate dokka into kotlin android gradle plugin?
Jerome, do you think we can let kotlin android plugin use variant api to provide the generated docs? (e.g. we create a dummy output and they "replace" it with their output.)
je...@google.com <je...@google.com> #12
we don't need to create a dummy output, we can just declare the artifact type and optionally consume it if it is provided/there.
bi...@google.com <bi...@google.com> #13
Our docs generation task is registered based on our dsl input, so the problem is how to let kotlin plugin know when to generate docs. By checking our dsl?
je...@google.com <je...@google.com> #14
this relates to the work Ivan is trying to do with regard to KGP. I would be better that KGP offers the task and ways to configure it and we, AGP, register the task based on our DSL.
bi...@google.com <bi...@google.com> #15
When we integrated dokka, we were thinking about whether to rely on dokka-core or configure the task from dokk-gradle-plugin. The reason why we didn't choose the dokka-gradle plugin is because the way how they configure tasks and wire up things is quite different from us and there were other issues in their plugin(e.g. config caching)
With KGP, I think it would be better as we basically are on the same page of adopting Gradle APIs and features.
ig...@jetbrains.com <ig...@jetbrains.com> #16
Not that I'm aware of, no.
> I would be better that KGP offers the task and ways to configure it and we, AGP, register the task based on our DSL.
If AGP could use Dokka shipped with KGP that would be great I think. We'll keep this in mind when designing the implementation.
As soon as we have some sort of a rough timeline - I'll let you know. We'll also try to keep you in the loop and try to provide some sort of a preview so that we can integrate and find bugs early on.
au...@google.com <au...@google.com> #17
One thing to consider here is to not add dokka-core directly to the classpath, but instead create a separate configuration/classpath/JVM process and only load it for the documentation task. That way, we will avoid all of the version collisions. AndroidX would also benefit from this as we currently
ga...@google.com <ga...@google.com> #18
This should be fixed in
ey...@gmail.com <ey...@gmail.com> #19
What version of AGP is that?
ig...@jetbrains.com <ig...@jetbrains.com> #21
Hi! Thanks!
Is there any way this can be cherry picked into earlier versions? 7.2, 7.3? Or at least have an updated Dokka in the mean time? 1.4 is quite old and was still in alpha, so some strange bugs do occur, and more and more people keep hitting hard to debug errors as they update.
bi...@google.com <bi...@google.com> #22
I think it is okay to cherry pick to 7.3 but it is too late for 7.2.
bi...@google.com <bi...@google.com> #23
The cherry-pick(ag/18561238) to 7.3 is merged in.
Description
This effort is to resolve the compatibility issue for users who use AGP and dokka gradle plugin at the same time.
Currently, AGP declares
dokka-core
as compile and runtime dependency and thedokka-core
dependency version is bound with AGP. When thedokka-core
dependency version are different between AGP anddokka-gradle-plugin
, the desireddokka-core
classes could possibly not be loaded which causes problems.The recommended workaround for users who use dokka gradle plugin to generate docs is to exclude
dokka-core
from agp dependencies.For referencehttps://github.com/Kotlin/dokka/issues/2415