Gradle add aar only for release build

from the CommonsWare Community archives

At June 8, 2018, 7:16am, rd7773 asked:

We have a requirement where we want to push some data logs to server only in the release build and not in the debug variant. For logging, we are using a third party library in form of aar file put in the libs folder.

  1. Is it a good idea to just add the dependency in the release variant through gradle file to not increase the apk size for debug builds.

  2. How to do it i.e. add aar dependency only for release build. (preferably with new gradle 3.0.1)

  3. Suppose my app depends on 2 libraries, libX(version 2) and libA. libA itself also depends on libX(version 1). In this case, would apk include 2 both versions or just keep the latest one and not impacting the apk size.

At June 8, 2018, 10:38am, mmurphy replied:

Is it a good idea to just add the dependency in the release variant through gradle file to not increase the apk size for debug builds.

IMHO, no, because it means that you will not test your interaction with that dependency.

How to do it i.e. add aar dependency only for release build

releaseImplementation "your.dependency.goes:here:1.0.0"

However, bear in mind that only code and manifests in release-based source sets can refer to items in that dependency.

Suppose my app depends on 2 libraries, libX(version 2) and libA. libA itself also depends on libX(version 1). In this case, would apk include 2 both versions or just keep the latest one and not impacting the apk size.

That depends a lot on how all this is happening.

Suppose that your libX scenario is really lib:x:1.0.0 and lib:x:2.0.0. And, suppose that libA depends upon lib:x:1.0.0 by “normal” means (i.e., it depends upon the actual artifact). Then, if your app also depends upon lib:x:2.0.0, Gradle will only include lib:x:2.0.0 in your app, and libA might break as a result.

This is why for serious API overhauls, many projects are using different artifact and group ID. For example, OkHttp used to be in the com.squareup.okhttp group, and now (3.x) is in the com.squareup.okhttp3 group. So, if your app depends upon com.squareup.okhttp3:okhttp:3.10.0, and libA depends upon com.squareup.okhttp:okhttp:2.7.5, then both versions of OkHttp will be in your app. As developers, we recognize that these artifacts represent the same library, but technically, they are completely independent libraries.

If libA does not use Maven-style dependencies, but instead embeds a copy of libX inside libA, most likely you will crash at build time, with a duplicate-class error.

At June 8, 2018, 11:41am, rd7773 replied:

Ah, got it. Ok but if we leave that groupId thing (lib having same group just different version), that means in our scenario of libX , android will pick only the higher version of libX and it doesn’t matter how they are added (added by normal means or by maven-style). Right ?

Also, What would happen if libX in my app is included by normal means but has been added in libA by maven-style.

At June 8, 2018, 11:53am, mmurphy replied:

Sorry, but I do not know what you consider “normal means” to be, in contrast to “maven-style”.

At June 8, 2018, 12:43pm, rd7773 replied:

Ok sorry for the confusion, by ‘normal means’ i mean adding an .aar file in libs folder and by ‘maven-style’ i mean a maven-repository.

At June 8, 2018, 1:00pm, mmurphy replied:

by ‘normal means’ i mean adding an .aar file in libs folder

I would consider that to be a code smell.

android will pick only the higher version of libX and it doesn’t matter how they are added (added by normal means or by maven-style)

No. There are no version numbers for AAR files in libs/, so Gradle always includes them.

What would happen if libX in my app is included by normal means but has been added in libA by maven-style.

You would attempt to use both, and probably fail to build due to a duplicate class.

At June 8, 2018, 1:27pm, rd7773 replied:

Got it. Thanks for clarifications.