While developing an Android Library, if I add v7 Support Library as an dependency to use Toolbar class only, then would the final .aar file contain only the methods of Toolbar class and the related classes only, or it will contain that of Entire Support Library which wouldn't be in any use?
It'll contain the entire support library. In order to remove the unused classes and methods you should use ProGuard. Check out the official guide
about code and resource shrinking.
It will be completely included in your aar. In order to do it in right you you should use provided, e.g.:
provided 'com.android.support:appcompat-v7:+'
In that case users of your library will use there own support library and will not have the same code of support library which will go with your lib.
Related
I just created a new library, Powerful Image View.
My library is a custom AppCompatImageView, so I need the appcompat-v7 library. And here comes the question:
How should I add it to my library?
Should I use 'compile', or 'provided' and let the user add the library to its own dependencies?
And how should i handle different versions of the libraries used, since i'm not depending on a specific version?
I added to the library's gradle file this line:
provided 'com.android.support:appcompat-v7:+'
I'd like to know your thoughts about this :)
Should I use 'compile', or 'provided' and let the user add the library to its own dependencies?
I would use compile and make sure that the developer using your library understands that your library relies upon appcompat-v7, as that in turn places lots of other requirements (e.g., using AppCompatActivity, using Theme.AppCompat).
And how should i handle different versions of the libraries used, since i'm not depending on a specific version?
Well, you are requiring some version. AppCompatImageView does not exist in all versions of appcompat-v7. I recommend depending upon a concrete version (i.e., not +), ideally the latest-and-greatest version.
My Android game doesn't reference any resources defined in extras-android-support-v7/appcompat.
(The app doesn't use ActionBar or material design user interface).
The project compiles without errors when appcompat is not included as library.
Do I still need to include appcompat, in case it is referenced from AdMob, GoogleAnalytics or GoogleGames play-services libraries?
in case it is referenced from AdMob, GoogleAnalytics or GoogleGames play-services libraries?
Those libraries shouldn't bind you to Material Design or extra asset resources requiring appcompat-v7.
If you wanted to use Support Fragments, though, it would be a good idea to include at least support-v4
How I can use com.android.setupwizardlib in my project?
This library isn't on jcenter or as gradle dependency.
This library is used in some apps (Such as Greenify) and it uses the XML tag com.android.setupwizardlib.SetupWizardLayout in my Activity
Any solutions about it?
I know how to import a library, I only need help with this specific google library
Greenify SetupWizardLib
It would be simpler for you to use existing packaged libraries for this functionality, such as some of these or a couple of these.
Otherwise, grab the source code and resources, add them to your project (directly or via a separate library module), and make changes as needed to get it to build.
I am using Android v4 library. There are some unused modules such as accessibility that I would like to remove from the dependency. I saw this link which says I can use ProGuard to do that, but I would like to know if there is something I can add to the gradle to explicitly set the removal.
android-support-v4 remove unused classes
Appreciate your help.
ProGuard does it by itself by default, but you may also "fix" your dependency using more specific lib instead of whole v4 package. take a look on options, maybe just one or two options will be sufficient for you
An unreleased android library I am working on has a third party networking library in it - OkHttp in this case.
Projects that use this library as a dependency also are now able to create objects with that networking library.
Can I limit or disable access to the networking library contained within my library?
You could make the dependency transitive however if your code hits the missing code inside their app it will fail ClassNotFound or MethodNotFound
dependencies {
compile('com.squareup.okhttp3:okhttp:3.2.0') {
transitive = false
}
}
Short of that once the code is packaged with your lib it's available to anyone who wants to use it from your lib.
This still won't solve the problem as you would like but you could use proguard to rename the okhttp classes. Users of your lib could still call the okhttp classes but they would be renamed by proguard to something like a,b,c,...
What you want to do is shade the dependency. Here's a description from a blog post about shading dependencies in Gradle:
To Shade a library is to take the contents files of said library, put
them in your own jar, and change their package.This is different from
packaging which is simply shipping the libraries files in side your
own jar without relocating them to a different package. The term
fatjar is commonly used to refer to jars that have the application as
well as its dependencies packaged or shaded into them.
It's easy to do for smaller libraries. I could image it might be difficult for a large library like OkHttp. You can do it manually by simply copying the files into your project and changing the package. There are also some scripts that will do it automatically. They usually use Jar Jar Links.
Normally be default you don't have the dependencies like that:
compile rootProject.ext.okhttp
compiled in your jar only your sources are. So OkHttp classes will not be in your lib.
I have exactly the same case. I use gradle to build and upload to maven.
You can check here
So if your intention is to have the exact dept version in the package and to be hidden you just need to include it in you project as a module and to change some things like the package of OkHttp to avoid conflicts and also the access to currenly public okhttp members. OkHttp is using Okio so you may want to privatize it too.
Note that this kind of shadowing + hiding functionality of the shadowed class can be useful for framework dependencies(ensuring all depts in runtime available) but it is increasing the size of your libs and will not be the best option for apps using your lib as they anyway ensure packaging required depts in the apk.