Visual Studio 2017 Xamarin Android API Level 25: Enable the default proguard

Question

I cannot build my android application with the default visual studio 2017 proguard enabled.

I enable the proguard from

Project > Android.Properties > Android Options > Check "Enable ProGuard"

Then I cannot build my application.

It says:

C:\\Program Files (Access is denied)

How do I fix this?

Answer 1

This was a bug in xamarin.
happens if the android sdk path contains space ("C:\\Program Files (x86)\\Android\\android-sdk"). You have to move the android-sdk to a path without spaces.(C:\\android-sdk)
See here how.

This was reportedly fixed so upgrading Xamarin should fix the bug however note that some devs reported as of 2017-06-22 that this was still reproducable using:

Xamarin 4.6.0.267 (750994b)
Xamarin.Android SDK 7.4.0.9 (5f3167a)

So if the updating all the tools and sdk does not work you will have to move the directory as described above.

Answer 2

尝试以下操作，我遇到了类似的问题并为我工作：-dontwarn okio。** -dontwarn java.nio。** -dontwarn java.lang.invoke。**有关同一问题的讨论在此处与其他解决方案一起继续： https://forums.xamarin.com/discussion/45210/enable-proguard-error-c-program-files-access-is-denied

Answer 3

it's a common Linux/Windows command-line compatibility issue. you might have to set ANDROID_HOME (the path to the Android SDK, without spaces) under "System Properties" > "Advanced System Settings" > "Environment Variables" > "System Variables". Visual Studio should pick up these values - also check permissions on proguard.exe , eg. if the current user can run it from the command line. here it's also explained: " How to Fix Error “C:\\Program Files (Access is Denied)” When Proguard has Enabled while Build a Android app " (linking the SDK is the other option). Moving the whole SDK to C:\\Android\\SDK might be suggested. Visual Studio may even install the SDK twice, when installing it beside an existing IDE, unless one has JAVA_HOME , ANDROID_HOME and ANDROID_AVD_HOME (the emulator images) defined. Having the SDK within the user profile (or within "Program Files") is rather problematic. At least, these variables can be used to change the individual install locations (in order to fix PATH issues alike this - or to delete eventual duplicate SDK installs).