Status Update
Comments
l3...@gmail.com <l3...@gmail.com> #2 Restricted+
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
Thanks for reporting this issue. We have passed this to the development team and will update this issue with more information as it becomes available.
sp...@google.com <sp...@google.com> #4
ws...@gmail.com <ws...@gmail.com> #5
sp...@google.com <sp...@google.com> #6
an...@google.com <an...@google.com> #7
wa...@gmail.com <wa...@gmail.com> #8
sp...@google.com <sp...@google.com> #9
What
Feature request
Now resolved. The functionality is back.
Where
Build and device data
- Build Number: google/shiba_beta/shiba:15/BP11.241025.006/12620009:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
- SoC Revision: Zuma B1
Debugging information
Google Play services
com.google.android.gms
Version 244433035 (24.44.33 (260400-694629214))
System App (Updated)
Android System WebView
com.google.android.webview
Version 672310733 (130.0.6723.107)
System App (Updated)
Network operator: Koodo
SIM operator: Koodo
Filed by Android Beta Feedback. Version (Updated): 2.46-betterbug.external_20241023_RC01 (DOGFOOD)
To learn more about our feedback process, please visit
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.