[Xamarin.Android.Build.Tasks] Thrown an exception while enabling "AndroidUseAapt2" in application. #3218
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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.
jonathanpeppers
approved these changes
Jun 13, 2019
jonpryor
pushed a commit
that referenced
this pull request
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.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #3123
Commit 373c6ed added a new
_ConvertCustomViewtarget tohandle 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\resdirectory. TheConvertResorucesCasestask is then run to fixup thoseresfiles with the correct casing. After than
GenerateJavaStubsis then also run, this is because the library project was
updated.
However at this point the wheels fall of the wagon because
_ConvertCustomViewsdoes NOT run. this is because itis only using the following inputs.
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 unlessresources 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.
The fix in this case is to update the Inputs of the
_ConvertCustomViewtarget to have the following
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.