Android studio apply plugin

Failed to apply plugin [id ‘com.android.internal.application’] — Android studio — Troubleshooting

This troubleshooting resolves the error Failed to apply plugin [id ‘com.android.internal.application’] in android studio.

We encountered a compilation error after a big update to the gradle tool. In this tutorial dedicated to troubleshooting computer errors we will try to provide the solution that worked (for us anyway) !!

Problem

While compiling your android application you find the error below:

If this is your case, the help would be much simpler than it seems.

Solution

To solve this problem just remove the script line below from the file gradle.properties

The file gradle.properties is at the root of your project. It is difficult to miss it.

Conclusion

Android Studio 4.1 Development Essentials — Kotlin Edition: Developing Android 11 Apps Using Android Studio 4.1, Kotlin and Android Jetpack (English Edition)

Completely updated for Android Studio 4.1, the goal of this book is to teach the skills necessary to develop Android-based applications using the Kotlin programming language.

Starting with the basics, this book provides an overview of the steps required to set up an Android development and testing environment, followed by an introduction to programming in Kotlin, including data types, flow control, functions. , lambdas and object oriented programming.

An overview of Android Studio is included, covering areas such as tool windows, the code editor, and the Layout Editor tool. An introduction to the architecture of Android is followed by an in-depth review of the design of Android applications and user interfaces using the Android Studio environment.

See the offer

• Do you have any stories to tell us? Go to the page Guest post to find out how to do it.

To advertise on TediDev, see the page advertising and sponsors

find us on Facebook , Twitter et Instagram so as not to miss anything.

Источник

Android studio apply plugin

buildscript <
repositories <
jcenter()
>

dependencies <
classpath ‘com.android.tools.build:gradle:1.3.1’
>
>

apply plugin: ‘com.android.application’

android <
compileSdkVersion 23
buildToolsVersion «23.1.0»
>

There are 3 main areas to this Android build file:

buildscript configures the code driving the build. In this case, this declares that it uses the jCenter repository, and that there is a classpath dependency on a Maven artifact. This artifact is the library that contains the Android plugin for Gradle in version 1.3.1. Note: This only affects the code running the build, not the project. The project itself needs to declare its own repositories and dependencies. This will be covered later.

Then, the com.android.application plugin is applied. This is the plugin used for building Android applications.

Finally, android configures all the parameters for the android build. This is the entry point for the Android DSL. By default, only the compilation target, and the version of the build-tools are needed. This is done with the compileSdkVersion and buildtoolsVersion properties.

The compilation target is the same as the target property in the project.properties file of the old build system. This new property can either be assigned a int (the api level) or a string with the same value as the previous target property.

Important: You should only apply the com.android.application plugin. Applying the java plugin as well will result in a build error.

Note: You will also need a local.properties file to set the location of the SDK in the same way that the existing SDK requires, using the sdk.dir property.
Alternatively, you can set an environment variable called ANDROID_HOME . There is no differences between the two methods, you can use the one you prefer. Example local.properties file:

Project Structure

Configuring the Structure

android <
sourceSets <
main <
manifest.srcFile ‘AndroidManifest.xml’
java.srcDirs = [‘src’]
resources.srcDirs = [‘src’]
aidl.srcDirs = [‘src’]
renderscript.srcDirs = [‘src’]
res.srcDirs = [‘res’]
assets.srcDirs = [‘assets’]
>

Build Tasks

General Tasks

• assemble
  The task to assemble the output(s) of the project.
• check
  The task to run all the checks.
• build
  This task does both assemble and check.
• clean
  This task cleans the output of the project.

The tasks assemble , check and build don’t actually do anything. They are «anchor» tasks for the plugins to add dependent tasks that actually do the work.

This allows you to always call the same task(s) no matter what the type of project is, or what plugins are applied. For instance, applying the findbugs plugin will create a new task and make check depend on it, making it be called whenever the check task is called.

From the command line you can get the high level task running the following command:

Java project tasks

Here are the two most important tasks created by the java plugin, dependencies of the main anchor tasks:

• assemble
  • jar
    This task creates the output.
• check
  • test
    This task runs the tests.

The jar task itself will depend directly and indirectly on other tasks: classes for instance will compile the Java code. The tests are compiled with testClasses , but it is rarely useful to call this as test depends on it (as well as classes ).

In general, you will probably only ever call assemble or check, and ignore the other tasks. You can see the full set of tasks and their descriptions for the Java plugin here.

Android tasks

The new anchor tasks are necessary in order to be able to run regular checks without needing a connected device. Note that build does not depend on deviceCheck, or connectedCheck.

An Android project has at least two outputs: a debug APK and a release APK. Each of these has its own anchor task to facilitate building them separately:

• assemble
  • assembleDebug
  • assembleRelease

They both depend on other tasks that execute the multiple steps needed to build an APK. The assemble task depends on both, so calling it will build both APKs.

Tip: Gradle support camel case shortcuts for task names on the command line. For instance:

as long as no other task matches ‘aR’

The check anchor tasks have their own dependencies:

• check
  • lint
• connectedCheck
  • connectedA ndroidTest
• deviceCheck
  • This depends on tasks created when other plugins implement test extension points.

Finally, the plugin creates tasks for installing and uninstalling all build types ( debug , release , test ), as long as they can be installed (which requires signing), e.g.

• installDebug
• installRelease
• uninstallAll
  • uninstallDebug
  • uninstallRelease
  • uninstallDebugAndroidTest

Basic Build Customization

Manifest entries

android <
compileSdkVersion 23
buildToolsVersion «23.0.1»

defaultConfig <
versionCode 12
versionName «2.0»
minSdkVersion 16
targetSdkVersion 23
>
>

android <
compileSdkVersion 23
buildToolsVersion «23.0.1»

defaultConfig <
versionCode 12
v ersionName computeVersionName()
minSdkVersion 16
targetSdkVersion 23
>
>

Build Types

This configuration is done through an object called a BuildType . By default, 2 instances are created, a debug and a release one. The Android plugin allows customizing those two instances as well as creating other Build Types. This is done with the buildTypes DSL container:

In addition to modifying build properties, Build Types can be used to add specific code and resources. For each Build Type, a new matching sourceSet is created, with a default location of src/ / , e.g. src/debug/java directory can be used to add sources that will only be compiled for the debug APK. This means the Build Type names cannot be main or androidTest (this is enforced by the plugin), and that they have to be unique.

Additionally, for each Build Type, a new assemble task is created, e.g. assembleDebug . The assembleDebug and assembleRelease tasks have already been mentioned, and this is where they come from. When the debug and release Build Types are pre-created, their tasks are automatically created as well. According to this rule, build.gradle snippet above will also generate an assembleJnidebug task, and assemble would be made to depend on it the same way it depends on the assembleDebug and assembleRelease tasks.

Tip: remember that you can type gradle aJ to run the assembleJnidebug task.

Possible use case:

• Permissions in debug mode only, but not in release mode
• Custom implementation for debugging
• Different resources for debug mode (for instance when a resource value is tied to the signing certificate).

The code/resources of the BuildType are used in the following way:

• The manifest is merged into the app manifest
• The code acts as just another source folder
• The resources are overlayed over the main resources, replacing existing values.

Signing Configurations

• A keystore
• A keystore password
• A key alias name
• A key password
• The store type

The location, as well as the key name, both passwords and store type form together a Signing Configuration. By default, there is a debug configuration that is setup to use a debug keystore, with a known password and a default key with a known password.
The debug keystore is located in $HOME/.android/debug.keystore , and is created if not present. The debugBuild Type is set to use this debugSigningConfig automatically.

android <
signingConfigs <
debug <
storeFile file(«debug.keystore»)
>

myConfig <
storeFile file(«other.keystore»)
storePassword «android»
keyAlias «androiddebugkey»
keyPassword «android»
>
>

buildTypes <
foo <
signingConfig signingConfigs.myConfig
>
>
>

The above snippet changes the location of the debug keystore to be at the root of the project. This automatically impacts any Build Types that are set to using it, in this case the debug Build Type. It also creates a new Signing Config and a new Build Type that uses the new configuration.

Note: Only debug keystores located in the default location will be automatically created. Changing the location of the debug keystore will not create it on-demand. Creating a SigningConfig with a different name that uses the default debug keystore location will create it automatically. In other words, it’s tied to the location of the keystore, not the name of the configuration.

Note: Location of keystores are usually relative to the root of the project, but could be absolute paths, thought it is not recommended (except for the debug one since it is automatically created).

Dependencies, Android Libraries and Multi-project setup

Dependencies on binary packages

Local packages

To configure a dependency on an external library jar, you need to add a dependency on the compile configuration. The snippet below adds a dependency on all jars inside the libs directory.

dependencies <
compile fileTree(dir: ‘libs’, include: [‘*.jar’])
>

Note: the dependencies DSL element is part of the standard Gradle API and does not belong inside the android element.

The compile configuration is used to compile the main application. Everything in it is added to the compilation classpath and also packaged in the final APK. There are other possible configurations to add dependencies to:

• compile: main application
• androidTestCompile: test application
• debugCompile: debug Build Type
• releaseCompile: release Build Type.

Because it’s not possible to build an APK that does not have an associated Build Type, the APK is always configured with two (or more) configurations: compile and Compile . Creating a new Build Type automatically creates a new configuration based on its name. This can be useful if the debug version needs to use a custom library (to report crashes for instance), while the release doesn’t, or if they rely on different versions of the same library (see Gradle documentation on details of how version conflicts are handled).

Remote artifacts

dependencies <
compile ‘com.google.guava:guava:18.0’
>

Note: jcenter() is a shortcut to specifying the URL of the repository. Gradle supports both remote and local repositories.
Note: Gradle will follow all dependencies transitively. This means that if a dependency has dependencies of its own, those are pulled in as well.

For more information about setting up dependencies, read the Gradle user guide here, and DSL documentation here.

Multi project setup

The :app project is likely to depend on the libraries, and this is done by declaring the following dependencies:

Library projects

Creating a Library Project

buildscript <
repositories <
jcenter()
>

dependencies <
classpath ‘com.android.tools.build:gradle:1.3.1’
>
>

apply plugin: ‘com.android.library’

android <
compileSdkVersion 23
buildToolsVersion «23.0.1»
>

Differences between a Project and a Library Project

Referencing a Library

Referencing a library is done the same way any other project is referenced:

Library Publication

Testing

Unit testing

Basics and Configuration

As seen previously, those are configured in the defaultConfig object:

The value of the targetPackage attribute of the instrumentation node in the test application manifest is automatically filled with the package name of the tested app, even if it is customized through the defaultConfig and/or the Build Type objects. This is one of the reason this part of the manifest is generated automatically.

Additionally, the androidTest source set can be configured to have its own dependencies. By default, the application and its own dependencies are added to the test app classpath, but this can be extended with the snippet below:

The test app is built by the assembleAndroidTest task. It is not a dependency of the main assemble task, and is instead called automatically when the tests are set to run.

Currently only one Build Type is tested. By default it is the debug Build Type, but this can be reconfigured with:

Resolving conflicts between main and test APK

Running tests

• Ensure the app and the test app are built (depending on assembleDebug and assembleDebugAndroidTest ).
• Install both apps.
• Run the tests.
• Uninstall both apps.

If more than one device is connected, all tests are run in parallel on all connected devices. If one of the test fails, on any device, the build will fail.

Testing Android Libraries

Test reports

Multi-projects reports

In a multi project setup with application(s) and library(ies) projects, when running all tests at the same time, it might be useful to generate a single reports for all tests.

To do this, a different plugin is available in the same artifact. It can be applied with:

buildscript <
repositories <
jcenter()
>

dependencies <
classpath ‘com.android.tools.build:gradle:0.5.6’
>
>

apply plugin: ‘android-reporting’

This should be applied to the root project, ie in build.gradle next to settings.gradle

Then from the root folder, the following command line will run all the tests and aggregate the reports:

Lint support

Build Variants

One goal of the new build system is to enable creating different versions of the same application.

There are two main use cases:

1. Different versions of the same application
   For instance, a free/demo version vs the “pro” paid application.
2. Same application packaged differently for multi-apk in Google Play Store.
   See http://developer.android.com/google/play/publishing/multiple-apks.html for more information.
3. A combination of 1. and 2.

The goal was to be able to generate these different APKs from the same project, as opposed to using a single Library Projects and 2+ Application Projects.

Product flavors

A product flavor defines a customized version of the application build by the project. A single project can have different flavors which change the generated application.

This new concept is designed to help when the differences are very minimum. If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects.

Product flavors are declared using a productFlavors DSL container:

Build Type + Product Flavor = Build Variant

Product Flavor Configuration

Each flavors is configured with a closure:

defaultConfig <
minSdkVersion 8
versionCode 10
>

productFlavors <
flavor1 <
applicationId «com.example.flavor1»
versionCode 20
>

flavor2 <
applicationId «com.example.flavor2»
minSdkVersion 14
>
>
>

Note that the android.productFlavors.* objects are of type ProductFlavor which is the same type as the android.defaultConfig object. This means they share the same properties.

defaultConfig provides the base configuration for all flavors and each flavor can override any value. In the example above, the configurations end up being:

• flavor1
  • applicationId : com.example.flavor1
  • minSdkVersion : 8
  • versionCode : 20
• flavor2
  • applicationId : com.example.flavor2
  • minSdkVersion : 14
  • versionCode : 10

Usually, the Build Type configuration is an overlay over the other configuration. For instance, the Build Type‘s applicationIdSuffix is appended to the Product Flavor‘s applicationId . There are cases where a setting is settable on both the Build Type and the Product Flavor. In this case, it’s is on a case by case basis. For instance, signingConfig is one of these properties. This enables either having all release packages share the same SigningConfig, by setting android.buildTypes.release.signingConfig , or have each release package use their own SigningConfig by setting each android.productFlavors.*.signingConfig objects separately.

Sourcesets and Dependencies

• android.sourceSets.flavor1Debug
  Location src/flavor1Debug/
• android.sourceSets.flavor1Release
  Location src/flavor1Release/
• android.sourceSets.flavor2Debug
  Location src/flavor2Debug/
• android.sourceSets.flavor2Release
  Location src/flavor2Release/

Building and Tasks

We previously saw that each Build Type creates its own assemble task, but that Build Variants are a combination of Build Type and Product Flavor.

When Product Flavors are used, more assemble-type tasks are created. These are:

1. assemble
2. assemble
3. assemble

#1 allows directly building a single variant. For instance assembleFlavor1Debug .

#2 allows building all APKs for a given Build Type. For instance assembleDebug will build both Flavor1Debug and Flavor2Debug variants.

#3 allows building all APKs for a given flavor. For instance assembleFlavor1 will build both Flavor1Debug and Flavor1Release variants.

The task assemble will build all possible variants.

Multi-flavor variants

In some case, one may want to create several versions of the same apps based on more than one criteria.
For instance, multi-apk support in Google Play supports 4 different filters. Creating different APKs split on each filter requires being able to use more than one dimension of Product Flavors.

Consider the example of a game that has a demo and a paid version and wants to use the ABI filter in the multi-apk support. With 3 ABIs and two versions of the application, 6 APKs needs to be generated (not counting the variants introduced by the different Build Types).
However, the code of the paid version is the same for all three ABIs, so creating simply 6 flavors is not the way to go.
Instead, there are two dimensions of flavors, and variants should automatically build all possible combinations.

flavorDimensions «abi», «version»

productFlavors <
freeapp <
dimension «version»
.
>

paidapp <
dimension «version»
.
>

The android.flavorDimensions array defines the possible dimensions, as well as the order. Each defined Product Flavor is assigned to a dimension.

From the following dimensioned Product Flavors [freeapp, paidapp] and [x86, arm, mips] and the [debug, release] Build Types, the following build variants will be created:

• x86-freeapp-debug
• x86-freeapp-release
• arm-freeapp-debug
• arm-freeapp-release
• mips-freeapp-debug
• mips-freeapp-release
• x86-paidapp-debug
• x86-paidapp-release
• arm-paidapp-debug
• arm-paidapp-release
• mips-paidapp-debug
• mips-paidapp-release

The order of the dimension as defined by android.flavorDimensions is very important.

Each variant is configured by several Product Flavor objects:

• android.defaultConfig
• One from the abi dimension
• One from the version dimension

The order of the dimension drives which flavor override the other, which is important for resources when a value in a flavor replaces a value defined in a lower priority flavor.
The flavor dimension is defined with higher priority first. So in this case:

• android.sourceSets.x86Freeapp
  Location src/x86Freeapp/
• android.sourceSets.armPaidapp
  Location src/armPaidapp/
• etc.

Testing

Testing multi-flavors project is very similar to simpler projects.

The androidTest sourceset is used for common tests across all flavors, while each flavor can also have its own tests.

As mentioned above, sourceSets to test each flavor are created:

• android.sourceSets.androidTestFlavor1
  Location src/androidTestFlavor1/
• android.sourceSets.androidTestFlavor2
  Location src/androidTestFlavor2/

Similarly, those can have their own dependencies:

Running the tests can be done through the main deviceCheck anchor task, or the main androidTest tasks which acts as an anchor task when flavors are used.

Each flavor has its own task to run tests: androidTest . For instance:

• androidTestFlavor1Debug
• androidTestFlavor2Debug

Similarly, test APK building tasks and install/uninstall tasks are per variant:

• assembleFlavor1Test
• installFlavor1Debug
• installFlavor1Test
• uninstallFlavor1Debug
• .

Finally the HTML report generation supports aggregation by flavor.
The location of the test results and reports is as follows, first for the per flavor version, and then for the aggregated one:

• build/androidTest-results/flavors/
• build/androidTest-results/all/
• build/reports/androidTests/flavors
• build/reports/androidTests/all/

Customizing either path, will only change the root folder and still create sub folders per-flavor and aggregated results/reports.

BuildConfig

• boolean DEBUG – if the build is debuggable.
• int VERSION_CODE
• String VERSION_NAME
• String APPLICATION_ID
• String BUILD_TYPE – name of the build type, e.g. «release»
• String FLAVOR – name of the flavor, e.g. «paidapp»

• String FLAVOR = «armFreeapp»
• String FLAVOR_abi = «arm»
• String FLAVOR_version = «freeapp»

Filtering Variants

android <
productFlavors <
realData
fakeData
>

variantFilter < variant ->
def names = variant.flavors*.name

if (names.contains(«fakeData») && variant.buildType.name == «release») <
variant.ignore = true
>
>
>

• realDataDebug
• realDataRelease
• fakeDataDebug

See the DSL reference for all properties of variant that you can check.

Advanced Build Customization

Running ProGuard

• proguard-android.txt
• proguard-android-optimize.txt

Shrinking Resources

Basic Java projects have a finite set of tasks that all work together to create an output.
The classes task is the one that compile the Java source code.
It’s easy to access from build.gradle by simply using classes in a script. This is a shortcut for project.tasks.classes .

In Android projects, this is a bit more complicated because there could be a large number of the same task and their name is generated based on the Build Types and Product Flavors.

In order to fix this, the android object has two properties:

• applicationVariants (only for the app plugin)
• libraryVariants (only for the library plugin)
• testVariants (for both plugins)

All three return a DomainObjectCollection of ApplicationVariant , LibraryVariant , and TestVariant objects respectively.

Note that accessing any of these collections will trigger the creations of all the tasks. This means no (re)configuration should take place after accessing the collections.

The DomainObjectCollection gives access to all the objects directly, or through filters which can be convenient.

All three variant classes share the following properties:

Property Name	Property Type	Description
name	String	The name of the variant. Guaranteed to be unique.
description	String	Human readable description of the variant.
dirName	String	subfolder name for the variant. Guaranteed to be unique. Maybe more than one folder, ie “debug/flavor1”
baseName	String	Base name of the output(s) of the variant. Guaranteed to be unique.
outputFile	File	The output of the variant. This is a read/write property
processManifest	ProcessManifest	The task that processes the manifest.
aidlCompile	AidlCompile	The task that compiles the AIDL files.
renderscriptCompile	RenderscriptCompile	The task that compiles the Renderscript files.
mergeResources	MergeResources	The task that merges the resources.
mergeAssets	MergeAssets	The task that merges the assets.
processResources	ProcessAndroidResources	The task that processes and compile the Resources.
generateBuildConfig	GenerateBuildConfig	The task that generates the BuildConfig class.
javaCompile	JavaCompile	The task that compiles the Java code.
processJavaResources	Copy	The task that process the Java resources.
assemble	DefaultTask	The assemble anchor task for this variant.

The ApplicationVariant class adds the following:

Property Name	Property Type	Description
buildType	BuildType	The BuildType of the variant.
productFlavors	List	The ProductFlavors of the variant. Always non Null but could be empty.
mergedFlavor	ProductFlavor	The merging of android.defaultConfig and variant.productFlavors
signingConfig	SigningConfig	The SigningConfig object used by this variant
isSigningReady	boolean	true if the variant has all the information needed to be signed.
testVariant	BuildVariant	The TestVariant that will test this variant.
dex	Dex	The task that dex the code. Can be null if the variant is a library.
packageApplication	PackageApplication	The task that makes the final APK. Can be null if the variant is a library.
zipAlign	ZipAlign	The task that zipaligns the apk. Can be null if the variant is a library or if the APK cannot be signed.
install	DefaultTask	The installation task. Can be null.
uninstall	DefaultTask	The uninstallation task.

The LibraryVariant class adds the following:

Property Name	Property Type	Description
buildType	BuildType	The BuildType of the variant.
mergedFlavor	ProductFlavor	The defaultConfig values
testVariant	BuildVariant	The Build Variant that will test this variant.
packageLibrary	Zip	The task that packages the Library AAR archive. Null if not a library.

The TestVariant class adds the following:

Property Name	Property Type	Description
buildType	BuildType	The BuildType of the variant.
productFlavors	List	The ProductFlavors of the variant. Always non Null but could be empty.
mergedFlavor	ProductFlavor	The merging of android.defaultConfig and variant.productFlavors
signingConfig	SigningConfig	The SigningConfig object used by this variant
isSigningReady	boolean	true if the variant has all the information needed to be signed.
testedVariant	BaseVariant	The BaseVariant that is tested by this TestVariant.
dex	Dex	The task that dex the code. Can be null if the variant is a library.
packageApplication	PackageApplication	The task that makes the final APK. Can be null if the variant is a library.
zipAlign	ZipAlign	The task that zipaligns the apk. Can be null if the variant is a library or if the APK cannot be signed.
install	DefaultTask	The installation task. Can be null.
uninstall	DefaultTask	The uninstallation task.
connectedAndroidTest	DefaultTask	The task that runs the android tests on connected devices.
providerAndroidTest	DefaultTask	The task that runs the android tests using the extension API. Also note, that except for the ZipAlign task type, all other types require setting up private data to make them work. This means it’s not possible to manually create new tasks of these types. This API is subject to change. In general the current API is around giving access to the outputs and inputs (when possible) of the tasks to add extra processing when required). Feedback is appreciated, especially around needs that may not have been foreseen. For Gradle tasks (DefaultTask, JavaCompile, Copy, Zip), refer to the Gradle documentation. Источник Читайте также:  Android supported os version Оцените статью Вам также может понравиться Как деактивировать режим наушников на смартфоне с Android? Когда к мобильному устройству присоединены наушники Обзор игры Джелли-Джу для Android В последние годы популярность мобильных игр резко возросла Лучшие шахматные приложения для iOS и Android Нынешний читерский скандал в шахматном мире сейчас Что хотят увидеть пользователи от Android 5.0 Key Lime Pie ОС Google Android развивается, и по всему видимому Правообладателям Политика конфиденциальности Контакты