Fixed
Status Update
Comments
l3...@gmail.com <l3...@gmail.com> #2 Restricted+
Restricted+
Comment has been deleted.
aa...@google.com <aa...@google.com>
je...@google.com <je...@google.com>
sp...@google.com <sp...@google.com>
sp...@google.com <sp...@google.com> #3
- I am a User
- No third party launcher using Default pixel launcher
- I cannot for now recreate the bug but will enable screen record and upload when caught
sp...@google.com <sp...@google.com> #4
Thank you for your response.
Once you are able to reproduce this bug, please upload the screen record of the issue.
sp...@google.com <sp...@google.com> #6
Please provide the requested information to proceed further. Unfortunately the issue will be closed within 7 days if there is no further update.
an...@google.com <an...@google.com> #7
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Meerkat | 2024.3.1 Canary 9
- Android Gradle Plugin 8.9.0-alpha09
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
wa...@gmail.com <wa...@gmail.com> #8
Genial
sp...@google.com <sp...@google.com> #9
FYI - for anyone trying this new API, see 8.9.0-rc01
and 8.10.0-alpha03
.
Description
DESCRIBE THE ISSUE IN DETAIL:
We are trying to write a gradle plugin that supports Android. We'd like to create one gradle dependency configuration per sourceset, and then have a resolvable configuration (and gradle tasks) per variant. To do this, we need to know which android sourceSets are used by each variant.
In the old AGP APIs, we could use
variant.sourceSets
, and then use the sourceSet names to find the corresponding dependency configurations.In the new AGP APIs, the source set names are not exposed from variants, so it's hard to determine which configurations should used by each variant. We have to hardcode some naming convention and determine the 'hierarchy' of configurations ourselves.
For example, our gradle plugin might define dependency configurations like
pluginDeps
(the 'main' sourceset),debugPluginDeps
,androidTestPluginDeps
,androidTestDebugPluginDeps
, ... for our users. Then, we would define tasks per variant / testVariant, so fordebug
we might have:myDebugTask
which uses dependencies frompluginDeps
anddebugPluginDeps
(of course, not directly but through a resolvable configuration)myAndroidTestDebugTask
which uses all ofpluginDeps
,debugPluginDeps
,androidTestPluginDeps
,androidTestDebugPluginDeps
, etc.We'd rather be able to use the existing logic in AGP, than have to hardcode all those rules of how configurations are named and used by variants.