Develop Reference

Library dependency issues with gradle 3.0.0-alphaX

I have a library project with submodules that include many dependencies that I'd like to pass to the developer's application. For example, module A may include all the necessary appcompat dependencies.
With the migration changes, I've updated all compile cases to api, which should not affect anything. However, I no longer have access to any of the libraries dependencies. I can only use code and references from my library itself.
Is there any way around this?
One of the build gradle files of my library submodules can be found here for reference.
The dependencies:
dependencies {
api "org.jetbrains.kotlin:kotlin-stdlib:${KOTLIN}"
api "com.android.support:appcompat-v7:${ANDROID_SUPPORT_LIBS}"
api "com.android.support:support-v13:${ANDROID_SUPPORT_LIBS}"
api "com.android.support:design:${ANDROID_SUPPORT_LIBS}"
api "com.android.support:recyclerview-v7:${ANDROID_SUPPORT_LIBS}"
api "com.android.support:cardview-v7:${ANDROID_SUPPORT_LIBS}"
api "com.android.support.constraint:constraint-layout:${CONSTRAINT_LAYOUT}"
api "com.mikepenz:iconics-core:${ICONICS}#aar"
api "com.mikepenz:google-material-typeface:${IICON_GOOGLE}.original#aar"
api "com.afollestad.material-dialogs:core:${MATERIAL_DIALOG}"
api "com.jakewharton.timber:timber:${TIMBER}"
api "org.jetbrains.anko:anko-commons:${ANKO}"
}
Edit:
To clarify, the sample project in the module actually does build properly, but there's an issue with using the dependencies in any other app, where it pulls from jitpack. See this gradle as an example that won't build.
I've tried using combinations of api, implementation, #aar, and transitive.
Come to think of it, this may be a jitpack issue and not a gradle issue, but if anyone else has a resolution I'd like to hear it.

I no longer have access to any of the libraries dependencies. I can only use code and references from my library itself.
It is correct.
From the gradle docs :
dependencies {
api 'commons-httpclient:commons-httpclient:3.1'
implementation 'org.apache.commons:commons-lang3:3.5'
}
Dependencies appearing in the api configurations will be
transitively exposed to consumers of the library, and as such will
appear on the compile classpath of consumers.
Dependencies found in the implementation configuration will, on the
other hand, not be exposed to consumers, and therefore not leak into
the consumers' compile classpath. This comes with several benefits:
dependencies do not leak into the compile classpath of consumers anymore, so you will never accidentally depend on a transitive
dependency
faster compilation thanks to reduced classpath size
less recompilations when implementation dependencies change: consumers would not need to be recompiled
cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that
distinguish exactly between what is required to compile against the
library and what is required to use the library at runtime (in other
words, don't mix what is needed to compile the library itself and what
is needed to compile against the library).

The issue seems to be related to the android-maven-gradle-plugin
Issue Report

It's has been fixed in version "2.0" of android-maven-gradle-plugin
just update to
dependencies {
classpath 'com.github.dcendents:android-maven-gradle-plugin:2.0'
}
or using the new syntax since Gradle 2.1
plugins {
id "com.github.dcendents.android-maven" version "2.0"
}
using api in your library module allows you to access the transient dependencies only in your library code; not the apps that consume it.
so to achieve the desired effect you need to change in your sample module.
implementation project(':core')
to
api project(':core')
note you don't need to use api in your library it's better to use implementation as it speeds up your build.

How do I properly specify dependencies in a published Android library?

I'm creating an Android library that will be published to something like Sonatype. Some of my classes depend on classes in the AppCompat library.
If my Android module look like this:
dependencies {
compile "com.android.support:appcompat-v7:25.3.1"
}
will my users run into problems if they add my library as a dependency and also add some future version of appcompat as a dependency?
And related, is there a way I can set this up so they don't have to specify transitive dependencies, or would that even be expected for ease of use?

How does gradle handle multi modules with different support library v4 revisions?

I have an Android project which depends on different modules and each modules depends on different revision of the android support-v4 library
1) My app also depends on the latest android support-v4 library (revision 21) so in this build.gralde I put a line like that:
dependencies {
compile 'com.android.support:support-v4:21.0.0'
}
2) Facebook SDK (v.3.15) module that also depends on the android support library v4, but revision 13 and its build.gradle file says:
dependencies {
compile 'com.android.support:support-v4:13.0.+'
compile files('../libs/bolts.jar')
}
3) and one more module that, we can call Module3 in that case, also depends on the support-v4 but with a different revision than the other modules, like that:
dependencies {
compile 'com.android.support:support-v4:19.0.+'
compile files('../libs/bolts.jar')
}
Questions:
1) How does gradle handle different support-v4 library revisions?
2) What does it do exactly?
3) What does it mean in terms of apk size?

In this case Gradle will fail the build (tested on my skin and I did not find other solutions)
"Unfortunately" you have to use the same version of support on any module.
From docs.gradle.com:
Gradle offers the following conflict resolution strategies:
Newest: The newest version of the dependency is used. This is Gradle's default strategy, and is often an appropriate choice as long as versions are backwards-compatible.
Fail: A version conflict results in a build failure. This strategy requires all version conflicts to be resolved explicitly in the build script. See ResolutionStrategy for details on how to explicitly choose a particular version.
While the strategies introduced above are usually enough to solve most conflicts, Gradle provides more fine-grained mechanisms to resolve version conflicts:
Configuring a first level dependency as forced. This approach is useful if the dependency in conflict is already a first level dependency. See examples in DependencyHandler.
Configuring any dependency (transitive or not) as forced. This approach is useful if the dependency in conflict is a transitive dependency. It also can be used to force versions of first level dependencies. See examples in ResolutionStrategy
Dependency resolve rules are an incubating feature introduced in Gradle 1.4 which give you fine-grained control over the version selected for a particular dependency.

Gradle dependencies update

One of the advantages of using Gradle in Android Studio is that it helps in dependency management. So if I have used a particular version of a library in my build.gradle file,
then how will I force it to update the dependency version once the higher version is available?
Some of the dependencies in my build.gradle are specified as
dependencies {
compile project(':facebookSDK')
compile files('libs/picasso-2.1.1.jar')
compile files('libs/crouton-1.8.1.jar')
}

One of the advantages of using Gradle in Android Studio is that it helps in dependency management.
Not the way that you are using it.
So if i have used a particular version of a library in my build.gradle file, then how will i force it to update the dependency version once the higher version is available?
In your case, you would download the new JARs, put them in libs/, and update your build.gradle to match.
The preferred approach is for you to delete those JARs and replace your two compile files statements with ones that pull down the dependencies from Maven Central or another artifact repository. You can find the proper statements for popular open source libraries like those via the Gradle, please site.
In your case, you would use:
compile 'com.squareup.picasso:picasso:2.3.3'
compile 'de.keyboardsurfer.android.widget:crouton:1.8.5'
These will require you to also have a repositories closure as a peer to your dependencies closure:
repositories {
mavenCentral()
}
This may already exist.
These compile statements still pin you to a specific version of those libraries, but moving to a new version would be a simple matter of updating the compile statement, and Gradle will pull down the new dependency on your next build.
If you want, you could replace part of the version number with a wildcard (e.g., 2.3.+). This will cause Gradle to automatically update to new patchlevels of the library, in this case. Some developers do not approve of this approach, as while it is convenient, it does reduce your ability to be able to reproduce a build (e.g., you need to recompile some older branch of your code, and now you don't know what version of the artifact you were using back then).

As you are compiling files from your local project, I don't think you can automatically compile a new individual jar version if available. What you can do instead of compiling individual files is:
compile fileTree(dir: 'libs', include: '*.jar')
This will compile all jars in the libs directory so you will always have the latest version.
Both the libraries you are using are available to be compiled as dependencies from mavencentral.
compile 'de.keyboardsurfer.android.widget:crouton:1.8.5'
compile 'com.squareup.picasso:picasso:2.3.3'
If you want to ensure you are getting the latest versions is you use a plus in place of the version number. It's up to you how open you want to be with this.. so
compile 'de.keyboardsurfer.android.widget:crouton:1.+'
compile 'com.squareup.picasso:picasso:2.+'
will give you the latest version under the 1. or 2. versioning cycles...

If you want, you could replace part of the version number with a wildcard (e.g., 2.3.+).
This will cause Gradle to automatically update to new patch-levels of the library, in this case.
Some developers do not approve of this approach, as while it is convenient it does reduce your ability to be able to reproduce a build (e.g., you need to recompile some older branch of your code, and now you don't know what version of the artifact you were using back then).
I have found Gradle, please to be my answer here.
Easily get the latest android library gradle compile statement.

How to add Android Support Repository to Android Studio?

I'm using Android Studio with an external Android SDK. I have installed the support library and the support repository. The support repository is in:
~/Development/Tools/android/sdk/extras/android/m2repository
When I add a dependency to the support library in the build.gradle file, like:
...
repositories {
mavenCentral()
}
...
dependencies {
compile "com.android.support:support-v4:18.0.+"
}
Android Studio cannot find the support libraries (cannot resolve symbol etc) and Gradle also cannot find the libraries:
Gradle: A problem occurred configuring project ':TestAndroidStudio'.
> Failed to notify project evaluation listener.
> Could not resolve all dependencies for configuration ':TestAndroidStudio:_DebugCompile'.
> Could not find any version that matches com.android.support:support-v4:18.0.+.
Required by:
TestAndroidStudio:TestAndroidStudio:unspecified
How do I specify in Android Studio and/or the build.gradle file the location of the Android support repository?

You are probably hit by this bug which prevents the Android Gradle Plugin from automatically adding the "Android Support Repository" to the list of Gradle repositories. The work-around, as mentioned in the bug report, is to explicitly add the m2repository directory as a local Maven directory in the top-level build.gradle file as follows:
allprojects {
repositories {
// Work around https://code.google.com/p/android/issues/detail?id=69270.
def androidHome = System.getenv("ANDROID_HOME")
maven {
url "$androidHome/extras/android/m2repository/"
}
}
}

Gradle can work with the 18.0.+ notation, it however now depends on the new support repository which is now bundled with the SDK.
Open the SDK manager and immediately under Extras the first option is "Android Support Repository" and install it

Found a solution.
1) Go to where your SDK is located that android studio/eclipse is using.
If you are using Android studio, go to extras\android\m2repository\com\android\support\.
If you are using eclipse, go to \extras\android\support\
2) See what folders you have, for me I had gridlayout-v7, support-v4 and support-v13.
3) click into support-v4 and see what number the following folder is, mine was named 13.0
Since you are using "com.android.support:support-v4:18.0.+", change this to reflect what version you have, for example I have support-v4 so first part v4 stays the same. Since the next path is 13.0, change your 18.0 to:
"com.android.support:support-v4:13.0.+"
This worked for me, hope it helps!
Update:
I noticed I had android studio set up with the wrong SDK which is why originally had difficulty updating! The path should be C:\Users\Username\AppData\Local\Android\android-sdk\extras\
Also note, if your SDK is up to date, the code will be:
"com.android.support:support-v4:19.0.+"

Android Studio 3
Make sure you have the latest version of Android Studio. The support library is included by default when you create new projects. If you are adding the Support Library to a project that doesn't have it, then you just need to add a single line to your app module's build.gradle file, and then sync gradle.
build.gradle
dependencies {
...
implementation 'com.android.support:appcompat-v7:27.1.1'
}
It should just be that easy, though there may be some things to note:
Android Studio should give you a warning nowadays if the support library needs to be updated. Just update the 27.1.1 numbers that I have here to whatever it tells you to. You can also manually check what the latest revision is if you want to.
The implementation keyword replaces compile that was used in Android Studio 2.x. (What's the difference?)
There are other support library packages that you may need to include depending on what your app uses (like constraint-layout or recyclerview).
Make sure that you have the latest updates for everything in the SDK Manager. Go to Tools > SDK Manager.
Documentation
Support Library
Support Library Setup
Support Library Features

I used to get similar issues. Even after installing the support repository, the build used to fail.
Basically the issues is due to the way the version number of the jar files are specified in the gradle files are specified properly.
For example, in my case i had set it as "compile 'com.android.support:support-v4:21.0.3+'"
On removing "+" the build was sucessful!!

Instead of doing this:
compile "com.android.support:support-v4:18.0.+"
Do this:
compile 'com.android.support:support-v4:18.0.+'
Worked for me