Build succeed
Build fail on AzureDevOps with this error :
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1769,2): Error APT0000: failed to create directory 'C:\Users\VssAdministrator\AppData\Local\Temp\gkeyu4ln.ejw\isatis\tad'.
For information, the same project build perfectly on my local machine with the project also on another disk than the system.
AzureDevOps Vs2017 image or AzureDevOps Vs2019 image used to build
Here the binlog of the build : binlog.zip
Related to issue #1771
I think it's because it use the build-tools 27.0.3 instead of 28.0.3 which contains an older aapt version.
Android NDK: \
Android SDK: C:\Program Files (x86)\Android\android-sdk\
Android SDK Build Tools: C:\Program Files (x86)\Android\android-sdk\build-tools\27.0.3\
Java SDK: C:\Program Files\Android\jdk\microsoft_dist_openjdk_1.8.0.25\
Another issue with the resolve task is that the ndk is not found on AzureDevOps.
How the ResolveSdk task decide what version to use and how to debug it ?
The environment variables in the agent are :
ANDROID_HOME=C:\Program Files (x86)\Android\android-sdk
ANDROID_NDK_HOME=C:\Microsoft\AndroidNDK64\android-ndk-r16b
ANDROID_NDK_PATH=C:\Microsoft\AndroidNDK64\android-ndk-r16b
JAVA_HOME=C:\Program Files\Java\zulu-8-azure-jdk_8.38.0.13-8.0.212-win_x64
JAVA_HOME_11_X64=C:\Program Files\Java\zulu-11-azure-jdk_11.31.11-11.0.3-win_x64
JAVA_HOME_8_X64=C:\Program Files\Java\zulu-8-azure-jdk_8.38.0.13-8.0.212-win_x64
After set AndroidSdkBuildToolsVersion in the csproj to force the usage of the latest builds tools and so of the latest version of aapt, it's the same error. Failed to create directory.
@dellis1972 I think this might be the thing building across drives on Windows...
any work around for now!?
@shanranm
There are a couple workarounds:
<AndroidUseAapt2> for your Release builds -- or whichever ones running on Azure DevOps. aapt2 has a lot of incremental build benefits, which helps you locally, but doesn't affect your final Release APK on the Play store that much.TEMP variable in your build definition to something like D:\work\_temp so the same drive is used for %TEMP% and where your code is checked out. I used this workaround in the past, and maybe I had to set TMP as well, I don't remember.I had already tried to move TEMP without success in the past but today I retry it and it works now.
I think it's because I was using only $env: syntax and it doesn't persist outside step, so I have to use SetEnvironmentVariable.
So for others that encounter the issue and use YAML pipeline, this is the step I use (It surely can be simplified) :
- powershell: |
$drive = (Get-Item $Env:BUILD_SOURCESDIRECTORY).PSDrive.Name;
$tempPath = Join-Path $drive -ChildPath Temp;
New-Item -ItemType "directory" $tempPath;
$env:TEMP = $tempPath;
$env:TMP = $tempPath;
[Environment]::SetEnvironmentVariable('TEMP', $tempPath);
[Environment]::SetEnvironmentVariable('TMP', $tempPath);
@jonathanpeppers Thank you for the multiple workarounds.
Personally I prefer to use the same aapt version in local and CI to minimize the differences between environment, but it's a valid workaround.
I'm also facing this issue when I'm trying to build my UWP project in App Center. Will try this powershell script and revert back about the results.
@Xonshiz aapt is not used by UWP. It is from the Android SDK.
I don鈥檛 see how UWP is related here?
Yes, I understand that. But, the error is same for UWP. I can build UWP on my system fine, not on App Center. At this point I'm just trying random fixes.
I removed the fix and it seems to work now.
Most helpful comment
@shanranm
There are a couple workarounds:
<AndroidUseAapt2>for yourReleasebuilds -- or whichever ones running on Azure DevOps.aapt2has a lot of incremental build benefits, which helps you locally, but doesn't affect your finalReleaseAPK on the Play store that much.TEMPvariable in your build definition to something likeD:\work\_tempso the same drive is used for%TEMP%and where your code is checked out. I used this workaround in the past, and maybe I had to setTMPas well, I don't remember.