Develop Reference

Cost of importing libraries

I've been working on an Android app project. I'm using quite a few libraries (because why redo work that someone else has done to make other people's life easier?).
My question is: what are the costs of importing libraries in a project? (I'm talking about the implementation XXX.YYY:v2.0.0 type of line added in the build.gradle dependencies list.)
Just as an example (though please provide a more encompassing answer): when compiling and publishing my application, does it take all of the libraries' classes and methods and put them in my application, thus making it much heavier than it would need to be?

Each library dependency requires an additional download while you compile your app. So these will increase the amount of time required to compile.
The code for each library is included in your final APK so they will increase the size.

For Every Library a download is necessary In order to built your app.
e.g If you want Libraries regarding to Firebase then You download the Library by adding the Firebase Project to your App. In build.gradle File you see the dependencies after you add them to Your Project App.

Using Dependencies or import Module from Github?

I have one doubt regarding using library from GitHub to Android Studio if anyone help me to solve my doubt, I would be thankful.
My question is
if we want to use library from GitHub , we have two option
either we can use dependencies to import library in project
or we can download the library from GitHub and use it as a module in our project
from above option which one would be good way to use library? (from all perspective)

Dependency
Because whenever a new version of a library arrives you don't have
to continuously check and look for it, let your build tool take care
of that. It can be cumbersome to regularly download and manage
different versions of libraries. That's where build tools like
Gradle comes in and informs you about an update and download it for
you.

You should always use library from github via using dependencies. Why?
You probably won't have times to check and fix the bugs of the library in the future.
You need more time to learn about the library nuts and bolts to maintain and update the library in the future.
You probably don't have enough expertise about the domain of the library.
You need to catch and recreate the bugs you found in your system. So, you need to keep an exact version of each libraries in your project.
You can update and change your dependencies easily without afraid of introducing new bugs.
Make your project clean.

If the package is removed from Gradle, what will happen with my project?

I don't have much experiences with Android development and I have a doubt about the dependencies using Gradle. For example:
If I construct an Android app using Gradle dependecies and the package provider (for example picasso) remove the package from the repository, what will happens with my project? Will I lose the components? Or It makes a local copy of the binaries and my project will kept working normally?
Thanks a lot for help me to understand better how does it works.

You should keep a backup copy of the library you are installing as a dependency, but you shouldn't really worry about it ahead of the time that much.
It is quite rare, but it could get removed due to many reasons. There have been such instances in other cases where someone responsible for managing some package has just decided to remove it or alter it.
This does not just apply to Gradle but to any such dependency your application depends on, from any hosted package management solution. This same advice therefore applies to systems like NPM as well.
What you should ask yourself at some point in the development would be "Can I build this in 5 years again to fix a bug on a fresh machine with all the data I have and probably still have access to in 5 years?", because your local dependency cache might be long gone at that point anyways and the downloads for the library might be gone from the internet as well. It is a good practice to tuck them away somewhere in the same repository as the rest of the code, just in case.

Gradle downloads and caches all the dependencies when you perform Sync, you can see it at the bottom of your Android Studio.
If in the new version of library was deleted some packages, we have two options:
You update library version in your project and this package was removed for your project too
You use the old version of library and package still accessible from your project.

First, you should read that :
What is dependency management ?
The dependency cache
Short answer to your question : your project will still build unless your cache is cleared or if the dependency's version changes
But a package usually does not disappear from a repository (edit : as lu.koerfer underlined it in a comment, packages are not deleted from repository). If so, there might be a replacement package with a different name/group and you should update your dependencies to make it build properly again instead of relying on the cache.

If you will remove the dependency that you using, your project will still be able to use the library you willing to use.
until other dependency with same name / group will override your older dependency
You can read more about how gradle works, and how gradle manage his cache dependencies

Localization for a library module in Android

We are building an app that imports, via Artifactory, a collection of libraries that are then referenced from the main app.
We are in the process of localizing our app. We can localize our libraries and verify it works by directly using the libraries in a test app. When the libraries are pushed to our artifactory, we can then import, via gradle, the libraries for use in our app.
We can verify that making code changes or even changes to English strings in the libraries all work, and when pulled into the main app, any such changes are reflected correctly. However, while we have localized our libraries (into Spanish), when pulling the localized libraries into the main, the Spanish strings are not used. Instead, it uses the default (English) strings. We have looked at the libraries on our artifactory, downloaded the AARs and verified that the snapshots do in fact contain the localized strings but for reasons we can't figure out when imported into the main app, it does not use them.
We're confused why this is the case - wether we are doing something wrong or if there is a bug in gradle or Android.
Does anyone have any insight? I apologise for the vagueness but the issue is rather esoteric so I'm not sure what code if any might be relevant to solving the issue. Feel free to ask for further clarification.
UPDATE:
We decided to import the .AAR directly, by placing it in a libs/ directory and referencing it in our Gradle build. It now works fine, the library in question is correctly localized.
So it would seem the issue comes from when the snapshot is downloaded from the repository.

The app is looking at the wrong version of the library: the previously released version rather than the latest SNAPSHOT.
Full disclosure: James and I work together.

Build a closed source Android library based on Gradle

I would like built a closed source android library using the Gradle. My library has some dependencies to open source projects. How should I structure my library? Can I use gradle?

Can I use gradle?
Short answer:
Yes.
Long answer:
I would assume that your library is packaged as aar (contains resources and compiled bytecode).
First thing you need to know is that at the moment of writing this post there is no way to create fat-aar libraries, which means that you'll have to distribute dependencies of your library separately. The most convenient way to do that, in my opinion, is to generate pom.xml file and publish your library on Maven repository (maven plugin can do all of that), so clients will just fetch all dependencies themselves. Since it is a "private" library, that could be your company's closed repo by access rights (in simple words - create special user for your repo and share password with interested parties).
One downside here is that all dependencies will be exposed in pom.xml and you won't be able to obfuscate them. Personally, I don't think that this is an issue.
Moreover, you get the huge advantage of being able to deploy build automatically and let clients use snapshot versions of the library. This is extremely helpful when you're trying to fix issues and want to deliver them to users fast. On client's side, all they need to do is either just update version in their build.gradle or just re-sync project in case if they were using snapshot.
Second thing. Since your library is closed source, you need to run proguard to obfuscate everything but public interface of your library (all public methods which are exposed to end user).
Remember, that even after obfuscation your code still can be decompiled and all string literals are still there. So, although it was said million times already, avoid storing any critical data in the library (such as passwords, keys, etc.). It is not as hard to extract it as you might think it is: https://www.youtube.com/watch?v=X28Oogg2Q3k
Third thing. I highly suggest you to create internal test project (as a gradle submodule) which will use your library, so you will be sure that you're not making any breaking changes.
Hopefully this answer made things at least a bit easier for you.