Android build in classes

Содержание
  1. How to make Android apps without IDE from command line
  2. How to do Android development faster without Gradle
  3. IntelliJ IDE, but not Gradle
  4. 1. Install Java
  5. 2. Install all SDK tools
  6. Download Android Studio and SDK Tools | Android Studio
  7. Download the official Android IDE and developer tools to build apps for Android phones, tablets, wearables, TVs, and…
  8. 3. Code the application
  9. How to use JavaMail on Android (without Gradle)
  10. Hello guys!
  11. 4. Build the code
  12. 5. Sign the package
  13. 6. Align the package
  14. 7. Test the application
  15. 8. Make a script
  16. Notes
  17. Android Application Class
  18. Android Activity Lifecycle
  19. Android activity lifecycle is first thing to be known as android developer. Here I’m sharing with you some facts and…
  20. Add build dependencies
  21. Dependency types
  22. Groovy
  23. Kotlin
  24. Groovy
  25. Kotlin
  26. Groovy
  27. Kotlin
  28. Groovy
  29. Kotlin
  30. Groovy
  31. Kotlin
  32. Groovy
  33. Kotlin
  34. Native dependencies
  35. Dependency configurations
  36. Groovy
  37. Kotlin
  38. Deprecated Gradle configurations (available in AGP 1.0–4.2)
  39. Groovy
  40. Kotlin
  41. Groovy
  42. Kotlin
  43. Groovy
  44. Kotlin
  45. Add annotation processors
  46. Groovy
  47. Kotlin
  48. Pass arguments to annotation processors
  49. Groovy
  50. Kotlin
  51. Groovy
  52. Kotlin
  53. Groovy
  54. Kotlin
  55. Disable the annotation processor error check
  56. Groovy
  57. Kotlin
  58. Groovy
  59. Kotlin
  60. Exclude transitive dependencies
  61. Groovy
  62. Kotlin
  63. Exclude transitive dependencies from test configurations
  64. Groovy
  65. Kotlin
  66. Configure Wear OS app dependencies
  67. Groovy
  68. Kotlin
  69. Groovy
  70. Kotlin
  71. Remote repositories
  72. Groovy
  73. Kotlin
  74. Groovy
  75. Kotlin
  76. Groovy
  77. Kotlin
  78. Google’s Maven repository
  79. Groovy
  80. Kotlin
  81. Groovy
  82. Kotlin
  83. Programmatic access
  84. Offline repository from SDK Manager
  85. Native dependencies with the Android Gradle plugin
  86. Using native dependencies
  87. Native dependencies in AARs
  88. Build system configuration
  89. Groovy
  90. Kotlin
  91. Publishing native libraries in AARs
  92. Groovy
  93. Kotlin
  94. Dependency order
  95. View module dependencies
  96. Fix dependency resolution errors
  97. Fix duplicate class errors
  98. Fix conflicts between classpaths
  99. Apply custom build logic
  100. Publish variant dependencies to custom logic
  101. Custom dependency resolution strategies
  102. Groovy
  103. Kotlin
  104. Dependency information for Play Console

How to make Android apps without IDE from command line

Nov 26, 2017 · 5 min read

A HelloWorld without Android Studio

Update: I’ve made a new course that explain how you can avoid Android Studio and Gradle, but still use IntelliJ iDE:

How to do Android development faster without Gradle

IntelliJ IDE, but not Gradle

In this tutorial, I will show you how you can build/compile an APK (an A n droid app) from your java code using terminal (on Linux) without IDE or in other words without Android Studio. At the end, I will also show you a script to automate the process. In this example, I will use Android API 19 (4.4 Kitkat) to make a simple HelloWorld. I want to say that I will do this tutorial without android command which is deprecated.

1. Install Java

First, you need to install java, in my case, I install the headless version because I don’t use graphics (only command line):

2. Install all SDK tools

Then download the last SDK tools of Android which you can find here:

Download Android Studio and SDK Tools | Android Studio

Download the official Android IDE and developer tools to build apps for Android phones, tablets, wearables, TVs, and…

I recommend to unzip it in the /opt directory inside another directory that we will call “android-sdk”:

Now, we have to install platform tools (which contain ADB), an Android API and build tools.

In fact, if you are on Debian, you can avoid installing platform-tools package and only install ADB like that:

3. Code the application

In this example, I want to compile a simple HelloWorld. So, first, we need to make a project directory:

Then we have to make the files tree:

If you use exernal libraries (.jar files), also make a folder for them:

You have an example here:

How to use JavaMail on Android (without Gradle)

Hello guys!

Make the file src/com/example/helloandroid/MainActivity.java and put that inside:

Make the strings.xml file in the res/values folder. It contains all the text that your application uses:

The activity_main.xml is a layout file which have to be in res/layout:

You also have to add the file AndroidManifest.xml at the root:

4. Build the code

Now, I recommend to store the project path in a variable:

First, we need generate the R.java file which is necessary for our code:

  • -m instructs aapt to create directories under the location specified by -J
  • -J specifies where the output goes. Saying -J src will create a file like src/com/example/helloandroid/R.java
  • -S specifies where is the res directory with the drawables, layouts, etc.
  • -I tells aapt where the android.jar is. You can find yours in a location like android-sdk/platforms/android-/android.jar

Now, we have to compile the .java files:

If you have use an external, add it the classpath:

The compiled .class files are in obj folder, but Android can’t read them. We have to translate them in a file called “classes.dex” which will be read by the dalvik Android runtime:

But if you use external libraries, do rather:

If you have the error UNEXPECTED TOP-LEVEL EXCEPTION , it can be because you use old build tools and DX try to translate java 1.7 rather than 1.8. To solve the problem, you have to specify 1.7 java version in the previous javac command:

The -source option specify the java version of your source files. Note that we can use previous versions of Java even we use OpenJDK 8 (or 1.8).

We can now put everything in an APK:

Be aware: until now, we used three AAPT commands, the first and the second one are similar but they don’t do the same. You have to copy the classes.dex file at the root of project like above! Otherwise, AAPT won’t put this file at right place in the APK archive (because an APK is like a .zip file).

The generated package can’t be installed by Android because it’s unaligned and unsigned.

If you want, you can check the content of the package like this:

5. Sign the package

To do so, we firstly create a new keystore with the command keytool given by Java:

Just answer the questions and put a password.

You can sign an APK like this:

Note that apksigner only exist since Build Tools 24.0.3.

6. Align the package

It’s as simple as that:

Alignment increase the performance of the application and may reduce memory use.

7. Test the application

To test the application, connect your smartphone with a USB cable and use ADB:

But before run this command, I recommend to run this one:

If there is an error during installation or running, you see it with that command.

Voila! Here’s the result:

8. Make a script

If you don’t want to run all these steps every time you would like to compile your app, make a script! Here’s mine:

Notes

  • You can remove “test” if you just want to compile without testing.
  • This script only compile and run the app on the phone. But I can also make a script to automatically generate a new project like this one. I think I have a good idea to do so, but I need to know if you are interested. If it’s the case, please leave a comment or send me an e-mail.
  • I can also complete the script for external libraries. Likewise, let me know if you want this.

If you have any questions, don’t hesitate to ask them below or by e-mail ;-)! EDIT: Well I’m very busy actually…

Источник

Android Application Class

W hile Starting App development, we tend to miss out simple basic stuffs either by ignorance or by curiosity to build million dollar app. But, Hey! Why so serious !. Building a App is bit of Art ,bit of Engineering and frequently both.

Activity Life Cycle is stages of activity in run time, knowing these would save you from headaches while you dive deeper in development.

I have written a post that will help you to understand activity lifecycle in a practical approach. Check it out

Android Activity Lifecycle

Android activity lifecycle is first thing to be known as android developer. Here I’m sharing with you some facts and…

Application class is a base class of Android app containing components like Activities and Services. Application or its sub classes are instantiated before all the activities or any other application objects have been created in Android app.

You Don’t have to import or extend application class, they are predefined. We cannot change application class but we could give additional instruction to it by extending it. Refer here for more info.

Create a java class named SubApplication and Application as Superclass

By extending Application class you could get boilerplate code like this

Check in AndroidManifest.xml and set Application name to SubApplication that you created

Lets take a situation where we should know which activity is currently running and we have to use register network receiver in all our activities. To this we used to write same code in all the activities or write a base class and extend that class instead of extending AppCompactActivity.

We have Activity Life cycle in one hand and Application class in another, what sense they make? Well actually they do? Let’s look into it.

  1. In application class create static Activity variable it is accessible from whole project.

2. Register Activity Life Cycle callback in onCreate method in application class. By this step we can get currently running activity in our app from mActivity.

Читайте также:  Эстетичные обои для андроид

3.Moving on to next, Create a Broadcast Receiver and write a method to check the internet connection. you can get the code here .

4. Register your broadcast receiver in Manifest File

But for SDK Above Nougat we need to register receiver and unregister in every activity we use programmatically or We can just register and unregister Commonly in Application class.

5. Create a Object for Broadcast Receiver in application class and Register it in onResume method and Unregister in onPause method.

Bit confused! Don’t Worry, Here is the Link to the files.

Thanks for reading out the article. Let me know if I have missed out something interesting so that I can be added. Be sure to clap/recommend as much as you can and also share with your friends.

Источник

Add build dependencies

The Gradle build system in Android Studio makes it easy to include external binaries or other library modules to your build as dependencies. The dependencies can be located on your machine or in a remote repository, and any transitive dependencies they declare are automatically included as well. This page describes how to use dependencies with your Android project, including details about behaviors and configurations that are specific to the Android plugin for Gradle. For a deeper conceptual guide to Gradle dependencies, you should also see the Gradle guide for dependency management —but remember that your Android project must use only the dependency configurations defined on this page.

Dependency types

To add a dependency to your project, specify a dependency configuration such as implementation in the dependencies block of your build.gradle file.

For example, the following build.gradle file for an app module includes three different types of dependencies:

Groovy

Kotlin

Each of these requests a different kind of library dependency as follows:

Local library module dependency

Groovy

Kotlin

This declares a dependency on an Android library module named «mylibrary» (this name must match the library name defined with an include: in your settings.gradle file). When you build your app, the build system compiles the library module and packages the resulting compiled contents in the app.

Local binary dependency

Groovy

Kotlin

Gradle declares dependencies on JAR files inside your project’s module_name /libs/ directory (because Gradle reads paths relative to the build.gradle file).

Alternatively, you can specify individual files as follows:

Groovy

Kotlin

Groovy

Kotlin

This is actually shorthand for the following:

Groovy

Kotlin

This declares a dependency on version 12.3 of the «app-magic» library, inside the «com.example.android» namespace group.

Note: Remote dependencies like this require that you declare the appropriate remote repositories where Gradle should look for the library. If the library does not already exist locally, Gradle pulls it from the remote site when the build requires it (such as when you click Sync Project with Gradle Files or when you run a build).

Native dependencies

As of Android Gradle plugin 4.0, native dependencies can also be imported in the manner described in this document.

Depending on an AAR that exposes native libraries will automatically make them available to the build system used by externalNativeBuild . To access the libraries from your code, you must link to them in your native build scripts. In this document, see Using native dependencies.

Dependency configurations

Inside the dependencies block, you can declare a library dependency using one of several different dependency configurations (such as implementation shown above). Each dependency configuration provides Gradle with different instructions about how to use the dependency. The following table describes each of the configurations you can use for a dependency in your Android project. The table also compares these configurations to those that were deprecated as of Android Gradle plugin 3.0.0.

To add a dependency on a library that is an annotation processor, you must add it to the annotation processor classpath using the annotationProcessor configuration. That’s because using this configuration improves build performance by separating the compile classpath from the annotation processor classpath. If Gradle finds annotation processors on the compile classpath, it deactivates compile avoidance, which negatively impacts build time (Gradle 5.0 and higher ignore annotation processors found on the compile classpath).

The Android Gradle plugin assumes a dependency is an annotation processor if its JAR file contains the following file:

If the plugin detects an annotation processor that’s on the compile classpath, it produces a build error.

Note: Kotlin projects should use kapt to declare annotation processor dependencies.

Use this configuration to include lint checks you want Gradle to execute when building your project.

Note: When using Android Gradle plugin 3.4.0 and higher, this dependency configuration no longer packages the lint checks in your Android Library projects. To include lint check dependencies in your AAR libraries, use the lintPublish configuration described below.

Configuration Behavior
implementation Gradle adds the dependency to the compile classpath and packages the dependency to the build output. However, when your module configures an implementation dependency, it’s letting Gradle know that you do not want the module to leak the dependency to other modules at compile time. That is, the dependency is available to other modules only at runtime.

Using this dependency configuration instead of api or compile (deprecated) can result in significant build time improvements because it reduces the number of modules that the build system needs to recompile. For example, if an implementation dependency changes its API, Gradle recompiles only that dependency and the modules that directly depend on it. Most app and test modules should use this configuration.

api Gradle adds the dependency to the compile classpath and build output. When a module includes an api dependency, it’s letting Gradle know that the module wants to transitively export that dependency to other modules, so that it’s available to them at both runtime and compile time.

This configuration behaves just like compile (which is now deprecated), but you should use it with caution and only with dependencies that you need to transitively export to other upstream consumers. That’s because, if an api dependency changes its external API, Gradle recompiles all modules that have access to that dependency at compile time. So, having a large number of api dependencies can significantly increase build time. Unless you want to expose a dependency’s API to a separate module, library modules should instead use implementation dependencies.

compileOnly Gradle adds the dependency to the compile classpath only (that is, it is not added to the build output). This is useful when you’re creating an Android module and you need the dependency during compilation, but it’s optional to have it present at runtime.

If you use this configuration, then your library module must include a runtime condition to check whether the dependency is available, and then gracefully change its behavior so it can still function if it’s not provided. This helps reduce the size of the final app by not adding transient dependencies that aren’t critical. This configuration behaves just like provided (which is now deprecated).

Note: You can’t use the compileOnly configuration with AAR dependencies.

runtimeOnly Gradle adds the dependency to the build output only, for use during runtime. That is, it is not added to the compile classpath. This configuration behaves just like apk (which is now deprecated).
annotationProcessor
lintPublish Use this configuration in Android library projects to include lint checks you want Gradle to compile into a lint.jar file and package in your AAR. This causes projects that consume your AAR to also apply those lint checks. If you were previously using the lintChecks dependency configuration to include lint checks in the published AAR, you need to migrate those dependencies to instead use the lintPublish configuration.

Groovy

Kotlin

Deprecated Gradle configurations (available in AGP 1.0–4.2)

Configuration Behavior
apk Gradle adds the dependency to the build output only, for use during runtime. That is, it is not added to the compile classpath.
compile Gradle adds the dependency to the compile classpath and build output. Exports the dependency to other modules.
provided Gradle adds the dependency to the compile classpath only (that is, it is not added to the build output).

All of the above configurations apply dependencies to all build variants. If you instead want to declare a dependency for only a specific build variant source set or for a testing source set, you must capitalize the configuration name and prefix it with the name of the build variant or testing source set.

For example, to add an implementation dependency only to your «free» product flavor (using a remote binary dependency), it looks like this:

Groovy

Kotlin

However, if you want to add a dependency for a variant that combines a product flavor and a build type, then you must initialize the configuration name in the configurations block. The following sample adds a runtimeOnly dependency to your «freeDebug» build variant (using a local binary dependency).

Groovy

Kotlin

To add implementation dependencies for your local tests and instrumented tests , it looks like this:

Groovy

Kotlin

However, certain configurations don’t make sense in this situation. For example, because other modules can’t depend on androidTest , you get the following warning if you use the androidTestApi configuration:

Add annotation processors

If you add annotation processors to your compile classpath, you’ll see an error message similar to the following:

To resolve this error, add annotation processors to your project by configuring your dependency using annotationProcessor as shown below:

Groovy

Kotlin

Note: Android plugin for Gradle 3.0.0+ no longer supports android-apt plugin.

Pass arguments to annotation processors

If you need to pass arguments to an annotation processor, you can do so using the AnnotationProcessorOptions block in your module’s build configuration. For example, if you want to pass primitive data types as key-value pairs, you can use the argument property, as shown below:

Groovy

Kotlin

However, when using Android Gradle plugin 3.2.0 and higher, you need to pass processor arguments that represent files or directories using Gradle’s CommandLineArgumentProvider interface.

Using CommandLineArgumentProvider allows you or the annotation processor author to improve the correctness and performance of incremental and cached clean builds by applying incremental build property type annotations to each argument.

For example, the class below implements CommandLineArgumentProvider and annotates each argument for the processor. The sample also uses the Groovy language syntax and is included directly in the module’s build.gradle file.

Groovy

Kotlin

After you define a class that implements CommandLineArgumentProvider , you need to create an instance and pass it to the Android plugin using the annotationProcessorOptions.compilerArgumentProvider method, as shown below.

Groovy

Kotlin

To learn more about how implementing CommandLineArgumentProvider helps improve build performance, read Caching Java projects.

Disable the annotation processor error check

If you have dependencies on the compile classpath that include annotation processors you don’t need, you can disable the error check by adding the following to your build.gradle file. Keep in mind, the annotation processors you add to the compile classpath are still not added to the processor classpath.

Groovy

Kotlin

If you use Kotlin and kapt:

Groovy

Kotlin

If you experience issues after migrating your project’s annotation processors to the processor classpath, you can allow annotation processors on the compile classpath by setting includeCompileClasspath to true . However, setting this property to true is not recommended, and the option to do so will be removed in a future update of the Android plugin.

Exclude transitive dependencies

As an app grows in scope, it can contain a number of dependencies including direct dependencies and transitive dependencies (libraries which your app’s imported libraries depend on). To exclude transitive dependencies that you no longer need, you can use the exclude keyword as given below:

Groovy

Kotlin

Exclude transitive dependencies from test configurations

If you need to exclude certain transitive dependencies from your tests, the code sample shown above might not work as expected. That’s because a test configuration (e.g., androidTestImplementation ) extends the module’s implementation configuration. That is, it always contains implementation dependencies when Gradle resolves the configuration.

So, to exclude transitive dependencies from your tests, you must do so at execution time as shown below:

Groovy

Kotlin

Note: You can still use the exclude keyword in the dependencies block as shown in the original code sample from the Exclude transitive dependencies section to omit transitive dependencies that are specific to the test configuration and are not included in other configurations.

Configure Wear OS app dependencies

Configuring dependencies for a Wear OS module is similar to that of any other module; that is, Wear OS modules use the same dependency configurations, such as implementation and compileOnly .

Wear modules also support variant-aware dependency management. As a result, if your base app module has a dependency on a Wear module, each variant of the base module consumes the matching variant from the Wear module. If you are building a simple app with a dependency on only one Wear module, where the module configures the same variants as your base module, you need to specify the wearApp configuration in your base module’s build.gradle file as shown below:

Groovy

Kotlin

If you have multiple Wear modules and you want to specify a different Wear module per app flavor, you can do so using the flavor WearApp configuration, as follows (however, you can’t include other dependencies that use the wearApp configuration):

Groovy

Kotlin

Remote repositories

When your dependency is something other than a local library or file tree, Gradle looks for the files in whichever online repositories are specified in the repositories block of your build.gradle file. The order in which you list each repository determines the order in which Gradle searches the repositories for each project dependency. For example, if a dependency is available from both repository A and B, and you list A first, Gradle downloads the dependency from repository A.

By default, new Android Studio projects specifies Google’s Maven repository and JCenter as repository locations in the project’s top-level build.gradle file, as shown below:

Groovy

Kotlin

If you want something from the Maven central repository, then add mavenCentral() , or for a local repository use mavenLocal() :

Groovy

Kotlin

Or you can declare specific Maven or Ivy repositories as follows:

Groovy

Kotlin

For more information, see the Gradle Repositories guide.

Google’s Maven repository

The most recent versions of the following Android libraries are available from Google’s Maven repository:

You can see all available artifacts at Google’s Maven repository index (see below for programmatic access).

To add one of these libraries to your build, include Google’s Maven repository in your top-level build.gradle file:

Groovy

Kotlin

Then add the desired library to your module’s dependencies block. For example,the appcompat library looks like this:

Groovy

Kotlin

However, if you’re trying to use an older version of the above libraries and your dependency fails, then it’s not available in the Maven repository and you must instead get the library from the offline repository.

Programmatic access

For programmatic access to Google’s Maven artifacts, you can get an XML list of artifact groups from maven.google.com/master-index.xml. Then, for any group, you can view its library names and versions at:

maven.google.com/ group_path /group-index.xml

For example, libraries in the android.arch.lifecycle group are listed at maven.google.com/android/arch/lifecycle/group-index.xml.

You can also download the POM and JAR files at:

maven.google.com/ group_path / library / version / library — version . ext

Offline repository from SDK Manager

For libraries not available from the Google Maven repository (usually older library versions), you must download the offline Google Repository package from the SDK Manager.

Then you can add these libraries to your dependencies block as usual.

The offline libraries are saved in android_sdk /extras/ .

Native dependencies with the Android Gradle plugin

AAR libraries can contain native dependencies that the Android Gradle Plugin can consume. AGP is also capable of producing AARs that expose native libraries to their consumers.

Using native dependencies

Starting with Android Gradle plugin 4.0, C/C++ dependencies can be imported from AARs linked in your build.gradle file. Gradle will automatically make these available to the native build system, but your build system must be configured to make use of the imported libraries and headers. Since C/C++ dependencies are distributed as AARs, the following links about generic AARs may be helpful:

  • Creating an Android Library for generic AAR documentation and how to integrate it into your project, especially when you want to use the AAR as a local C/C++ dependency.
  • Add build dependencies for information on adding dependencies to your build.gradle file, especially for the remote dependencies.

This document focuses on how to configure your native build system and assumes you’ve already added a C/C++ dependency AAR into your project’s Gradle build environment.

Native dependencies in AARs

AAR dependencies of your Gradle modules can expose native libraries for use by your application. Inside the AAR, the prefab directory contains a Prefab package, which includes the headers and libraries of the native dependency.

Each dependency can expose at most one Prefab package, which comprises one or more modules. A Prefab module is a single library, which could be either a shared, static, or header only library.

The package and module names need to be known to make use of the libraries. By convention the package name will match the Maven artifact name and the module name will match the C/C++ library name, but this is not required. Consult the dependency’s documentation to determine what names it uses.

Build system configuration

Android Gradle Plugin 4.0 Android Gradle Plugin 4.1+

The prefab feature must be enabled for your Android Gradle module.

To do so, add the following to the android block of your module’s build.gradle file:

Groovy

Kotlin

Dependencies imported from an AAR are exposed to CMake via CMAKE_FIND_ROOT_PATH. This value will be set automatically by Gradle when CMake is invoked, so if your build modifies this variable be sure to append rather than assign to it.

Each dependency exposes a config-file package to your build. These are imported with the find_package command. This command searches for config-file packages matching the given package name and version and exposes the targets it defines to be used in your build. For example, if your application defines libapp.so and it uses cURL, your CMakeLists.txt should include the following:

app.cpp is now able to #include «curl/curl.h» , libapp.so will be automatically linked against libcurl.so when building, and libcurl.so will be included with the app.

Publishing native libraries in AARs

The ability to create native AARs was first added in AGP 4.1.

To export your native libraries, add the following to the android block of your library project’s build.gradle file:

Groovy

Kotlin

In this example, the mylibrary and myotherlibrary libraries from either your ndk-build or CMake external native build will be packaged in the AAR produced by your build, and each will export the headers from the specified directory to their dependents.

Dependency order

The order in which you list your dependencies indicates the priority for each: the first library is higher priority than the second, the second is higher priority than the third, and so on. This order is important in the event that resources are merged or manifest elements are merged into your app from the libraries.

For example, if your project declares the following:

  • Dependency on LIB_A and LIB_B (in that order)
  • And LIB_A depends on LIB_C and LIB_D (in that order)
  • And LIB_B also depends on LIB_C

Then, the flat dependency order will be as follows:

This ensures that both LIB_A and LIB_B can override LIB_C ; and LIB_D is still higher priority than LIB_B because LIB_A (which depends on it) has higher priority than LIB_B .

For more information about how manifests from different project sources/dependencies are merged, see Merge multiple manifest files.

View module dependencies

Some direct dependencies may have dependencies of their own. These are called transitive dependencies. Rather than requiring you to manually declare each transitive dependency, Gradle automatically gathers and adds them for you. The Android plugin for Gradle provides a task that displays a list of the dependencies Gradle resolves for a given module.

For each module, the report also groups the dependencies based on build variant, testing source set, and classpath. The following is sample report for an app module’s runtime classpath of its debug build variant and compile classpath of its instrumented test source set.

To run the task, proceed as follows:

  1. Select View > Tool Windows > Gradle (or click Gradle in the tool windows bar).
  2. Expand AppName > Tasks > android and double-click androidDependencies. After Gradle executes the task, the Run window should open to display the output.

For more information about managing dependencies in Gradle, see Dependency management basics in the Gradle User Guide.

Fix dependency resolution errors

When you add multiple dependencies to your app project, those direct and transitive dependencies might conflict with one another. The Android Gradle plugin tries to resolve these conflicts gracefully, but some conflicts may lead to compile time or runtime errors.

To help you investigate which dependencies are contributing to errors, inspect your app’s dependency tree and look for dependencies that appear more than once or with conflicting versions.

If you can’t easily identify the duplicate dependency, try using Android Studio’s UI to search for dependencies that include the duplicate class as follows:

  1. Select Navigate > Class from the menu bar.
  2. In the pop-up search dialog, make sure that the box next to Include non-project items is checked.
  3. Type the name of the class that appears in the build error.
  4. Inspect the results for the dependencies that include the class.

The following sections describe the different types of dependency resolution errors you may encounter and how to fix them.

Fix duplicate class errors

If a class appears more than once on the runtime classpath, you get an error similar to the following:

This error typically occurs due to one of the following circumstances:

  • A binary dependency includes a library that your app also includes as a direct dependency. For example, your app declares a direct dependency on Library A and Library B, but Library A already includes Library B in its binary.
    • To resolve this issue, remove Library B as a direct dependency.
  • Your app has a local binary dependency and a remote binary dependency on the same library.
    • To resolve this issue, remove one of the binary dependencies.

Fix conflicts between classpaths

When Gradle resolves the compile classpath, it first resolves the runtime classpath and uses the result to determine what versions of dependencies should be added to the compile classpath. In other words, the runtime classpath determines the required version numbers for identical dependencies on downstream classpaths.

Your app’s runtime classpath also determines the version numbers that Gradle requires for matching dependencies in the runtime classpath for the app’s test APK. The hierarchy of classpaths is described in figure 1.

Figure 1. Version numbers of dependencies that appear across multiple classpaths must match according to this hierarchy.

A conflict where different versions of the same dependency appears across multiple classpaths might occur when, for example, your app includes a version of a dependency using the implementation dependency configuration and a library module includes a different version of the dependency using the runtimeOnly configuration.

When resolving dependencies on your runtime and compile time classpaths, Android Gradle plugin 3.3.0 and higher attempt to automatically fix certain downstream version conflicts. For example, if the runtime classpath includes Library A version 2.0 and the compile classpath includes Library A version 1.0, the plugin automatically updates the dependency on the compile classpath to Library A version 2.0 to avoid errors.

However, if the runtime classpath includes Library A version 1.0 and the compile classpath includes Library A version 2.0, the plugin does not downgrade the dependency on the compile classpath to Library A version 1.0, and you still get an error similar to the following:

To resolve this issue, do one of the following:

  • Include the desired version of the dependency as an api dependency to your library module. That is, only your library module declares the dependency, but the app module will also have access to its API, transitively.
  • Alternatively, you can declare the dependency in both modules, but you should make sure that each module uses the same version of the dependency. Consider configuring project-wide properties to ensure versions of each dependency remain consistent throughout your project.

Apply custom build logic

This section describes advanced topics that are useful when you want to extend the Android Gradle plugin or write your own plugin.

Publish variant dependencies to custom logic

A library can have functionalities that other projects or sub-projects might want to use. Publishing a library is the process by which the library is made available to its consumers. Libraries can control which dependencies its consumers have access to at compile time and runtime.

There are two separate configurations that hold the transitive dependencies of each classpath which must be used by consumers to consume the library as described below:

  • variant_name ApiElements : This configuration holds the transitive dependencies that are available to consumers at compile time.
  • variant_name RuntimeElements : This configuration holds the transitive dependencies that are available to consumers at runtime.

To learn more about the relationships between the different configurations, go to The Java Library plugin configurations.

Custom dependency resolution strategies

A project may include a dependency on two different versions of the same library which can lead to dependency conflicts. For example, if your project depends on version 1 of module A and version 2 of module B, and module A transitively depends on version 3 of module B, there arises a dependency version conflict.

To resolve this conflict, the Android Gradle plugin uses the following dependency resolution strategy: when the plugin detects that different versions of the same module are in the dependency graph, by default, it chooses the one with the highest version number.

However, this strategy might not always work as you intend. To customize the dependency resolution strategy, use the following configurations to resolve specific dependencies of a variant that are needed for your task:

  • variant_name CompileClasspath : This configuration contains the resolution strategy for a given variant’s compile classpath.
  • variant_name RuntimeClasspath : This configuration contains the resolution strategy for a given variant’s runtime classpath.

The Android Gradle plugin includes getters that you can use to access the configuration objects of each variant. Thus, you can use the variant API to query the dependency resolution as shown in the example below:

Groovy

Kotlin

Dependency information for Play Console

When building your app using AGP 4.0.0 and higher, the plugin includes metadata that describes the library dependencies that are compiled into your app. When uploading your app, the Play Console inspects this metadata to provide alerts for known issues with SDKs and dependencies your app uses, and, in some cases, provide actionable feedback to resolve those issues.

The data is compressed, encrypted by a Google Play signing key, and stored in the signing block of your release app. We recommend keeping this dependencies file for a safe and positive user experience. However, if you’d rather not share this information, you can opt out by including the following dependenciesInfo block in your module’s build.gradle file:

For more information on our policies and potential issues with dependencies, see our support page on using third-party SDKs in your app.

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник

Читайте также:  Лучшие вещи для андроид
Оцените статью