An app project's structure is like the following:
Foo
app
mylibrary
libs
somelib.aar
The app uses mylibrary as follows in build.gradle:
implementation project(path: ':mylibrary')
Is it possible for the code of the app to reference classes in somelib.aar directly? I want to avoid adding somelib.aar to both app and mylibrary.
Related
I am developing an Android Library module in AAR format. I found it very troublesome to have to be manually importing the module via Android Studio wizard each time I need to test library changes on an Android sample app. I changed my approach to using a symbolic link and linking the generated AAR on the library side with the AAR on the sample app side and just building and syncing Gradle via Android Studio.
However, this process is still not the best because I need to manually click buttons on Studio to achieve this. What I would like is to write a simple script using Gradle CLI and/or bash that allows me, from the app's side, to import the module into the app from some directory and sync the app's Gradle after importing.
Is this possible? Thanks.
You don't need to import your library module every time. Make your library as one of the modules and link the dependency between app and library.
Make sure the library is listed at the top of your settings.gradle file, as shown here for a library named "my-library-module":
include ':app', ':my-library-module'
Open the app module's build.gradle file and add a new line to the dependencies block as shown in the following snippet:
dependencies {
implementation project(":my-library-module")
}
And build using command lines.
gradlew assembleDebug
https://developer.android.com/studio/projects/android-library
I have an android project with following structure:
-- Calendar
------app (app module)
----------build.gradle (module level)
------build.gradle (project level)
------Commons(A common project which i reuse across various projects)
----------common (common module in Commons project)
-------------build.gradle (for only common module level)
----------build.gradle(for Commons Project)
Now the problem is that if I compile Commons, deploy it to bintray and then use it as implementation 'com.amitkma.Commons:common:1.0.0' in app module, all the dependencies (which are implemented in common build.gradle) is available to use in app module also. But if I use it like following
implementation project(:Commons:common), only dependencies provided using api is available to use.
I want to know what is the difference between api and implementation with respect to module is compiled or used directly like above?
There are two things at play here:
The separation of api and implementation when declaring dependencies. In short dependencies in the implementation scope are only visible at runtime because they are an implementation detail. Such libraries will use the runtime scope in their published Maven metadata. More information in the documentation
Before Gradle 5.0, the Maven metadata scopes compile and runtime were mixed by Gradle and thus all runtime dependencies did appear on the compile classpath. Gradle 5 changes this
So when you publish your component, the limitation of Gradle 4.x means that your common dependencies are available to app. Note that moving to Gradle 5 will cause a breakage there, as documented.
And when you use the project directly, the separation is properly enforced.
The fix is to simply promote dependencies that are part of the common api to the api configuration in common and for the runtime ones, declare them in app as after all they are directly required by it.
I have Project where is included several modules.
each module has its own build.gradle file, where is dependencies for it's module.
my main problem:
for example i have module-one and module-two, each of them has it own build.gradle where is same .jar libraries but different versions.
when building application, into each modules Library are both dependency classes both versions and getting error because of application trying to call function(from version 1.1) but i need from version 1.2
please explain how can i fix it, to don't mix up Libraries within modules.
I'd like to create my own gradle library, that can be compiled into other projects using gradle compile statement.
Example from Picasso's README:
Download the latest JAR or grab via Gradle:
compile 'com.squareup.picasso:picasso:2.5.2'
I'm developing few applications that share common source: fragments, views, some logic... Sometimes I extend these sources while I'm developing app A, sometimes while I'm developing app B,... And I feel that copy-paste of packages/classes in Android Library Module is not an proper solution.
So I would like to setup my own library, that:
it could be easily deployed to as gradle library that could be used by compile.
I can easily develop/extend it together with currently developed application
Disclaimer: I had been googling it a lot, but without luck.
If you want to reuse a library across completely separate projects then you'll want to publish your library to repository. Assuming this is open source and you don't mind sharing, you could use JCenter, which is already added as a repository to Android projects by default.
https://www.virag.si/2015/01/publishing-gradle-android-library-to-jcenter/
I wonder about dependencies in libgdx. Each sub project (Android, iOS etc) can have their own dependencies as I understand it (they have their own build.gradle file).
I thought that I would only import a dependency to for example the core-project and then all the other sub projects would use that dependency also. Is that not the case? Or do I always need to specify a dependency many times for each sub project, even though I imported it already in the core project?
In libgdx, every projects depends on the core project, so if the core project depends on a library the subproject will depend on it as well.
You can easily manage dependencies in gradle with Maven like this:
dependencies {
compile "group.name:artifactId:versionX"
}
Filled in for libgdx this would make:
dependencies {
compile "com.badlogicgames.gdx:gdx:1.4.1"
}
To add more dependencies add another compile "" on a new line.