Gradle android plugin github
We are very sorry to announce that development of this plugin has been discontinued. Google has created their own Android development toolchain based on Gradle, which supercedes this plugin.
This is the Android plugin for the Gradle build system. This plugin enables the creation of Android applications using Gradle, with all of the power and flexibility you’ve come to expect from Gradle.
Currently, Gradle 1.0-rc-3 is required.
For mailing lists see the project page on Google Code: https://code.google.com/p/gradle-android-plugin/
Features of the Android plugin include:
- Compile, package, and install Android applications. (Including handling of Android resource files.)
- Sign application packages using the default debug key, or with a release key for publication to Android Market.
- Incorporation of ProGuard to ensure that applications have minimal memory footprint.
- Easily create Android applications in Scala (and possibly Groovy or Clojure).
The Android plugin fully integrates into the Gradle build lifecycle by extending the Java plugin. Furthermore, the incorporation of ProGuard into the build not only ensures that Android application packages are small and tight, it also trivially enables the use of Scala for Android application development simply by incorporating the existing Scala plugin into the build. ProGuard will include only those classes from the Scala library that are actually used by your Android application, resulting in an application package that is as small as possible.
TASKS AND LIFECYCLE
The Android plugin adds the following tasks and dependencies to the build:
To use the Android plugin for Gradle you must first create the application skeleton using the android command-line tool. For example:
This will create and Android application skeleton that you can immediately build using Ant. To build with Gradle instead, you must (1) create a build.gradle file that includes the Android plugin, and (2) either move the source code to the directory expected by Gradle, or tell Gradle to use the src directory of your project directly.
Create a build.gradle file in the root directory of the project, and include the Android plugin as follows:
The android create project command created the source code directly in the src directory of the project. The Android plugin tries to conform to the conventions established by Android’s Ant-based build, but in this case it is better to conform to Gradle’s «source sets» convention, since it allows you to have separate test source code, or to use multiple languages. Therefore, we recommend that the source should be moved to src/main/java instead. Once you’ve done this you can, of course, utilize Gradle’s source sets to their full extent by placing resources in src/main/resources, Scala source files in src/main/scala etc. However, if you prefer to keep your source code directly in the src directory (for example, if you need to retain compatibility with Ant) then you can do so by configuring the Java source set in your build.gradle file. Just add the following to build.gradle:
If your Android project was initially created by Eclipse rather than the android create project command, then you will have some additional setup work to do. The Android plugin for Gradle must be told the location of the Android SDK. When you create a project with the android create project command, the location is filled in for you by the application generator, but the Eclipse project generator does not provide this information to the project. Therefore, you must fill it in yourself. To do this, create (or edit) the local.properties file in the root of the project and add the sdk.dir property, referring to the location of your Android SDK installation:
Note that this file should not be checked in to your version control system as it will likely differ across various development environments. Alternatively, you can use the ANDROID_HOME environment variable instead.
Once you’ve performed these steps you can build your Android application by invoking the tasks described above.
A complete minimal but real-world example is as follows.
This build script configures the build to sign with a provided keystore. This configuration applies for every build (1). It also sets Gradle to expand properties in every resource file (2).
In this way you can get a full build with the command:
It processes all the resources, expanding them with properties from the project’s scope, compiles classes, packs them into the dex file, builds the apk, signs it with the provided keystore (but does not process it with proguard) and zipaligns the package, which is named -x.y.z.apk and placed in /build/distributions. You can see the proguard task is skipped from Gradle’s output during the build.
You can create several build configurations and choose which one to execute from the gradle command line. The task configureDebug (3) defines the Gradle classifier for the package name. Executing this build with the command:
creates a package with same steps than the default build, but the package name is project-x.y.z-debug.apk.
The task configureRelease (4) defines a release configuration task, which activate the proguard step. Again, you get the package named -x.y.z.apk in the same output directory.
To disable signing and get a signed apk with the debug key, you can remove the androidPackage configuration (1): if keyStore or keyAlias are null, the signing is skipped and the debug key is used. Of course, you can put the signing configuration in a dedicated configuration task and invoke that task in order to get a signed package (or not to call it for the debug signed package).
Also note that if you don’t supply password (that is, keyStorePassword or keyAliasPassword are null), Gradle asks for them on the command line (not very good for CI servers. ).
To install the generated apk onto a running emulator or a device connected with USB (and configured in debug mode), run:
This installs the default built package; as with previous examples, if you want to install the debug (or release) package, you have to issue:
The androidUninstall task unistalls the application from a running emulator or a device. There is no need to specify which package: there can be only one package to undeploy and it’s defined by the base package name of the application, from androidManifest.xml.
You can use Gradle to generate an Eclipse project for you. The Android plugin enhances this process by setting up the Eclipse project correctly for Android, which includes establishing the correct class path and inserting the Android builders into the build process.
To use the Eclipse integration, first make sure that you apply the Gradle Eclipse plugin in your build.gradle file:
Then you can generate the Eclipse project files as follows:
The plugin is able to run instrumentation tests for you on a connected device or emulator:
On projects that do not define any instrumentations in their manifest, this task will safely be skipped. By default, the task runs all tests in the given project, using Android’s default test runner. If you want more control, you can add a configure closure to your test project:
The ‘run’ method can you be used in different ways. If used as above, all tests will be run using the given test runner. The ‘options’ field can be used to route parameters to the Activity manager that’s used to run the instrumentation (cf. ‘adb shell am instrument’). Note that you don’t have to supply the «-w» parameter, that’s done by default.
You can also partition your test suite to run with different runners. Note that this only works if you don’t also have a more general runner configured as seen above. Currently, the plugin allows you to partition by test package and annotation:
Источник
Gradle android plugin github
Secrets Gradle Plugin for Android
A Gradle plugin for providing your secrets securely to your Android project.
This Gradle plugin reads secrets from a properties file not checked into version control, such as local.properties , and expose those properties as variables in the Gradle-generated BuildConfig class and in the Android manifest file.
DISCLAIMER: This plugin is primarily for hiding your keys from version control. Since your key is part of the static binary, your API keys are still recoverable by decompiling an APK. So, securing your key using other measures like adding restrictions (if possible) are recommended.
- Gradle-based Android project
- Android Gradle plugin 7.0.0
NOTE: Starting from v1.1.0, the plugin ID was changed to «com.google.android.libraries.mapsplatform.secrets-gradle-plugin» and the plugin is now being distributed via Google Maven (gMaven). You can still download previous versions of the plugin from Gradle’s plugin portal, but new versions will now only be distributed through gMaven.
- In your project’s root build.gradle file:
- In your app-level build.gradle file:
This plugin also supports library module type ( com.android.library ). Just install the plugin in your library-level build.gradle file and keys will be visible inside that module as well.
Snapshot releases, which are distributed via GitHub Packages, are also available for latest fixes. To use a snapshot release, add the following repository to your project-level build.gradle file:
Example contents of local.properties under your root project:
After applying the plugin and building your project, the API key then becomes accessible in two ways.
- As a variable accessible in your AndroidManifest.xml file:
The plugin can optionally be configured:
Build-Variant Specific Properties
To set build-variant specific properties (build type or flavor), create a properties file at the root directory of the project with the same name as the variant. For example, to set keys specific for the release build type, create a new file called release.properties containing release-specific keys.
Contributions to this library are always welcome and highly encouraged!
See CONTRIBUTING.md and CODE_OF_CONDUCT.md for more information on how to get started.
Apache 2.0. See LICENSE for more information.
About
A Gradle plugin for providing your secrets to your Android project.
Источник
Gradle android plugin github
Android cache fix Gradle plugin
Some Android plugin versions have issues with Gradle’s build cache feature. When applied to an Android project this plugin applies workarounds for these issues based on the Android plugin and Gradle versions.
- Supported Gradle versions: 5.4.1+
- Supported Android Gradle Plugin versions: 3.5.4, 3.6.4, 4.0.1, 4.1.3, 4.2.2, 7.0.3, 7.1.0-beta03, 7.2.0-alpha04
- Supported Kotlin versions: 1.3.70+
We only test against the latest patch versions of each minor version of Android Gradle Plugin. This means that although it may work perfectly well with an older patch version (say 3.6.2), we do not test against these older patch versions, so the latest patch version is the only version from that minor release that we technically support.
The Android cache fix plugin is compatible with the Gradle Configuration Cache when used in conjunction with Android Gradle Plugin 4.2.0 and above. Using the configuration cache with earlier versions of the Android Gradle Plugin is not supported.
Should I use this?
Take a look at the list of issues especially unresolved issues. If any of these apply to your project, you can use this plugin to solve them.
How can I discover issues?
You can discover issues by using the task input comparison tool in Gradle Enterprise. More information about how to diagnose cache misses here. You can compare the inputs of a build that seeds the build cache — typically CI — with a build that consumes from the build cache like a local developer build. If you discover an issue related to the Android Gradle Plugin, please file an issue in the Android Bug Tracker. You can also file an issue here and we can see if a workaround is possible.
Applying the plugin
This plugin should be applied anywhere the com.android.application or com.android.library plugins are applied. Typically, this can just be injected from the root project’s build.gradle (change ‘2.4.5’ to the latest version of the cache fix plugin here):
Note that if you are currently exporting schemas with the Room annotation processor, you will need to change how you specify the output directory according to the instructions here.
You can take a look at the list of issues that the plugin fixes by looking at the classes in org.gradle.android.workarounds . It contains a number of Workaround implementations annotated with @AndroidIssue . The Javadoc has a short description of the problem, and the annotation gives information about when the problem was introduced, what is the first version of the Android plugin that fixes it, and there’s a link to the issue on Android’s issue tracker:
The following caching issues are fixed by the cache fix plugin but unresolved in any current or upcoming preview release of the Android Gradle Plugin as of 2021-11-29.
Please star them if you are experiencing them in your project.
- CompileLibraryResourcesTask is not relocatable: https://issuetracker.google.com/issues/155218379
- MergeResources is not relocatable: https://issuetracker.google.com/issues/141301405
- Room annotation processor causes cache misses, doesn’t declare outputs, overlapping outputs, etc: https://issuetracker.google.com/issues/132245929
Most of the workarounds in this plugin should apply to your project without any changes. However, one workaround requires some extra configuration. The Room schema location workaround allows you to specify an output directory for Room schema exports without breaking caching for your Java and/or Kapt tasks where the annotation processor has been configured. There are various issues with how this annotation processor works (see https://issuetracker.google.com/issues/132245929 and https://issuetracker.google.com/issues/139438151) which this workaround attempts to mitigate. However, in order to do so in a manageable way, it imposes some restrictions:
- The schema export directory must be configured via the «room» project extension instead of as an explicit annotation processor argument. If an explicit annotation processor argument is provided, an exception will be thrown, instructing the user to configure it via the extension:
Groovy
- There can only be a single schema export directory for the project — you cannot configure variant-specific export directories. Schemas exported from different variants will be merged in the directory specified in the «room» extension.
MergeNativeLibs, StripDebugSymbols, MergeJavaResources, MergeSourceSetFolders, BundleLibraryClassesJar, DataBindingMergeDependencyArtifacts, LibraryJniLibs and ZipMerging Workarounds
It has been observed that caching the MergeNativeLibsTask , StripDebugSymbols , MergeJavaResources , MergeSourceSetFolders , BundleLibraryClassesJar , DataBindingMergeDependencyArtifacts , LibraryJniLibs and ZipMergingTask tasks rarely provide any significant positive avoidance savings. In fact, they frequently provide negative savings, especially when fetched from a remote cache node. As such, these workarounds actually disable caching for these tasks.
About
Gradle plugin to fix Android caching problems
Источник
