Status Update
Comments
to...@gmail.com <to...@gmail.com> #2
Information redacted by Android Beta Feedback.
uc...@google.com <uc...@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.
wa...@gmail.com <wa...@gmail.com> #4
to...@gmail.com <to...@gmail.com> #5
Thank you for reporting this issue. We have a fix rolling out in an upcoming release.
pr...@gmail.com <pr...@gmail.com> #6
[Deleted User] <[Deleted User]> #7
ss...@gmail.com <ss...@gmail.com> #8
Because of the inter-dependencies, there is no way to Proguard the entire project at once. If we proguard each module individually, then we are getting class not found errors at runtime for some classes.
ss...@gmail.com <ss...@gmail.com> #9
da...@capitalone.com <da...@capitalone.com> #10
xa...@google.com <xa...@google.com> #11
wa...@gmail.com <wa...@gmail.com> #12
ma...@gmail.com <ma...@gmail.com> #13
pom.withXml {
def dependenciesNode = asNode().appendNode('dependencies')
configurations.implementation.allDependencies.each {
def dependencyNode = dependenciesNode.appendNode('dependency')
dependencyNode.appendNode('groupId', it.group)
dependencyNode.appendNode('artifactId',
if(it.group == 'com.mattruno.android') {
dependencyNode.appendNode('version', rootProject.localVersion())
} else {
dependencyNode.appendNode('version', it.version)
}
}
}
The trick here is that I had to "manually" configure the versions of the POMs based on the version from my project. By overwriting everything this way, I was able to get it to work.
localVersion() is...
def localVersion() {
isSnapshot() == "true" ? "${rootProject.gitLastTag()}-SNAPSHOT" : "${rootProject.gitLastTagWithCommitCount()}-${rootProject.gitSha(8)}"
}
ma...@gmail.com <ma...@gmail.com> #14
pom.withXml {
def dependenciesNode = asNode().appendNode('dependencies')
configurations.implementation.allDependencies.each {
def dependencyNode = dependenciesNode.appendNode('dependency')
dependencyNode.appendNode('groupId', it.group)
dependencyNode.appendNode('artifactId',
if(it.group == 'com.mattruno.android') {
dependencyNode.appendNode('version', rootProject.localVersion())
} else {
dependencyNode.appendNode('version', it.version)
}
}
}
The trick here is that I had to "manually" configure the versions of the POMs based on the version from my project. By overwriting everything this way, I was able to get it to work.
localVersion() is...
def localVersion() {
isSnapshot() == "true" ? "${rootProject.gitLastTag()}-SNAPSHOT" : "${rootProject.gitLastTagWithCommitCount()}-${rootProject.gitSha(8)}"
}
pr...@gmail.com <pr...@gmail.com> #15
ss...@gmail.com <ss...@gmail.com> #16
je...@jedrivisser.com <je...@jedrivisser.com> #17
ss...@gmail.com <ss...@gmail.com> #18
Also, it doesn't allow you to obfuscate the code all at once because the Jar is precompiled.
It does solve the case of zipping multiple precompiled Jars into a single AAR file.
ur...@gmail.com <ur...@gmail.com> #19
ra...@gtempaccount.com <ra...@gtempaccount.com> #20
So we are considering an in-house plugin implementation but we would prefer an official solution, if it is a viable date.
xa...@google.com <xa...@google.com> #21
I would be surprised if it made it into 3.3 at this point :(
ma...@gmail.com <ma...@gmail.com> #22
ka...@waltzapp.com <ka...@waltzapp.com> #23
om...@gmail.com <om...@gmail.com> #24
li...@163.com <li...@163.com> #25
li...@gmail.com <li...@gmail.com> #26
it...@gmail.com <it...@gmail.com> #27
ah...@gmail.com <ah...@gmail.com> #28
[Deleted User] <[Deleted User]> #29
li...@mingchao.com <li...@mingchao.com> #30
sa...@gmail.com <sa...@gmail.com> #31
to...@gmail.com <to...@gmail.com> #32
Pretty much every Android developer who wants to create and offer an SDK and use android library modules to arrange code & architecture will bump into this same issue.
There's already 135 fellows that have starred this issue and there are bound to be lots more out there who would really benefit from this.
fx...@gmail.com <fx...@gmail.com> #33
zh...@gmail.com <zh...@gmail.com> #34
We have to use a self-define merger gradle task which try to copy source code files, jni libraries and more to include submodules into release aar.
I believe many other SDK developers would beneift from this feature.
ma...@gmail.com <ma...@gmail.com> #35
Thanks.
gm...@163.com <gm...@163.com> #36
Thanks.
ss...@gmail.com <ss...@gmail.com> #37
ku...@gmail.com <ku...@gmail.com> #38
Thanks.
to...@gmail.com <to...@gmail.com> #39
First step would be to support bundling of Java code only (i.e. resource file & manifest merging could be skipped and conflicts could just throw a Gradle error/exception). This should be an easy step to support but would nicely allow hierarchical library & SDK code development.
om...@gmail.com <om...@gmail.com> #40
ma...@gmail.com <ma...@gmail.com> #41
We think this feature is very useful to reuse modules across different projects.
ra...@gmail.com <ra...@gmail.com> #42
We really need this feature in out project. Unofficial lib fat-aar does not support new gradle versions.
[Deleted User] <[Deleted User]> #43
dm...@gmail.com <dm...@gmail.com> #44
Our team voted for this feature
bi...@outlook.com <bi...@outlook.com> #45
We need this feature urgently :(
ja...@gmail.com <ja...@gmail.com> #46
We need this feature desperately!
ss...@gmail.com <ss...@gmail.com> #47
For your "bundling kotlin with AAR" use case, you can include the kotlin JAR file in a `libs` directory and this will work. Bundling JARs in an AAR has been supported. You cannot bundle AARs within AARs however. As good practice though, if you don't own the source code, I wouldn't bundle it in and just give the gradle dependencies to the apps that use your SDK. This is important because you will run into issues if your apps also use Kotlin and want to upgrade the version version of Kotlin for an unrelated reason. In this situation, there will be two versions of kotlin at runtime causing errors.
dm...@gmail.com <dm...@gmail.com> #48
[Deleted User] <[Deleted User]> #49
fn...@163.com <fn...@163.com> #50
de...@gmail.com <de...@gmail.com> #51
ep...@gmail.com <ep...@gmail.com> #52
li...@gmail.com <li...@gmail.com> #54
ze...@gmail.com <ze...@gmail.com> #55
yu...@gmail.com <yu...@gmail.com> #56
ma...@gmail.com <ma...@gmail.com> #57
Please, stop polluting this thread by adding "+1", "we need this feature", "Urgently need this", ...
You have a star button on the top left corner that help Google see how important this issue/feature is important. So ensure the star is enabled (yellow) and stop commenting with non-helping message.
Actually, those message will have the complete reverse effect, where people will get sick of receiving email that are unhelping, and will unstar from this thread, decreasing from Google eyes, the importance of this issue.
Btw, thanks to...@indoo.rs for your
Thanks.
dm...@gmail.com <dm...@gmail.com> #58
Fat aar in build tools will be very helpful as it makes no sense to provide details of internal modules division to the clients. You have also no way to provide the list of dependecies if you are not publishing to maven.
Thanks!
nx...@gmail.com <nx...@gmail.com> #59
to...@gmail.com <to...@gmail.com> #60
There's already 215 stars in this issue which means loads of developers really need this feature.
If you start now, this could be implemented before two years has passed from when I filed this issue :)
mi...@gmail.com <mi...@gmail.com> #61
al...@gmail.com <al...@gmail.com> #62
... But I want to show my support for this feature request. Please prioritize this Google (or perhaps Gradle?)! :-)
ra...@gmail.com <ra...@gmail.com> #63
se...@gmail.com <se...@gmail.com> #64
zs...@gmail.com <zs...@gmail.com> #65
lo...@gmail.com <lo...@gmail.com> #66
You better find another solution like fat AAR library, or find another job. There's seemingly no progress on that issue, only people complaining.
[Deleted User] <[Deleted User]> #67
[Deleted User] <[Deleted User]> #68
With this we ended up having our .aar library compiled and bundled with other 4 differents aars (all in the same package).
Hope it will work for some of you without manifest merging strategies and similar.
an...@gmail.com <an...@gmail.com> #69
an...@gmail.com <an...@gmail.com> #70
cl...@gmail.com <cl...@gmail.com> #71
wa...@gmail.com <wa...@gmail.com> #72
co...@gmail.com <co...@gmail.com> #73
Thanks.
xi...@gmail.com <xi...@gmail.com> #74
Thanks
et...@gmail.com <et...@gmail.com> #75
[Deleted User] <[Deleted User]> #76
[Deleted User] <[Deleted User]> #77
dependencies {
//this will not be bundled into the aar and the consumer will download the dependency from maven/jcenter etc... as it is now
implementation "com.thirdparty.dep:lib:1.0.0"
//this will be bundled into our lib and by default all the :my_lib dependencies will be bundled as they are into our aar lib.
//To prevent duplicate conflict with third party open source lib, you can specify a custom repackage behaviour
bundleAar project(":my_lib") {
dep: "com.thirdparty.dep:lib2", repackageAs: "com.mylib.lib2"
}
}
In this way we would prevent conflict and duplicate classes error. The only thing is that the Consumer will have the same class name for different packages and will need to know which one to import each time (and I thinks it's still fine because it is something we already do every day when there is a conflict)
[Deleted User] <[Deleted User]> #78
If you have lots of dependencies, make an (empty) companion library with all your maven dependencies and publish it to online repo. That way there's no need to modify standard tooling and integrating apps need to add just one dependency.
[Deleted User] <[Deleted User]> #79
[Deleted User] <[Deleted User]> #80
ma...@gmail.com <ma...@gmail.com> #81
Is there any update on this.
I also need to bundle multiple AAR files inside my library projects. These aar files are having third party property rights with whom we already have contract signed but we don't want to expose these libraries directly to our clients. Our team is creating wrapper around them and deciding which library need to be called based on the requirement.
Due to FAT aar issue, we facing crashes. Resource files of the embedded AAR files are not getting merged and final aar file don't have all string resources of the embedded AAR files in it.
ra...@gmail.com <ra...@gmail.com> #82
Any updates about this feature request?
It would be awesome to bundle multiple AAR inside our SDK library. Due to we don't want to expose a few libraries dependencies as well inside our SDK library.
ra...@gmail.com <ra...@gmail.com> #83
Looks like kezon already done it to support gradle plugin version 3 above, here's the lin:
But currently, doesn't support publish to maven for adding our dependencies.
no...@gmail.com <no...@gmail.com> #84
da...@gmail.com <da...@gmail.com> #85
ka...@gmail.com <ka...@gmail.com> #86
zs...@plaid.com <zs...@plaid.com> #87
in...@gmail.com <in...@gmail.com> #88
bu...@gmail.com <bu...@gmail.com> #89
mi...@gmail.com <mi...@gmail.com> #90
ad...@gmail.com <ad...@gmail.com> #91
ss...@gmail.com <ss...@gmail.com> #92
There is a Fat AAR plugin that works for most use cases, but isn't an official solution. Check it out here
d....@infotech.team <d....@infotech.team> #93
External implementations will always break with updates and be suboptimal to AGP implementation(if it exeisted), since only people that are working on it know the internals and possible pitfalls and bottlenecks.
For example: how does
[Deleted User] <[Deleted User]> #94
ty...@gmail.com <ty...@gmail.com> #95
aa...@gmail.com <aa...@gmail.com> #96
zs...@plaid.com <zs...@plaid.com> #97
d....@infotech.team <d....@infotech.team> #98
AGP is already heavily granularizes all possible artifacts which are produced for bunlding AAR. Why is it so hard to take the same logic that you already have for apk(and maybe bundles/features) and run it on AAR artifacts?
xu...@gmail.com <xu...@gmail.com> #99
xa...@google.com <xa...@google.com> #100
For AAR there are 2 main difficulties:
- We need to unify the package/application ID of the different AARs, as AAR can only have a single manifest and consumer will create a single R class for it. This means rewriting the compiled code for all the merged libraries (this is not technically challenging but work that needs to happen).
- We need to rewrite the dependencies of the published AAR. If you merge everything this is easy, if you only merge your local modules and keep your external dependencies out this is more complicated. Gradle may offer ways to do this but we have not looked into this yet.
This is not happening in 4.0
rj...@gmail.com <rj...@gmail.com> #101
es...@gmail.com <es...@gmail.com> #102
Any updates?
ro...@gmail.com <ro...@gmail.com> #103
I need this! please!!
va...@gmail.com <va...@gmail.com> #104
er...@gmail.com <er...@gmail.com> #105
ji...@gmail.com <ji...@gmail.com> #106
Google team, please add this feature.
ch...@gmail.com <ch...@gmail.com> #107
oa...@gmail.com <oa...@gmail.com> #108
ka...@gmail.com <ka...@gmail.com> #109
lo...@gmail.com <lo...@gmail.com> #110
lo...@gmail.com <lo...@gmail.com> #111
ye...@gmail.com <ye...@gmail.com> #112
ok...@gmail.com <ok...@gmail.com> #113
I'm aware this is not a trivial issue. I'm just hoping the the priority of this issue would be re-evaluated.
ok...@gmail.com <ok...@gmail.com> #114
Also it is very unintuitive that currently the dependencies work differently depending on whether library is a precompiled AAR dependency or a subproject in the same gradle project.
For example:
I have the dependency chain: 'app' -> 'lib_a' -> 'lib_b'
If all the projects are subprojects in the same gradle project it's enough for app
to say
dependencies {
implementation project(':lib_a')
}
and also resources from lib_b
will be included in the APK.
However, if I use the AAR generated for lib_a
and make an app that uses it in a similar way (e.g. using new module -> import JAR/AAR Package)
From the app point of view the dependency looks exactly the same:
dependencies {
implementation project(':lib_a')
}
but resources from lib_b
are no longer included in the APK as they are not part of the AAR generated by lib_a
ag...@skipit.com <ag...@skipit.com> #115
[Deleted User] <[Deleted User]> #116
ra...@gmail.com <ra...@gmail.com> #117
as...@hoyosintegrity.com <as...@hoyosintegrity.com> #118
p....@criteo.com <p....@criteo.com> #119
ba...@gmail.com <ba...@gmail.com> #120
ao...@gmail.com <ao...@gmail.com> #121
ma...@gmail.com <ma...@gmail.com> #122
oz...@gmail.com <oz...@gmail.com> #123
va...@gmail.com <va...@gmail.com> #124
kr...@gmail.com <kr...@gmail.com> #125
(pity, apparently so many people in need of this super important feature, and no luck)
eg...@gmail.com <eg...@gmail.com> #126
[Deleted User] <[Deleted User]> #127
pr...@gmail.com <pr...@gmail.com> #128
ko...@gmail.com <ko...@gmail.com> #129
se...@demant.com <se...@demant.com> #130
[Deleted User] <[Deleted User]> #131
at...@gmail.com <at...@gmail.com> #132
ma...@gmail.com <ma...@gmail.com> #133
DO NOT WRITE "+1" COMMENTS
It sends emails to hundreds of people. If you want to bring attention to this issue, just click the star icon at the top. If you spam the others with unhelpful comments, they might unstar this issue, making it less likely to ever be resolved.
ga...@google.com <ga...@google.com> #134
At the moment we are talking with Gradle about being able to merge dependencies from multiple projects (that are being bundled), as that part is a problem in the JVM ecosystem as well. Once that is in, we can focus on the Android-specific features (Android resources, manifest etc.).
ne...@gmail.com <ne...@gmail.com> #135
ga...@google.com <ga...@google.com>
[Deleted User] <[Deleted User]> #136
pa...@gmail.com <pa...@gmail.com> #137
ch...@gmail.com <ch...@gmail.com> #138
cm...@google.com <cm...@google.com> #139
Please don't comment with +1 - as
mu...@gmail.com <mu...@gmail.com> #140
ww...@gmail.com <ww...@gmail.com> #141
nope... it sucks but it looks like this P1 priority is not a priority at this point in time.
ve...@gmail.com <ve...@gmail.com> #142
I'm leaving below a "workaround" solution that I put togeter for my particular project.
My main requirement was to ship a closed-source library that was obfuscated as much as possible, except for a very limited set of API methods.
The main idea is to replace each internal module with a corresponding sourceSet in the main library:
sourceSets {
getByName("main") {
java.srcDir("../module1/src/main/java")
java.srcDir("../module2/src/main/java")
}
}
By using a relative path with ..
, I was able to version control module1
and module2
in their own git repository.
Note that this solution has to be expanded if your modules contribute additional dependencies, additional android resources, additional manifest entries, etc.
I realize this is hacky as hell, but it serves my purpose, while we wait for a proper fix...
wa...@bytedance.com <wa...@bytedance.com> #143
[Deleted User] <[Deleted User]> #144
si...@gmail.com <si...@gmail.com> #145
+1
cm...@google.com <cm...@google.com> #146
Please don't comment with +1 - as
jr...@gmail.com <jr...@gmail.com> #147
ww...@gmail.com <ww...@gmail.com> #148
This issue bugs me so much. Google for one reason (compilation speed) or another (code structure) is/was actively suggesting splitting logic into separate modules and creating multi-module projects. Also Kotlin "I'm agains package access modifier" people are actively pointing at a modules as an alternative.
But you can't even do it when writing a 3rd-party library because of this bug. You'll either end up with a huge number of nonsensical module dependencies that way or your code will not even compile...
lu...@google.com <lu...@google.com> #149
id...@gmail.com <id...@gmail.com> #150
go...@jakewharton.com <go...@jakewharton.com> #151
They probably have to spend their time dealing with entitled assholes like you here on the issue tracker. I'm sure they're hiring, by the way, if you need it that badly.
je...@google.com <je...@google.com> #152
As #149 stated, we are actively working towards providing a solution.
qi...@gmail.com <qi...@gmail.com> #153
ga...@ril.com <ga...@ril.com> #154
vr...@ril.com <vr...@ril.com> #155
mu...@ril.com <mu...@ril.com> #156
pr...@ril.com <pr...@ril.com> #157
ja...@gmail.com <ja...@gmail.com> #158
vi...@digilandia.io <vi...@digilandia.io> #159
pa...@digilandia.io <pa...@digilandia.io> #160
il...@scandit.com <il...@scandit.com> #161
cl...@portto.com <cl...@portto.com> #162
kb...@gmail.com <kb...@gmail.com> #163
un...@gmail.com <un...@gmail.com> #164
ko...@gmail.com <ko...@gmail.com> #165
de...@gmail.com <de...@gmail.com> #166
mm...@gmail.com <mm...@gmail.com> #167
Both of them use some shared modules, but I'm unable to pack them with artfiacts.
Really need this feature
e....@gmail.com <e....@gmail.com> #168
Re: #167
If I used both Android Views and Compose with your library in my project I'd get duplicated classes errors because both your libraries contain the same common classes making it unusable.
Producing an additional common AAR already solves this case. Publishing support improved so much in AGP 7.1+.
e....@gmail.com <e....@gmail.com> #169
Re: #165
You don't provide your SDK using maven coordinates? Copying even a single one AAR is what's annoying.
You can use raw Amazon S3 as a maven repo.
go...@jakewharton.com <go...@jakewharton.com> #170
@ #168
With Java-based projects embedding local project dependencies inside your jar also affords the ability to repackage them into separate package names thus avoiding that problem.
Wanting to create a monolithic AAR from a suite of local project dependencies is one use case. Wanting to repackage a dependency (whether local or remote) into a new package is a separate use case. Both are, however, useful and related.
mr...@gmail.com <mr...@gmail.com> #171
go...@jakewharton.com <go...@jakewharton.com> #172
I think you dropped a "for me".
vu...@gmail.com <vu...@gmail.com> #173
But if your dependent library (lib_A) is private then you have to create fatAAR or open the dependent library (public lib_A)
good luck
be...@livevoice.io <be...@livevoice.io> #174
Is there any update on this?
#149 stated work on this was in progress almost a year ago, is this still true?
Can we expect something to happen anytime soon?
ga...@linecorp.com <ga...@linecorp.com> #175
It seems that com.android.fused-library
But when I applied this plugin, I got errors like this.
plugins {
id "com.android.fused-library"
}
android {
buildToolsVersion "33.0.2"
}
dependencies {
include project(":xxx")
}
$ ./gradlew tasks
...
* What went wrong:
An exception occurred applying plugin request [id: 'com.android.fused-library']
> Failed to apply plugin 'com.android.internal.fused-library'.
> Could not register artifact transform AarResourcesCompilerTransform (from {artifactType=android-exploded-aar} to {artifactType=android-compiled-dependencies-resources}).
> Service com.android.build.gradle.internal.services.Aapt2DaemonBuildService_fe3852e3-dd9f-49d6-ae5c-b2ea20b92660 is not registered.
xa...@google.com <xa...@google.com> #176
The fused-library
plugin is a work in progress and not usable at the moment.
be...@livevoice.io <be...@livevoice.io> #177
Any info on when the fused-library
might be available?
A date far out would still be more helpful than being left in the dark
lu...@google.com <lu...@google.com> #178
Unfortunately, the team can't provide a solid release date for the release of the fused library. Although there was active development on the fused library in 2022, our team priorities changed and we had to put development on hold. We are still committed to fused library especially given this is a highly requested feature and this feature request has been around since 2017.
Once development resumes, it may take take up to 6 months for the plugin to land in a stable release.
I'll update this feature request, once we are able to continue work.
cy...@gmail.com <cy...@gmail.com> #179
iv...@gmail.com <iv...@gmail.com> #180
ne...@gmail.com <ne...@gmail.com> #181
Hey google,
Most of us are eagerly looking at
Three questions:
-
You guys were able to create an entire IDE with Android flavour collaborating with JetBrains. How big is giving us a plugin collaborating with Gradle? If it is that difficult, it would help if you share the work.
-
Date you can't provide, progress you wont reveal, task is not prioritised. You are forcing us not to update to latest AGP. Imagine the world stopped buying new Android phones and use/share the old phones. Do you like it?
-
This feature is not requested by users to ignore, it is required by developers to make apps for you Google. Do you realize that?
I know asking these questions changes nothing, but asking feels right.
Anyone has any better ideas other than making your project into single module or publish all individually to maven?
ar...@gmail.com <ar...@gmail.com> #182
pw...@gmail.com <pw...@gmail.com> #183
[Deleted User] <[Deleted User]> #184
cy...@gmail.com <cy...@gmail.com> #185
+1
wo...@gmail.com <wo...@gmail.com> #186
ba...@gmail.com <ba...@gmail.com> #187
+1
dr...@gmail.com <dr...@gmail.com> #188
ml...@bosch.com <ml...@bosch.com> #189
bs...@gmail.com <bs...@gmail.com> #190
pk...@welldocinc.com <pk...@welldocinc.com> #191
lu...@trulioo.com <lu...@trulioo.com> #192
l....@gmail.com <l....@gmail.com> #193
ar...@neofacto.com <ar...@neofacto.com> #194
ma...@gr8.tech <ma...@gr8.tech> #195
te...@gmail.com <te...@gmail.com> #196
vi...@spotify.com <vi...@spotify.com> #197
id...@gmail.com <id...@gmail.com> #198
I think it's safe to conclude that no one cares, and it will never be fixed.
kb...@gmail.com <kb...@gmail.com> #199
sf...@netflix.com <sf...@netflix.com> #200
ch...@gmail.com <ch...@gmail.com> #201
be...@gmail.com <be...@gmail.com> #202
kh...@gmail.com <kh...@gmail.com> #203
co...@gmail.com <co...@gmail.com> #204
This is a feature we really need where I work, delivering different/customized SDK to client is pain as we can't have common utils and modules without delivering the commons modules separetly (so multiple AAR).
For obfuscation it become annoying as normally we would just have to obfuscate the final SDK and keep the public interface in clear. But with the current behavior we have to have interface between our different modules, instead of having everything "internal" and let the shrinker/minimifier do its job.
Really waiting for a news about this.
ma...@autodesk.com <ma...@autodesk.com> #205
be...@gmail.com <be...@gmail.com> #206
bu...@pensasystems.com <bu...@pensasystems.com> #207
in...@gmail.com <in...@gmail.com> #208
It seems to me that there 2 distinct needs:
a) to merge multiple aar and and expose functionalities of all of them (for example network module, storage module and UI module, and you want all the 3 API available to the user of the resulting merged aar)
b) to use local aar inside another aar, so only the final aar expose an API and the local aar used can be considered private ( so app --> 1.aar --> 2.aar, 3.aar, 4.aar. App sees only 1.aar. 1.aar uses code from 2.arr, 3.aar & 4.aar)
I understand case a) may be difficult for the merging of resources, manifests etc.
But why case b) doesn't work? The accepted solution in the stack overflow question[
It seems to me that a) and b) are 2 related but different problems and should be 2 different tickets, although I may obviously miss something.
*Edit:
in my case, which is b, I don't need a final aar which is merged or obfuscated in a different way, private aar could be even zipped into the public aar and used by the app as if it was a flatDir repo. I could do a flatDir repo and pull the dependency from there, but it seems crazy that for that I need to understand the nuances of the repos, the difference of flatdir and a local maven, if I need or not a pom file, what goes into the pom file, why now in the settings.gradle.kts it says fail_on_project_repos etc.
id...@gmail.com <id...@gmail.com> #209
said. Trying to make a rational argument is just pissing into the wind at
this point.
On Fri, Apr 19, 2024 at 7:03 PM <buganizer-system@google.com> wrote:
be...@gmail.com <be...@gmail.com> #210
in...@gmail.com <in...@gmail.com> #211
In the end why this merging is needed anyway? Are there any reasons aside proguard?
The needs seems to be just having 1 aar file, and obfuscate/strip on the whole set.
at...@zimperium.com <at...@zimperium.com> #212
buy/use some SDK that is provided as an AAR. Combining several AARs into
one would let the provider of the SDK to package everything into a single
AAR with a clean/clear external API and hide the internal structure and
dependencies (maybe even pre-obfuscating and otherwise protecting it but
that is a secondary goal). Without this feature, the user has to deal with
several AARs that comprise the SDK. Or the provider of the SDK has to go
through a lot of pain to do the merging manually.
Atis
On Mon, Apr 22, 2024 at 3:57 AM <buganizer-system@google.com> wrote:
--
[image: photo-logo] <
[image: linkedin] <
twitter_x] <
facebook] <
Atis Straujums
Security Architect, zKeyBox Product Manager
atis.straujums@zimperium.com <
+37129418149
Connect on LinkedIn <
[image: banner] <
in...@gmail.com <in...@gmail.com> #213
@zimperium, yes. I meant what is the need to merge the folders internally on a aar. Instead of having an internal structure like:
Aidl
Androidmanifest.xml
Assets
Classes.jar
Libs
Res
Where the contents are merged from the name1.aar, name2.aar, name3.aar... etc You could have an internal structure like:
Name1
Aidl
Androidmanifest.xml
Assets
Classes.jar
Libs
Res
Name2
Aidl
Androidmanifest.xml
Assets
Classes.jar
Libs
Res
Name3
Aidl
Androidmanifest.xml
Assets
Classes.jar
Libs
Res
...
So you could apply the the obfuscation shrinking only on the whole set of code but defer the actual merge only when the apk file Is created by the user of the created aar. Wouldn't this be equivalent?
I mean, if the merge seemed to require 7 years, maybe doing a new format definition for aar would be easier?
ad...@ticketmaster.co.uk <ad...@ticketmaster.co.uk> #214
je...@google.com <je...@google.com>
ma...@mopinionlabs.com <ma...@mopinionlabs.com> #216
+1
[Deleted User] <[Deleted User]> #217
va...@techtreeit.com <va...@techtreeit.com> #218
+1
pr...@keyless.io <pr...@keyless.io> #219
ha...@solidict.com <ha...@solidict.com> #220
First in 2025 :)
Just wanted to mention that we are still waiting for official support for this issue. Thanks.
Description
Android Plugin Version: 3.0.0-alpha1
Module Compile Sdk Version: n/a
Module Build Tools Version: n/a
Android SDK Tools version: n/a
This issue (or actually a feature request) is for those of us that need to create library projects that produce AAR library as the output.
Please provide a way to create an AAR output that has configured dependencies built in.
There's apparently a lot of Android projects that need this, and so far there has not been an official way to do this with Android Gradle plugin.
There are some workarounds such as Android Fat AAR:
Still, since this is a very basic level feature I think this should be covered by core Android tools.
For example a library project that uses three sub projects that should be all bundled into one AAR output could be declared like this ("api" keyword is just suggestion, it could be also "bundle", "include" or what ever you see fit):
apply plugin: 'com.android.library'
android {
// Normal project definitions
}
dependencies {
api project(":subproject1")
api project(":subproject2")
api project(":subproject3")
}