AndroidManifest can not be set to an absolute path

[SamMonoRT]

Description

Copied over from dotnet/runtime#73311
Description
Microsoft.Android.Sdk.DefaultProperties.targets is always settings $(AndroidManifest) to AndroidManifest.xml if empty. Xamarin.Android.Common.targets is settings _AndroidManifestAbs always to $(ProjectDir)$(AndroidManifest) as long as $(AndroidManifest) is not empty.

There is no clean way to set the path to an absolute one (as part of an SDK) besides hooking in before _GetAndroidPackageName and resetting $(AndroidManifest) and defining $(_AndroidManifestAbs) myself. This feels a bit hacky.

Reproduction Steps
Set C:...\AndroidManifest.xml

Expected behavior
'$(_AndroidManifestAbs)' == 'C:...\AndroidManifest.xml'

Actual behavior
'$(_AndroidManifestAbs)' == '$(ProjectDir)C:...\AndroidManifest.xml'

Regression?
No response

Known Workarounds


<_AndroidManifestAbs Condition=" '$(AndroidManifest)' != '' ">$(AndroidManifest)</_AndroidManifestAbs>




Configuration
No response

Other information
No response

Steps to Reproduce

See Description.

@Falco20019 dotnet/maui is already doing exactly what you describe:

https://github.com/dotnet/maui/blob/f1c358800c5276bc16290164eaf98c60f92da9fe/.nuspec/Microsoft.Maui.Controls.SingleProject.targets#L40

Is the problem finding right place to set this value? .NET workloads can probably run .targets in a different order that makes this work.

Did you find any workaround?

No response

Relevant log output

No response

[jonathanpeppers]

As mentioned here, dotnet/maui is already doing this:

dotnet/runtime#73311 (comment)

@Falco20019 did you take a look at what they are doing:

https://github.com/dotnet/maui/blob/f1c358800c5276bc16290164eaf98c60f92da9fe/.nuspec/Microsoft.Maui.Controls.SingleProject.targets#L40

Does it work if you try something like this?

[ghost]

Hi @Falco20019. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[Falco20019]

AFAIK AndroidProjectFolder is only relative to ProjectDir, which is why it works in this case (see PlatformsProjectFolder). This is still not allowing absolute paths to work, since this also has the assumption, that when _AndroidManifestAbs is calculated, $(ProjectDir) will be prepented to it. Just try setting PlatformsProjectFolder to $(ProjectDir)\Platforms\ to make it absolute instead of relative, and you should run into the same issue.

[jonathanpeppers]

@Falco20019 can you give some details why you need the AndroidManifest.xml path an absolute path? I think some details on what you're trying to accomplish will help us prioritize this. Thanks!

[Falco20019]

We have a custom SDK that we use that contains a default manifest, setting some stuff that all of our apps need. Every app is then only adding more stuff using the manifest attributes. Since the SDK is usually located in the NuGet package cache (which is not always on the same drive), we need to define the path based on the package path.

In our case, we have an encrypted virtual drive on that our code is located. The NuGet package cache on the other side is usually in the user directory and therefore on the system drive. Due to that, it's not possible for us to calculate a relative path to use based on both paths, as the relative path has to include the drive letter, making it an absolute path.

More details: It's a highly configurable and modular application. Therefore, all modules are separate NuGet packages themselves. When publishing the customer specific app, we basically have a bootstrapper (one package) and the customer needed modules (more packages) that are referenced in a deployment project, which does not have any code itself. The .NET toolchain needs to have the manifest to be defined in that project as you know. To keep it code-less, we need to add this and other default files through the SDK. That leads to the aforementioned issue with possibly having different drives involved. All other parts of the .NET toolchain have no issues with absolute paths. So this is the only place that behaves "out of order".

[jonathanpeppers]

What is an example of the values you need to put in the AndroidManifest.xml? There are probably several ways to accomplish this, and an absolute path to this file seems like it might not be the best way. Would you be better off using a "partial" manifest and using our manifest-merger feature? Should we add MSBuild properties to do what you need? You can also define some values as C# attributes inside class libraries.

[Falco20019]

AFAIK, the build chain requires one manifest file as part of your APK building project. It has to be at least existing and empty. Otherwise I got an error. But I must not have any files beside the csproj and possible files absolutely referenced by the SDK.

[jonathanpeppers]

So you have a project that builds multiple apps, with the same manifest?

Could you have a nearly empty manifest in the app, and then any of the NuGets / class libraries you use pass the specific parts you want set in the final manifest?

[Falco20019]

We already define mostly everything through the C# attributes per module and rely on the merger. We only put the basic information like package id into the dummy file. Just to make the tool chain happy. If it's possible to completely avoid adding a file and only rely on attributes, that's also fine for us. It would be best, if we could add the basic manifest into one of the module nupkgs and don't have one in the deployment project at all.

Do I have to set a property for this to work? Because if I only tried to rely on the merger without adding at least an empty file to my project, it told me it's missing that file.

[jonathanpeppers]

We were considering making it where you wouldn't need an AndroidManifest.xml at all in the future:

• https://github.com/xamarin/xamarin-android/blob/main/Documentation/guides/OneDotNetSingleProject.md#other-future-work

(But this is probably a .NET 8/future thing if it happens)

Would something like this work?

• Your app has a small AndroidManifest.xml, not much in it
• The NuGet packages could either:
  • Include an .aar with an AndroidManifest.xml inside. I think you could literally make a .zip with one file and change the extension to .aar. Placing the file in a project directory, should automatically pack the file inside the .nupkg.
  • Include an AndroidManifest.xml inside the NuGet packages, and then add a MSBuild .targets file that adds the files to the ExtractedManifestDocuments item group

Then the default manifest-merger behavior would do what you need?

[Falco20019]

If the ExtractedManifestDocuments support absolute paths, this should work for us. Since the SDK is already doing exactly that.