Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
I have an androidmanifest.xml file which works correctly and starts with these lines:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="@string/AppPackageCode" android:versionCode="2" android:versionName="1.1" android:installLocation="auto">
The xam tools don't follow the @string/AppPackageCode indirection and use a strange package name instead: x_string_AppPackageCode.x_string_AppPackageCode
This setup is fully supported by android tools.
This bug in xam tools prevents me from creating clones of my app with the same common files.
Plz fix it.
Please note that, in order to reproduce the pb, the @string/AppPackageCode resource should be created in a strings.xml file in an android library project !
Don't count on this being fixed anytime soon.
> This bug in xam tools prevents me from creating clones of my app with the same
You can instead override the $(AndroidManifest) MSBuild property to refer to a different AndroidManifest.xml file with a different /manifest/@package attribute value.
Possibly relevant: https://forums.xamarin.com/discussion/590/one-solution-for-many-clients
The reason this won't be fixed anytime soon is that the package name is used in numerous places by the build process itself: it's used for `aapt --custom-package` (for library project support), it's used to determine the output filename, etc. It's use is _not_ constrained to "just" aapt.
As such, in order to allow /manifest/@package to be an Android string resource, we would need to implement an Android resource parser (so that it could be looked up in the same way that aapt does things), which in turn is (1) not trivial, and (2) even if we did so would likely add a not insignificant amount of time overhead for common build operations.
I'm not saying it'll never be fixed. I'm saying that if it will be fixed, it won't be anytime soon.
Sounds like Jonathan Pryor answered the question in Comment 2 (https://bugzilla.xamarin.com/show_bug.cgi?id=20970#c2).