Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fast deploy of wearable project has regressed between d16-3 Preview 2 and Preview 3 #3562

Closed
pjcollins opened this issue Aug 29, 2019 · 4 comments · Fixed by #3569
Closed
Assignees

Comments

@pjcollins
Copy link
Member

Our fastdev support has regressed for wearable project types between d16-3 Preview 2 and Preview 3.

Steps to Reproduce

  1. Download and restore NuGets for: https://github.com/xamarin/monodroid-samples/tree/master/wear/DelayedConfirmation.
  2. msbuild /t:Install DelayedConfirmationApp\DelayedConfirmationApp.csproj
  3. msbuild /t:Install DelayedConfirmationApp\DelayedConfirmationApp.csproj

Expected Behavior

Second deploy with no code changes should be fast.

Actual Behavior

Second deploy with no code changes results in the .apk being rebuilt.

The issue appears to have been introduced somewhere in this diff: http://github.com/xamarin/xamarin-android/compare/21a650c170483a1ac99e1c4bf80d7ef3158ab281...489f2580373b0ddb2e1268a159e3eb935b2871a5

Version Information

d16-3 Preview 3

Log File

Binary logs for good and bad incrementalinstall attempts

@pjcollins pjcollins added this to the d16-3 milestone Aug 29, 2019
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Aug 30, 2019
Fixes: dotnet#3562

Our QA tests caught a regression where building a Xamarin.Android app
that includes an embedded Android Wear app would always rebuild.

This brought up a few things:

1. We have a `XamarinAndroidWearApplicationProject` class, but no
   tests using it?
2. What does our MSBuild targets even do for Wear projects?

~~ Tests ~~

In adding some tests, I had to fix a few other things:

* We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of
  `preview7`.
* `Xamarin.ProjectTools` was generating `csproj` files of an encoding
  that did not match:

    C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly.
        System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode.
        at System.Xml.XmlTextReaderImpl.Throw(Exception e)
        at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res)
        at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName)
        at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl)
        at System.Xml.XmlTextReaderImpl.Read()
        at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri)
        at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute()
        at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
        at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj]

The file was actually `utf-8` but we were generating:

    <?xml version="1.0" encoding="utf-16"?>

I reworked `Xamarin.ProjectTools` to fix this.

I was able to add a simple test that just build a wear project, and
then added a second test that reproduces the problem.

~~ The Problem ~~

Generally embedded Android Wear solutions:

* A main app references the Wear project.
* The main app grabs a few files from the Wear project: the APK and an
  xml configuration file and copies them into `obj\Debug\res`.

What was even weirder, since we put them in `@(AndroidResource)` the
`_GenerateAndroidResourceDir` MSBuild target would attempt to copy
these files to themselves. The same files paths were in
`@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`...

    <CopyIfChanged
        SourceFiles="@(_AndroidResolvedResources)"
        DestinationFiles="@(_AndroidResourceDest)"

The problem was we basically were copying these files and never adding
them to `@(_ModifiedResources)`. This meant that
`$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases:

    <Touch
        Files="$(_AndroidResFlagFile)"
        AlwaysCreate="True"
        Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' "
    />

Two fixes seemed to solve the issue:

* The `<PrepareWearApplicationFiles/>` task needs to return a
  `ModifiedFiles` output we can add to `@(_ModifiedResources)`.
* We should define the Wear files in `@(_AndroidResourceDest)` after
  the `<CopyIfChanged/>` call such as:

    <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" />

This way they are never part of `@(AndroidResource)`, since they are
auto-generated.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Sep 3, 2019
Fixes: dotnet#3562

Our QA tests caught a regression where building a Xamarin.Android app
that includes an embedded Android Wear app would always rebuild.

This brought up a few things:

1. We have a `XamarinAndroidWearApplicationProject` class, but no
   tests using it?
2. What does our MSBuild targets even do for Wear projects?

~~ Tests ~~

In adding some tests, I had to fix a few other things:

* We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of
  `preview7`.
* `Xamarin.ProjectTools` was generating `csproj` files of an encoding
  that did not match:

    C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly.
        System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode.
        at System.Xml.XmlTextReaderImpl.Throw(Exception e)
        at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res)
        at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName)
        at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl)
        at System.Xml.XmlTextReaderImpl.Read()
        at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri)
        at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute()
        at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
        at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj]

The file was actually `utf-8` but we were generating:

    <?xml version="1.0" encoding="utf-16"?>

I reworked `Xamarin.ProjectTools` to fix this.

I was able to add a simple test that just build a wear project, and
then added a second test that reproduces the problem.

~~ The Problem ~~

Generally embedded Android Wear solutions:

* A main app references the Wear project.
* The main app grabs a few files from the Wear project: the APK and an
  xml configuration file and copies them into `obj\Debug\res`.

What was even weirder, since we put them in `@(AndroidResource)` the
`_GenerateAndroidResourceDir` MSBuild target would attempt to copy
these files to themselves. The same files paths were in
`@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`...

    <CopyIfChanged
        SourceFiles="@(_AndroidResolvedResources)"
        DestinationFiles="@(_AndroidResourceDest)"

The problem was we basically were copying these files and never adding
them to `@(_ModifiedResources)`. This meant that
`$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases:

    <Touch
        Files="$(_AndroidResFlagFile)"
        AlwaysCreate="True"
        Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' "
    />

Two fixes seemed to solve the issue:

* The `<PrepareWearApplicationFiles/>` task needs to return a
  `ModifiedFiles` output we can add to `@(_ModifiedResources)`.
* We should define the Wear files in `@(_AndroidResourceDest)` after
  the `<CopyIfChanged/>` call such as:

    <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" />

This way they are never part of `@(AndroidResource)`, since they are
auto-generated.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Sep 3, 2019
Fixes: dotnet#3562

Our QA tests caught a regression where building a Xamarin.Android app
that includes an embedded Android Wear app would always rebuild.

This brought up a few things:

1. We have a `XamarinAndroidWearApplicationProject` class, but no
   tests using it?
2. What does our MSBuild targets even do for Wear projects?

~~ Tests ~~

In adding some tests, I had to fix a few other things:

* We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of
  `preview7`.
* `Xamarin.ProjectTools` was generating `csproj` files of an encoding
  that did not match:

    C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly.
        System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode.
        at System.Xml.XmlTextReaderImpl.Throw(Exception e)
        at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res)
        at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName)
        at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl)
        at System.Xml.XmlTextReaderImpl.Read()
        at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri)
        at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute()
        at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
        at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj]

The file was actually `utf-8` but we were generating:

    <?xml version="1.0" encoding="utf-16"?>

I reworked `Xamarin.ProjectTools` to fix this.

I was able to add a simple test that just build a wear project, and
then added a second test that reproduces the problem.

~~ The Problem ~~

Generally embedded Android Wear solutions:

* A main app references the Wear project.
* The main app grabs a few files from the Wear project: the APK and an
  xml configuration file and copies them into `obj\Debug\res`.

What was even weirder, since we put them in `@(AndroidResource)` the
`_GenerateAndroidResourceDir` MSBuild target would attempt to copy
these files to themselves. The same files paths were in
`@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`...

    <CopyIfChanged
        SourceFiles="@(_AndroidResolvedResources)"
        DestinationFiles="@(_AndroidResourceDest)"

The problem was we basically were copying these files and never adding
them to `@(_ModifiedResources)`. This meant that
`$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases:

    <Touch
        Files="$(_AndroidResFlagFile)"
        AlwaysCreate="True"
        Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' "
    />

Two fixes seemed to solve the issue:

* The `<PrepareWearApplicationFiles/>` task needs to return a
  `ModifiedFiles` output we can add to `@(_ModifiedResources)`.
* We should define the Wear files in `@(_AndroidResourceDest)` after
  the `<CopyIfChanged/>` call such as:

    <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" />

This way they are never part of `@(AndroidResource)`, since they are
auto-generated.
jonathanpeppers added a commit that referenced this issue Sep 6, 2019
)

* [Xamarin.Android.Build.Tasks] fix Android Wear incremental builds

Fixes: #3562

Our QA tests caught a regression where building a Xamarin.Android app
that includes an embedded Android Wear app would always rebuild.

This brought up a few things:

1. We have a `XamarinAndroidWearApplicationProject` class, but no
   tests using it?
2. What does our MSBuild targets even do for Wear projects?

~~ Tests ~~

In adding some tests, I had to fix a few other things:

* We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of
  `preview7`.
* `Xamarin.ProjectTools` was generating `csproj` files of an encoding
  that did not match:

    C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly.
        System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode.
        at System.Xml.XmlTextReaderImpl.Throw(Exception e)
        at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res)
        at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName)
        at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl)
        at System.Xml.XmlTextReaderImpl.Read()
        at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri)
        at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute()
        at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
        at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj]

The file was actually `utf-8` but we were generating:

    <?xml version="1.0" encoding="utf-16"?>

I reworked `Xamarin.ProjectTools` to fix this.

I was able to add a simple test that just build a wear project, and
then added a second test that reproduces the problem.

~~ The Problem ~~

Generally embedded Android Wear solutions:

* A main app references the Wear project.
* The main app grabs a few files from the Wear project: the APK and an
  xml configuration file and copies them into `obj\Debug\res`.

What was even weirder, since we put them in `@(AndroidResource)` the
`_GenerateAndroidResourceDir` MSBuild target would attempt to copy
these files to themselves. The same files paths were in
`@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`...

    <CopyIfChanged
        SourceFiles="@(_AndroidResolvedResources)"
        DestinationFiles="@(_AndroidResourceDest)"

The problem was we basically were copying these files and never adding
them to `@(_ModifiedResources)`. This meant that
`$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases:

    <Touch
        Files="$(_AndroidResFlagFile)"
        AlwaysCreate="True"
        Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' "
    />

Two fixes seemed to solve the issue:

* The `<PrepareWearApplicationFiles/>` task needs to return a
  `ModifiedFiles` output we can add to `@(_ModifiedResources)`.
* We should define the Wear files in `@(_AndroidResourceDest)` after
  the `<CopyIfChanged/>` call such as:

    <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" />

This way they are never part of `@(AndroidResource)`, since they are
auto-generated.
jonpryor pushed a commit that referenced this issue Sep 6, 2019
)

* [Xamarin.Android.Build.Tasks] fix Android Wear incremental builds

Fixes: #3562

Our QA tests caught a regression where building a Xamarin.Android app
that includes an embedded Android Wear app would always rebuild.

This brought up a few things:

1. We have a `XamarinAndroidWearApplicationProject` class, but no
   tests using it?
2. What does our MSBuild targets even do for Wear projects?

~~ Tests ~~

In adding some tests, I had to fix a few other things:

* We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of
  `preview7`.
* `Xamarin.ProjectTools` was generating `csproj` files of an encoding
  that did not match:

    C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly.
        System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode.
        at System.Xml.XmlTextReaderImpl.Throw(Exception e)
        at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res)
        at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName)
        at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl)
        at System.Xml.XmlTextReaderImpl.Read()
        at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options)
        at System.Xml.Linq.XDocument.Load(String uri)
        at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute()
        at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
        at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj]

The file was actually `utf-8` but we were generating:

    <?xml version="1.0" encoding="utf-16"?>

I reworked `Xamarin.ProjectTools` to fix this.

I was able to add a simple test that just build a wear project, and
then added a second test that reproduces the problem.

~~ The Problem ~~

Generally embedded Android Wear solutions:

* A main app references the Wear project.
* The main app grabs a few files from the Wear project: the APK and an
  xml configuration file and copies them into `obj\Debug\res`.

What was even weirder, since we put them in `@(AndroidResource)` the
`_GenerateAndroidResourceDir` MSBuild target would attempt to copy
these files to themselves. The same files paths were in
`@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`...

    <CopyIfChanged
        SourceFiles="@(_AndroidResolvedResources)"
        DestinationFiles="@(_AndroidResourceDest)"

The problem was we basically were copying these files and never adding
them to `@(_ModifiedResources)`. This meant that
`$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases:

    <Touch
        Files="$(_AndroidResFlagFile)"
        AlwaysCreate="True"
        Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' "
    />

Two fixes seemed to solve the issue:

* The `<PrepareWearApplicationFiles/>` task needs to return a
  `ModifiedFiles` output we can add to `@(_ModifiedResources)`.
* We should define the Wear files in `@(_AndroidResourceDest)` after
  the `<CopyIfChanged/>` call such as:

    <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" />

This way they are never part of `@(AndroidResource)`, since they are
auto-generated.
@brendanzagaeski
Copy link
Contributor

Release status update

A new Preview version has now been published that includes the fix for this item. The fix is not yet included in a Release version. I will update this item again when a Release version is available that includes the fix.

The fix is not yet available on macOS. I will update this item again when a Preview version with the fix is available on macOS.

Fix included in Xamarin.Android 10.0.99.100.

Fix included on Windows in Visual Studio 2019 version 16.4 Preview 1. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview.

Fix not yet available on macOS.

@brendanzagaeski
Copy link
Contributor

Release status update

A new Preview version has now been published for macOS that includes the fix for this item.

Fix included in Xamarin.Android 10.1.0.1.

Fix included on macOS in Visual Studio 2019 for Mac version 8.4 Preview 1. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.

@brendanzagaeski
Copy link
Contributor

Release status update

A new Release version has now been published on Windows that includes the fix for this item. The fix is not yet published in a Release version on macOS. I will update this item again when a Release version is available on macOS that includes the fix.

Fix included in Xamarin.Android 10.1.0.30.

Fix included on Windows in Visual Studio 2019 version 16.4. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/.

(Fix also included on macOS in Visual Studio 2019 for Mac version 8.4 Preview 2.1 and higher. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.)

@brendanzagaeski
Copy link
Contributor

Release status update

A new Release version has now been published on macOS that includes the fix for this item.

Fix included in Xamarin.Android 10.1.1.0.

Fix included on macOS in Visual Studio 2019 for Mac version 8.4. To get the new version that includes the fix, check for the latest updates on the Stable updater channel.

(Fix also included on Windows in Visual Studio 2019 version 16.4 and higher. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/.)

@ghost ghost locked as resolved and limited conversation to collaborators Jun 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants