Thrown an exception while enabling "AndroidUseAapt2" in application. #3123
Assignees
Labels
Area: App+Library Build
Issues when building Library projects or Application projects.
Milestone
Comments
Iyyappanmani
changed the title
Iyyappanmani
changed the title
jonpryor
added
the
Area: App+Library Build
|
Thanks for the bug report and the example, I have tested this on our latest internal preview (XA SDK 9.4.x) and I am able to reproduce this issue. I'll start taking a look to see what is happening. |
|
Looks like the |
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Jun 13, 2019
…roidUseAapt2" in application. Fixes dotnet#3123 Commit 373c6ed added a new `_ConvertCustomView` target to handle the conversion of custom view to the md5 hash versions. While it worked *most* of the time, there was a very specific area where it was not fixing up the custom views. This problem only occurs when a library project code is updated. When happens next is when the main app builds the library resources are then re-extracted to the `$(IntermediateOutputPath)lp\XX\ji\res` directory. The `ConvertResorucesCases` task is then run to fixup those `res` files with the correct casing. After than `GenerateJavaStubs` is then also run, this is because the library project was updated. However at this point the wheels fall of the wagon because `_ConvertCustomViews` does NOT run. this is because it is only using the following inputs. `$(_CustomViewMapFile);$(_AcwMapFile)` Neither of these files are updated in this instance. The acwmap file will only be updated if a class or namespace are changed. If code within a class is changed nothing the the acwmap will need to be updated, so we don't update the file. The `$(_CustomViewMapFile)` also does not be updated unless resources are added or removed. So that doesn't change either. The result is the target is skipped, and we end up with a custom view which does NOT have the correct md5 hash. This results in the following error at runtime. Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class InflatedLibrary.CodeBehindClass occurred The fix in this case is to update the Inputs of the `_ConvertCustomView` target to have the following `$(_CustomViewMapFile);$(_AcwMapFile);@(_AndroidResourceDest);@(_LibraryResourceDirectoryStamps)` By including these two extra items we can make sure the target runs if either an app resource is updated or if a library project is updated. A unit test has been updated to test for this particular issue.
jonpryor
pushed a commit
that referenced
this issue
Jun 14, 2019
Fixes: #3123 Scenario: 1. Create a Solution in which the `App.csproj` references a `MonoAndroid`-profile `Library.csproj` project. 2. `Library.csproj` contains an `Android.Views.View` subclass. 3. `Library.csproj` contains an `@(AndroidResource)` with a layout `.axml` file which uses the `View` from (2) 4. `App` project uses (2) with `Activity.SetContentView()`. 5. Build & Run the project; it works. 6. Update the `View` subclass from (2). 7. Build & run the project. Step (7) is expected to result in a successful app launch. Instead, it fails during process startup: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class InflatedLibrary.CodeBehindClass occurred Commit 373c6ed added a new `_ConvertCustomView` target to handle the conversion of custom view to the md5 hash versions. While it worked *most* of the time, there was a very specific area where it was not fixing up the custom views. This problem only occurs when a library project code is updated, as with step (6). When happens next is that when the main app builds and the library resources are then re-extracted into the `$(IntermediateOutputPath)lp\XX\ji\res` directory. The `<ConvertResorucesCases/>` task is then run to fixup those `res` files with the correct casing. Then the `<GenerateJavaStubs/>` task is run, because the library project was updated. However at this point the wheels fall of the wagon because the `_ConvertCustomViews` target does NOT run. This is because it is only using the following inputs: $(_CustomViewMapFile);$(_AcwMapFile) Neither of these files are updated in this instance. `$(_AcwMapFile)` will only be updated if a class or namespace are changed. If code within a class is changed in a way which doesn't alter the class or namespace name, then nothing in the ACW map will need to be updated, so we don't update the file. The `$(_CustomViewMapFile)` is also not updated, unless resources are added or removed. So that doesn't change either. The result is the target is skipped, and we end up with a custom view which does NOT have the correct type names. This results in the above error. The fix in this case is to update the Inputs of the `_ConvertCustomView` target to have the following $(_CustomViewMapFile);$(_AcwMapFile);@(_AndroidResourceDest);@(_LibraryResourceDirectoryStamps) By including these two extra items we can make sure the target runs if either an app resource is updated or if a library project changes. A unit test has been updated to test for this particular issue.
jonpryor
pushed a commit
that referenced
this issue
Jun 14, 2019
Fixes: #3123 Scenario: 1. Create a Solution in which the `App.csproj` references a `MonoAndroid`-profile `Library.csproj` project. 2. `Library.csproj` contains an `Android.Views.View` subclass. 3. `Library.csproj` contains an `@(AndroidResource)` with a layout `.axml` file which uses the `View` from (2) 4. `App` project uses (2) with `Activity.SetContentView()`. 5. Build & Run the project; it works. 6. Update the `View` subclass from (2). 7. Build & run the project. Step (7) is expected to result in a successful app launch. Instead, it fails during process startup: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class InflatedLibrary.CodeBehindClass occurred Commit 373c6ed added a new `_ConvertCustomView` target to handle the conversion of custom view to the md5 hash versions. While it worked *most* of the time, there was a very specific area where it was not fixing up the custom views. This problem only occurs when a library project code is updated, as with step (6). When happens next is that when the main app builds and the library resources are then re-extracted into the `$(IntermediateOutputPath)lp\XX\ji\res` directory. The `<ConvertResorucesCases/>` task is then run to fixup those `res` files with the correct casing. Then the `<GenerateJavaStubs/>` task is run, because the library project was updated. However at this point the wheels fall of the wagon because the `_ConvertCustomViews` target does NOT run. This is because it is only using the following inputs: $(_CustomViewMapFile);$(_AcwMapFile) Neither of these files are updated in this instance. `$(_AcwMapFile)` will only be updated if a class or namespace are changed. If code within a class is changed in a way which doesn't alter the class or namespace name, then nothing in the ACW map will need to be updated, so we don't update the file. The `$(_CustomViewMapFile)` is also not updated, unless resources are added or removed. So that doesn't change either. The result is the target is skipped, and we end up with a custom view which does NOT have the correct type names. This results in the above error. The fix in this case is to update the Inputs of the `_ConvertCustomView` target to have the following $(_CustomViewMapFile);$(_AcwMapFile);@(_AndroidResourceDest);@(_LibraryResourceDirectoryStamps) By including these two extra items we can make sure the target runs if either an app resource is updated or if a library project changes. A unit test has been updated to test for this particular issue.
|
Hi @jonpryor - we have faced this same issue even disable the aapt2 in release mode. Is anyone faced this in before |
|
@HemalathaMarikuma-syncfusion this issue is a bit old, can you file a new one including build logs? One thing to note is that enabling Android App Bundles forces aapt2 to be enabled. Just and idea, but maybe that is happening? |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to Reproduce
We have created the sample to reproduce the issue.
In our sample, we have created the one custom control that contains the layout from axml and it has been inflated in our library project.
In our application project, we have only added that custom control into the view and we are facing the below error at the time of enabling the AndroidUseAapt2 in our application.
Expected Behavior
It should run without any exception.
Actual Behavior
It has thrown the runtime exception as shown below.
Basic Information
Screenshots
Error log: Unhandled Exception:
Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class InflatedLibrary.CodeBehindClass occurred
Sample
Sample
The text was updated successfully, but these errors were encountered: