2017-02-23 2 views
1

Ich habe ein einfaches Batch-Skript, das ein Xamarin-Formular-Projekt erstellt. Es funktioniert, wenn ich es manuell auf dem Computer ausführe, aber es schlägt fehl, wenn ich versuche, es als Build-Schritt durch Jenkins auszuführen. Ich erhalte folgende Fehlermeldung:Warum findet Jenkins kein Android SDK?

Did not find Android SDK
C:\Program Files x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(567,2): error XA5205: The Android SDK Directory could not be found.
Please set via /p:AndroidSdkDirectory .

Ich bin mir ziemlich sicher, dass alle Umgebungsvariablen meines Systems korrekt eingestellt sind.
PATH enthält C:\Program Files\Android\android-sdk

Ich habe ANDROID_HOME Set C:\Program Files\Android\android-sdk sowie auch. Ich habe es nicht über /p:AndroidSdkDirectory eingestellt (was ich jetzt vorhabe), aber ich bin immer noch daran interessiert, warum es nicht durch PATH oder ANDROID_HOME finden kann. Jede Hilfe würde sehr geschätzt werden! Vielen Dank!

EDIT:

Meine Batch-Datei:

SET projectPath=%1 
SET projectName=%2 
SET keystorePath=%3 
SET password=%4 
SET alias=%5 
SET config=%6 
SET apkName=%7 

msbuild %projectPath%\%projectName% /p:Configuration=%config% /t:Clean 
msbuild %projectPath%\%projectName% /p:Configuration=%config% /t:PackageForAndroid /p:AndroidSdkDirectory="C:\Program Files\Android\android-sdk" 

jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore %keystorePath% -storepass %password% -signedjar %projectPath%\bin\%config%\com.company.helloworld-signed.apk %projectPath%\bin\%config%\com.company.helloworld.apk %alias% 

zipalign -f -v 4 %projectPath%\bin\%config%\com.company.helloworld-signed.apk %projectPath%\bin\%config%\%apkName%.apk 

Meine Systemvariablen:

ANDROID_NDK_PATH  "C:\Program Files\Android\android-ndk-rl3b" 
ANDROID_SDK_HOME  "C:\Program Files\Android\android-sdk" 
ComSpec    C:\Windows\system32\cmd.exe 
SDK_HOME    C:\Program Files\Java\jdk1.8.0_121 
NUMBER_OF_PROCESSORS 4 
OS      Windows_NT 

Mein System PATH:

C:\ProgramData\Oracle\Java\javapath 
%SystemRoot%\system32 
%SystemRoot% 
%SystemRoot%\System32\Wbem 
%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\ 
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static 
C:\Program Files (x86)\Skype\Phone\ 
%USERPROFILE%\.dnx\bin 
C:\Program Files\Microsoft DNX\Dnvm\ 
C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit 
C:\Program Files\Microsoft SQL Server\130\Tools\Binn\ 
C:\Program Files\Perforce 
C:\Program Files\Perforce\DVCS\ 
C:\Program Files (x86)\MSBuild\14.0\Bin 
C:\Program Files\Java\jdk1.8.0_121 
C:\Program Files\Android\android-sdk 
C:\Program Files\Java\jre1.8.0_121\bin 
C:\Program Files\Java\jdk1.8.0_121\bin 
C:\Program Files\Android\android-sdk\build-tools\25.0.2 

Ich habe Jenkins als Windows-Dienst installiert.

+0

Hm es fand die sdk nachdem ich hinzugefügt/p: AndroidSdkDirectory aber jetzt kann es zipalign nicht finden. Warum sollte Jenkins Probleme mit meinem System PATH haben? –

+0

Wenn ich den PATH im Build-Schritt ausdrucke, sehe ich, was wie die richtige Variable aussieht. –

+0

Also nach einem Neustart des Computers kann es zipalign finden und korrekt erstellt, wenn ich/p: AndroidSdkDirectory verwende. Ich bin immer noch verwirrt darüber, warum ich dieses Argument verwenden muss, wenn ich von Jenkins baue, aber nicht lokal. Jede Hilfe würde immer noch geschätzt werden. –

Antwort

1

Es ist interessant, dass die Fehlermeldung Zeile

C:\Program Files x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(567,2): 

einen Raum Charakter statt eine öffnende Klammer ( links von x86 enthält.


Das System PATH Umgebungsvariable sollte nicht als erste Verzeichnispfad haben

C:\ProgramData\Oracle\Java\javapath 

Dies sollte der fünfte Verzeichnispfad in der Liste der Verzeichnisse sein.


Ich habe keine Android SDK je auf einem meiner Windows-Computer installiert ist, aber ich finde es merkwürdig, dass die Verzeichnispfade von ANDROID_SDK_HOME und ANDROID_SDK_HOME mit den umliegenden doppelten Anführungszeichen eingeschlossen definiert sind.

Das kann richtig sein, könnte aber auch Probleme verursachen, je nachdem, wie diese beiden Umgebungsvariablen von Batch-Dateien referenziert werden oder in Anwendungen verwendet werden.

Verzeichnispfade werden Umgebungsvariablen normalerweise ohne umgebende doppelte Anführungszeichen zugewiesen.


In der Batch-Datei könnte die Behandlung des ersten und zweiten Arguments ein Problem sein.

SET projectPath=%1 
SET projectName=%2 
msbuild %projectPath%\%projectName% /p:Configuration=%config% /t:Clean 

Wenn Projektpfad oder Projektnamen &()[]{}^=;!'+,`~ ein Leerzeichen oder eines dieses Zeichen enthält, muss sie angegeben wird, in doppelten Anführungszeichen eingeschlossen werden, um die Batch-Datei beim Starten. Es ist üblich, Verzeichnispfade, Dateinamen und andere Parameter an Batch-Dateien in Anführungszeichen zu übergeben.

Das erste und das zweite Argument werden den Umgebungsvariablen projectPath und projectName zugewiesen, wie in der Befehlszeile beim Starten der Batch-Datei definiert, dh ohne oder mit umgebenden doppelten Anführungszeichen. Im Fall von Projektpfad und Projektnamen in doppelten Anführungszeichen eingeschlossen sind, wird die dritte Zeile vor der Ausführung erweitert zum Beispiel:

msbuild "C:\Project Path"\"Project Name" /p:Configuration=xxx /t:Clean 

Das ist nicht gut. Je nachdem, wie gut die Fehlerkorrektur des Windows-Befehlsinterpreters bzw. die Kernel-Funktionen von Windows sind, kann es funktionieren. Aber es wäre definitiv besser, sicherzustellen, dass die doppelten Anführungszeichen entfernt werden, wenn die Argumente der Stapelverarbeitungsdatei Umgebungsvariablen zugewiesen werden, und die Parameterzeichenfolgen in Anführungszeichen eingeschlossen werden, wenn sie in den Befehlszeilen darunter benötigt oder zumindest stark empfohlen werden.


Es wäre auch in einer Batch-Datei, die von Jenkins verwendet Sinne ergibt Abhängigkeit der Umgebungsvariablen zu vermeiden PATH und PATHEXT so viel wie möglich vor allem auf Lauf Jenkins als Service mit Systemkonto durch die Anwendungen, die Angabe mit voller auszuführen Pfad und mit Dateierweiterung, die keine Umgebungsvariablen verwendet oder Systemumgebungsvariablen verwendet, die von Windows selbst definiert werden.


Hier ist ein Batch-Code ohne Jenkins, MSBuild überhaupt mit der Annahme installiert hat geschrieben, Java SDK, Java JDK oder Android SDK, dass der config Parameter ein kurzes Wort ist enthält niemals kritische Zeichen.

set "projectPath=%~1" 
set "projectName=%~2" 
set "keystorePath=%~3" 
set "password=%~4" 
set "alias=%~5" 
set "config=%~6" 
set "apkName=%~7" 

rem Get directory paths of used applications for build task. 
for /D %%I in ("%ProgramFiles(x86)%\MSBuild\*") do set "MSBUILD_PATH=%%I\Bin" 
for /D %%I in ("%ProgramFiles%\Java\jdk*") do set "JAVA_JDK_PATH=%%I\bin" 

"%MSBUILD_PATH%\msbuild.exe" "%projectPath%\%projectName%" /p:Configuration=%config% /t:Clean 
"%MSBUILD_PATH%\msbuild.exe" "%projectPath%\%projectName%" /p:Configuration=%config% /t:PackageForAndroid /p:AndroidSdkDirectory="%ProgramFiles%\Android\android-sdk" 

"%JAVA_JDK_PATH%\jarsigner.exe" -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore "%keystorePath%" -storepass "%password%" -signedjar "%projectPath%\bin\%config%\com.company.helloworld-signed.apk" "%projectPath%\bin\%config%\com.company.helloworld.apk" "%alias%" 

"%JAVA_JDK_PATH%\zipalign.exe" -f -v 4 "%projectPath%\bin\%config%\com.company.helloworld-signed.apk" "%projectPath%\bin\%config%\%apkName%.apk" 

Ich weiß nicht, ob es wirklich eine gute Idee ist, der MSBuild mit der Batch-Datei zu finden und der Java JDK Pfad oder eine Systemumgebungsvariable verwenden. Die automatische Suche nach MSBuild und Java JDK Pfade möglicherweise keine gute Idee, wenn mehrere Versionen von MSBuild und/oder Java JDK installiert ist.

Die Batchdateiargumente den Umgebungsvariablen jedoch zuweisen, indem umschließende Anführungszeichen wie bei %~1, %~2, ... und später umschlossen werden, die Variablenparameterzeichenfolgen in Anführungszeichen eingeschlossen werden.

Die Hilfeausgabe durch Ausführen in einem Eingabeaufforderungsfenster call /? erklärt, welche Modifikatoren bei Verweisungsargumenten verwendet werden können.

Seiten mit einer www-Suchmaschine zu diesem Problem gefunden:

diese Web-Seiten sind 4 der Top-7 Ergebnisse auf der Suche mit meiner bevorzugten World Wide Web Suche Engine für den Begriff "Android SDK Directory could not be found" in Anführungszeichen eingeschlossen, wie hier gepostet, um Seiten zu finden, die genau diesen Begriff enthalten.


Ein weiterer Hinweis:

Systemumgebungsvariablen definiert oder bearbeitet durch den Benutzer über Windows-Systemsteuerung wirksam werden nur für Anwendungen und Dienste nach der Änderung gestartet.

Alle bereits ausgeführten Dienste, Prozesse und Anwendungen verfügen bereits über eigene Umgebungsvariablen, die von Windows automatisch im Speicher des vom übergeordneten Prozess beim Starten des Dienstes/Prozesses/der Anwendung abgeleiteten Dienstes/Prozesses/Anwendung erstellt werden.

Es ist nicht möglich, dass ein übergeordneter Prozess die Umgebungsvariablen eines untergeordneten untergeordneten Prozesses manipuliert, noch kann ein untergeordneter Prozess die Umgebungsvariablen seines übergeordneten Prozesses manipulieren.

Jeder Prozess hat seine eigene Umgebungsvariablenliste, die von Windows automatisch erstellt wird, als Kopie der Umgebungsvariablenliste des Prozesses, der den neuen Prozess startet.

Bei Windows-Diensten, die im Hintergrund ausgeführt werden, muss mindestens eine Systemumgebungsvariable den Dienst anhalten und neu starten oder möglicherweise sogar Windows neu starten, je nachdem, was der übergeordnete Prozess des ausgeführten Windows-Dienstes ist.

Verwandte Themen