Aapt error file failed to compile

Understanding resource conflicts in Android

• Android
• Libraries
• Build Process

During Android development we often have to manage many different resources. At compilation time these resources are all gathered up and merged together into a single package.

As per the ‘The build process’ in the Configure your build documentation

1. The compilers convert your source code into DEX (Dalvik Executable) files, which include the bytecode that runs on Android devices, and everything else into compiled resources.

1. The APK Packager combines the DEX files and compiled resources into a single APK. …

But what happens if there is a resource naming collision? Turns out that “it depends”, especially when libraries are involved. In this article we’ll explore some different resource collision cases and look at what it means to have good resource naming hygiene.

In the App Module

In the simplest case we have a collision between two resources with the same name and type in the same file, like in the following example:

Attempting to compile this results in a very self explanatory error message:

Similarly if we were to define these resources over multiple files:

We get a similar compilation error, however this time listing both files involved in the conflict:

The way resources work in Android starts to become apparent. In our app module we need to be able to resolve a unique resource for the combination of type, name and device configuration. That is, there needs to be only one resolvable value for string/hello_world when referenced from the app module. We (the developer) are expected to resolve this conflict by either removing the resource (if it is a duplicate), renaming one of the instances or by moving one instance to a resource file with an appropriate qualifier. More information on resources and qualifiers can be found in the App resources overview documentation.

Library and App Module

The next case we’ll investigate is when we have a resource defined in a library module and the duplicate defined in our app module:

Attempting to compile this… succeeds! From our previous discoveries we can now infer that Android must have a rule for resolving a single value for string/hello when encountering this scenario.

As per the Create an Android library documentation

The build tools merge resources from a library module with those of a dependent app module. If a given resource ID is defined in both modules, the resource from the app is used.

However what implications does this have when building a modularised application? Say we define the following view in our library:

Looking at the preview for this view shows us:

And now when we decide to include the text view layout in a layout inside the app module:

When looking at the preview / the running application we can see that the text displays as:

Not only does accessing string/hello from a layout in the app module resolve to “Hello from the App!” but the app module’s version is also used for layouts included from libraries! For this reason we need to be wary of overriding resources defined in libraries when we don’t mean to.

Two Libraries

In the final case we’ll look at what happens when conflicting resources are defined in two libraries. Following on from our previous example, if we have a setup like:

What will be rendered for the value string/hello ? Turns out it depends on the ordering of dependencies in our app’s build.gradle .

Again from the Create an Android library documentation

If conflicts occur between multiple AAR libraries, then the resource from the library listed first in the dependencies list (toward the top of the dependencies block) is used.

This means for the configuration:

The value of string/hello will be Hello from Library 1! . Subsequently if the two implementation lines are reordered such that implementation project(«:library2») comes before implementation project(«:library1») then the value will be Hello from Library 2! . This is quite a subtle effect and it’s pretty easy to see how it could result in unintended behaviour for our application.

Custom Attributes

So far all of our examples have been making use of string resources, however an interesting resource type to take particular notice of is custom attributes.

Consider the following definition:

One may think that the following would compile without issue, however when defined in the app module we get the following compilation error:

And if each custom attribute is defined across two libraries like so:

It… compiles. However if we change library2’s definition to be a different format (e.g. ) we get the much more obtuse compilation error:

One important part of the message to look into is: mergeDebugResources/merged.dir/values/values.xml: AAPT: error: file failed to compile.

What’s going on here? The compilation of values.xml actually refers to the generation of the R class for the app module. During this compilation AAPT is trying to generate a single value for each of the properties for our R class. For each custom attribute inside a styleable there are actually two R class values which are generated. The first is the styleable name spaced value (under R.styleable ), the second is the global value (under R.attr ). For our particular case we are getting a collision on the global value, and due to the naming collision there are only three values to resolve as detailed below:

• R.styleable.CustomStyleable_freeText which is the value from library1 resolves to the attribute freeText with a format of string
• R.styleable.CustomStyleable2_freeText which is the value from library2 resolved to the attribute freeText with a format of boolean
• R.attr.freeText this value cannot be resolved as we have included values from both library1 and library2 and their format’s differ, this causes a collision.

In the first case where the format was the same across libraries R.attr.freeText was resolved to a single definition for the app module.

It’s worth noting at this time that each module has its own R class generated. We can’t always expect the value to remain consistent across our modules. Again from the Create an Android library documentation

When you build the dependent app modules, library modules are compiled into an AAR file then added to the app module. Therefore, each library has its own R class, named according to the library’s package name. The R class generated from main module and the library module is created in all the packages that are needed including the main module’s package and the libraries’ packages.

Conclusion

So what do we take away from all of this? That resource compilation is complex and nuanced? Well actually, yes. However there are things that we can do as a developer to make what is going on obvious to ourselves and our team, namely resource prefixing. From our favourite Create an Android library documentation there is this hidden gem:

To avoid resource conflicts for common resource IDs, consider using a prefix or other consistent naming scheme that is unique to the module (or is unique across all project modules).

Taking on this advice, it would be a good idea to establish a pattern in our projects and teams where we prefix all resources in modules with the module name e.g. library_help_text . This has two side effects:

1. It decreases the chance of collision considerably.
2. It makes overrides explicit. E.g. creating library_help_text in the app module is now clearly overriding something in the library module. Sometimes we do want to perform these overrides and using prefixes helps to make it clear what is occurring during the build process.

At a minimum all public resources should be prefixed, especially when distributing our library as a vendor or as an open source project. From experience not all of the resources in Google’s own library’s are prefixed appropriately. This can have the unfortunate side effect of the inclusion of our library causing an app compilation to fail due to a naming collision. Not a great look!

For instance we can see the material design library prefixes their color resources consistently with mtrl . However the attribute resources nested under a styleable are not prefixed with material . As we have seen, this has the potential to conflict when generating the R class for a module which includes both the material library and a library containing an attribute of the same name but different format .

Acknowledgements

The creation of this blog post was assisted by the following content:

Источник

Android resource compilation failed #115

I know it’s early but I got following error from Android Studio 3.2 Preview when using com.android.tools.build:gradle:3.2.0-alpha14 :

It’s easy to reproduce, just create an empty project with build tool version 3.2.0-alpha14 . And the following dependencies:

After somme research this seem to be linked with following resources:

I have been using Android studio Preview (from canary channel) for month now because the release version is slow on mac os hight sierra.

The text was updated successfully, but these errors were encountered:

Same issue. Any updates on this?

We haven’t had a chance to take a look at this yet, we’ll keep you updated once we do.
Thanks for understanding.

Should be fixed in version 5.12.3

I also have similar issue with AS Preview.

I’m having this same issue.
AS Preview Beta 1
Android Build Tools 3.2.0-beta01
implementation ‘io.smooch:core:5.13.1’
implementation ‘io.smooch:ui:5.13.1’

how to deal with this issue, thanks, same issue in my project.

The demo app is working for me with:

AS Preview Beta 2
Android Build Tools 3.2.0-beta02
implementation ‘io.smooch:core:5.13.1’
implementation ‘io.smooch:ui:5.13.1’

I have the same issue. Can someone tell why this error occurs?

is it possible to provide a sample project reproducing the issue? It’s working for me using the demo app with the latest AS preview

Follow this syntax

@pratheepchowdhary do you mean adding that resource to my app? Because I couldn’t reproduce the issue by doing that

same issue anyone got the answer

Active proguard and you’ll see app crashing. It’s probably happen because proguard are removing some classes and methods of library, so we need specify what is really needed for every possible case. How I need move on, I accepted evertything of the library as a non excluding file to proguard.

@pedrofsn running Proguard may fail because of a missing Glide method. If the error you are getting is

Add the following to your proguard config. We’ll include it in our next release:

I was also having the same error but I removed all nonresourece item from resource file. And it is working fine now.

it seems that the lastest version of android which is 28 will not work the format like :

it mean that google will not allow self define id values any more, after all the item fix , it really work.

how to solve this problem?

Same problem here, started with Android Studio 3.2.1 and buildToolsVersion ‘28.0.3’, but I cannot modify the autogenerated files, they generate again

Same here, AS 3.2.1 and buildTools 28.0.3. same issue.

what SDK version are you using? Can you provide a sample project or setup that reproduces the issue? I haven’t been able to reproduce, unfortunately

Android resource compilation failed
Output: values_values.arsc.flat: error: failed to open.

Command: C:UsersEZZECASH.gradlecachestransforms-1files-1.1aapt2-3.2.1-4818971-windows.jar6fd25df41b5b28f816048a23d6a0b147aapt2-3.2.1-4818971-windowsaapt2.exe compile —legacy
-o
C:UsersEZZECASHDesktopAhleHaqappbuildintermediatesresmergeddebug
C:UsersEZZECASHDesktopAhleHaqappbuildintermediatesincrementalmergeDebugResourcesmerged.dirvaluesvalues.xml
Daemon: AAPT2 aapt2-3.2.1-4818971-windows Daemon #0

I have this same issue. someone please help

SOLVED.
Ok so there hasn’t been a clear explanation to solve this issue but i just figured it out.
Thanks to landsnail. His explanation was correct but not geared to someone who has never built an app. So here is the step by step.

Go into your app project.
Navigate to the Resources folder (res)
Open values folder
Open ids.xml
— This should show you the list of all items that you created in the .xml files in the layouts folder
Each item should be of the format
the question marks should contain the id that you assigned the item that you created in your layouts files.
DO NOT put the name in be the name of the item in between . .
here is an example of what i did wrong
childText
this is what i did to correct it
type=»id»>`

there MUST be an for ever item that you created in your various layout .xml files.

Hope this helps someone

If you have an Antivirus or Antimalware service running somewhere, make sure you add exemptions to everything under Android Studio and the Sdk in (%applocaldata%)

Check also that Windows Defender’s Controlled Folder Access is On or Off and that you have added AS files on the whitelist. Restart Android Studio and the problem should be fixed.

how to solve this problem?

Failed to compile values file. how to fix this issue

this is my build.gradle

plugins <
id ‘com.android.application’
>

android <
compileSdkVersion 29
buildToolsVersion «30.0.2»

Источник

Android Studio 3.0 решение проблемы «AAPT2 error»

При попытке компиляции старых проектов или создании нового после обновления Android Studio до версии 3.0 вываливаются ошибки следующего вида:

Связано это с тем, что теперь по умолчанию используется AAPT2 (Android Asset Packaging Tool 2.0) и для решения проблемы обычно предлагают просто отказаться от неё. Это решение работает, однако это не решение самой проблемы, а лишь «кривой костыль».

Для отключения AAPT2 необходимо открыть файл gradle.properties , находящийся в корне проекта, и вставить строчку android.enableAapt2=false , после чего синхронизовать проект (File -> Synchronize или Crtl+Alt+Y).

Ошибочность такого подхода в том, что отключать использование AAPT2 в пользу старой версии придется вручную в каждом проекте, при этом старая версия может быть объявлена устаревшей и не факт, что в будущем её совсем не выпилят.

Поэтому разбираться надо с самой проблемой, а не закрывать на неё глаза. К тому же это весьма просто.

Если копнуть чуть глубже, то становится ясно, что ошибка вызвана с наличием кириллицы в пути к папке, в которой лежат ресурсы gradle. Связано это с тем, что AAPT2 дружит только с ASCII символами.

Исправляется сея беда следующим образом:

• Открываем настройки File -> Settings (CTRL+ALT+S)
• Ищем вкладку Build, Execution, Deployment -> Gradle
• Меняем путь, прописанный в поле Service directory path, на новый, не содержащий кириллицы.

После этого в новых проектах проблем не будет, а для старых надо просто произвести ребилд: Build -> Make Project (CTRL+F9)

Источник

Eclipse Turn AndroidStudio Aapt: Error: File Failed to Compile.

tags: diary  Summary  AndroidaApt error

compile 'com.android.support:support-v4:19.+'

implementation 'com.android.support:support-v4:19.+'

Intelligent Recommendation

More Recommendation

During Android development we often have to manage many different resources. At compilation time these resources are all gathered up and merged together into a single package.

As per the ‘The build process’ in the Configure your build documentation

1. The compilers convert your source code into DEX (Dalvik Executable) files, which include the bytecode that runs on Android devices, and everything else into compiled resources.

1. The APK Packager combines the DEX files and compiled resources into a single APK. …

But what happens if there is a resource naming collision? Turns out that “it depends”, especially when libraries are involved. In this article we’ll explore some different resource collision cases and look at what it means to have good resource naming hygiene.

In the App Module

In the simplest case we have a collision between two resources with the same name and type in the same file, like in the following example:

<!--strings.xml-->
<resources>
    <string name="hello_world">Hello World!</string>
    <string name="hello_world">Hello World!</string>
</resources>

Attempting to compile this results in a very self explanatory error message:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mergeDebugResources'.
> /.../strings.xml: Error: Found item String/hello_world more than one time

Similarly if we were to define these resources over multiple files:

<!--strings.xml-->
<resources>
    <string name="hello_world">Hello World!</string>
</resources>

<!--other_strings.xml-->
<resources>
    <string name="hello_world">Hello World!</string>
</resources>

We get a similar compilation error, however this time listing both files involved in the conflict:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mergeDebugResources'.
> [string/hello_world] /.../other_strings.xml
  [string/hello_world] /.../strings.xml: Error: Duplicate resources

The way resources work in Android starts to become apparent. In our app module we need to be able to resolve a unique resource for the combination of type, name and device configuration. That is, there needs to be only one resolvable value for string/hello_world when referenced from the app module. We (the developer) are expected to resolve this conflict by either removing the resource (if it is a duplicate), renaming one of the instances or by moving one instance to a resource file with an appropriate qualifier. More information on resources and qualifiers can be found in the App resources overview documentation.

Library and App Module

The next case we’ll investigate is when we have a resource defined in a library module and the duplicate defined in our app module:

<!--app/../strings.xml-->
<resources>
    <string name="hello">Hello from the App!</string>
</resources>

<!--library/../strings.xml-->
<resources>
    <string name="hello">Hello from the Library!</string>
</resources>

Attempting to compile this… succeeds! From our previous discoveries we can now infer that Android must have a rule for resolving a single value for string/hello when encountering this scenario.

As per the Create an Android library documentation

The build tools merge resources from a library module with those of a dependent app module. If a given resource ID is defined in both modules, the resource from the app is used.

However what implications does this have when building a modularised application? Say we define the following view in our library:

<!--library/../text_view.xml-->
<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/hello"
    xmlns:android="http://schemas.android.com/apk/res/android" />

Looking at the preview for this view shows us:

And now when we decide to include the text view layout in a layout inside the app module:

<!--app/../activity_main.xml-->
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:gravity="center"
    tools:context=".MainActivity"
    >

    <include layout="@layout/text_view" />

</LinearLayout>

When looking at the preview / the running application we can see that the text displays as:

Not only does accessing string/hello from a layout in the app module resolve to “Hello from the App!” but the app module’s version is also used for layouts included from libraries! For this reason we need to be wary of overriding resources defined in libraries when we don’t mean to.

Two Libraries

In the final case we’ll look at what happens when conflicting resources are defined in two libraries. Following on from our previous example, if we have a setup like:

<!--library1/../strings.xml-->
<resources>
    <string name="hello">Hello from Library 1!</string>
</resources>

<!--library2/../strings.xml-->
<resources>
    <string name="hello">Hello from Library 2!</string>
</resources>

<!--app/../activity_main.xml-->
<TextView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/hello" />

What will be rendered for the value string/hello? Turns out it depends on the ordering of dependencies in our app’s build.gradle.

Again from the Create an Android library documentation

If conflicts occur between multiple AAR libraries, then the resource from the library listed first in the dependencies list (toward the top of the dependencies block) is used.

This means for the configuration:

dependencies {
    implementation project(":library1")
    implementation project(":library2")
    ...
}

The value of string/hello will be Hello from Library 1!. Subsequently if the two implementation lines are reordered such that implementation project(":library2") comes before implementation project(":library1") then the value will be Hello from Library 2!. This is quite a subtle effect and it’s pretty easy to see how it could result in unintended behaviour for our application.

Custom Attributes

So far all of our examples have been making use of string resources, however an interesting resource type to take particular notice of is custom attributes.

Consider the following definition:

<!--app/../attrs.xml-->
<resources>
    <declare-styleable name="CustomStyleable">
        <attr name="freeText" format="string"/>
    </declare-styleable>

    <declare-styleable name="CustomStyleable2">
        <attr name="freeText" format="string"/>
    </declare-styleable>
</resources>

One may think that the following would compile without issue, however when defined in the app module we get the following compilation error:

Execution failed for task ':app:mergeDebugResources'.
> /.../attrs.xml: Error: Found item Attr/freeText more than one time

And if each custom attribute is defined across two libraries like so:

<!--library1/../attrs.xml-->
<resources>
    <declare-styleable name="CustomStyleable">
        <attr name="freeText" format="string"/>
    </declare-styleable>
</resources>

<!--library2/../attrs.xml-->
<resources>
    <declare-styleable name="CustomStyleable2">
        <attr name="freeText" format="string"/>
    </declare-styleable>
</resources>

It… compiles. However if we change library2’s definition to be a different format (e.g. <attr name="freeText" format="boolean"/>) we get the much more obtuse compilation error:

* What went wrong:
Execution failed for task ':app:mergeDebugResources'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
   > Android resource compilation failed
     /.../library2/build/intermediates/packaged_res/debug/values/values.xml:4:5-6:25: AAPT: error: duplicate value for resource 'attr/freeText' with config ''.
     /.../library2/build/intermediates/packaged_res/debug/values/values.xml:4:5-6:25: AAPT: error: resource previously defined here.
     /.../app/build/intermediates/incremental/mergeDebugResources/merged.dir/values/values.xml: AAPT: error: file failed to compile.

One important part of the message to look into is: mergeDebugResources/merged.dir/values/values.xml: AAPT: error: file failed to compile.

What’s going on here? The compilation of values.xml actually refers to the generation of the R class for the app module. During this compilation AAPT is trying to generate a single value for each of the properties for our R class. For each custom attribute inside a styleable there are actually two R class values which are generated. The first is the styleable name spaced value (under R.styleable), the second is the global value (under R.attr). For our particular case we are getting a collision on the global value, and due to the naming collision there are only three values to resolve as detailed below:

• R.styleable.CustomStyleable_freeText which is the value from library1 resolves to the attribute freeText with a format of string
• R.styleable.CustomStyleable2_freeText which is the value from library2 resolved to the attribute freeText with a format of boolean
• R.attr.freeText this value cannot be resolved as we have included values from both library1 and library2 and their format’s differ, this causes a collision.

In the first case where the format was the same across libraries R.attr.freeText was resolved to a single definition for the app module.

It’s worth noting at this time that each module has its own R class generated. We can’t always expect the value to remain consistent across our modules. Again from the Create an Android library documentation

When you build the dependent app modules, library modules are compiled into an AAR file then added to the app module. Therefore, each library has its own R class, named according to the library’s package name. The R class generated from main module and the library module is created in all the packages that are needed including the main module’s package and the libraries’ packages.

Conclusion

So what do we take away from all of this? That resource compilation is complex and nuanced? Well actually, yes. However there are things that we can do as a developer to make what is going on obvious to ourselves and our team, namely resource prefixing. From our favourite Create an Android library documentation there is this hidden gem:

To avoid resource conflicts for common resource IDs, consider using a prefix or other consistent naming scheme that is unique to the module (or is unique across all project modules).

Taking on this advice, it would be a good idea to establish a pattern in our projects and teams where we prefix all resources in modules with the module name e.g. library_help_text. This has two side effects:

1. It decreases the chance of collision considerably.
2. It makes overrides explicit.
   E.g. creating library_help_text in the app module is now clearly overriding something in the library module. Sometimes we do want to perform these overrides and using prefixes helps to make it clear what is occurring during the build process.

At a minimum all public resources should be prefixed, especially when distributing our library as a vendor or as an open source project. From experience not all of the resources in Google’s own library’s are prefixed appropriately. This can have the unfortunate side effect of the inclusion of our library causing an app compilation to fail due to a naming collision. Not a great look!

For instance we can see the material design library prefixes their color resources consistently with mtrl. However the attribute resources nested under a styleable are not prefixed with material. As we have seen, this has the potential to conflict when generating the R class for a module which includes both the material library and a library containing an attribute of the same name but different format.

Acknowledgements

The creation of this blog post was assisted by the following content:

• Android Resources collision without warning!
• Why Android cannot deal with Resources name conflict between Project and Library?