2015-09-07 10 views
11

Próbuję uruchomić android SDK na pudełku, które musi mieć noexec na /tmp.Jak ręcznie zainstalować biblioteki Java i zachować/tmp jako noexec?

Mogę wskazać, że java tmp to kolejne miejsce, w którym mogę wykonać egzekucję, ale to mogłoby zniweczyć cel policji wymagającej noexec w tmp. Więc nie chcę tego jeszcze robić.

Chciałem poprawnie zainstalować biblioteki wymagane przez sdk, ale moje java jest zardzewiałe.

Kiedy próbuję go uruchomić, uzyskać:

$ Android/Sdk/tools/android 
Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-gtk-3550 or swt-gtk in swt.library.path, java.library.path or the jar file 
    at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source) 
    at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source) 
    at org.eclipse.swt.internal.C.<clinit>(Unknown Source) 
    at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source) 
    at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source) 
    at org.eclipse.swt.widgets.Display.<clinit>(Unknown Source) 
    at com.android.sdkmanager.Main.showSdkManagerWindow(Main.java:403) 
    at com.android.sdkmanager.Main.doAction(Main.java:391) 
    at com.android.sdkmanager.Main.run(Main.java:151) 
    at com.android.sdkmanager.Main.main(Main.java:117) 

Moja pierwsza próba obejścia, które brzmiało:

$ sudo aptitude install libswt-gtk-3-java... 
Selecting previously unselected package libswt-gtk-3-jni. 
(Reading database ... 199270 files and directories currently installed.) 
Preparing to unpack .../libswt-gtk-3-jni_3.8.2-3_amd64.deb ... 
Unpacking libswt-gtk-3-jni (3.8.2-3) ... 
Selecting previously unselected package libswt-gtk-3-java. 
Preparing to unpack .../libswt-gtk-3-java_3.8.2-3_amd64.deb ... 
Unpacking libswt-gtk-3-java (3.8.2-3) ... 
Setting up libswt-gtk-3-jni (3.8.2-3) ... 
Setting up libswt-gtk-3-java (3.8.2-3) ... 

Ale wciąż otrzymuję ten sam błąd. Czy oznacza to, że program nie szuka domyślnych bibliotek, ale celowo próbuje użyć czegoś, co rozpakowuje na/tmp? Czy java rozpakuje słoik zawsze w/tmp i spróbuje uruchomić go stamtąd, a ja nic nie mogę zrobić?

EDYTOWANIE: Aby wyczyścić, przyczyną jest noexec. Jeśli uruchomię aplikację pod numerem -Djava.io.tmpdir=Android/tmp, wszystko działa. I mam następującą zawartość w nowym tmp reż:

Android/tmp/ 
└── swtlib-64 
    ├── libswt-gtk-3550.so 
    └── libswt-pi-gtk-3550.so 

Edycja 2:

$ ANDROID_SWT=/usr/lib/java/ 
$ ls $ANDROID_SWT/ 
    swt-gtk-3.8.2.jar 
$ Android/Sdk/tools/android 
Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-gtk-3550 or swt-gtk in swt.library.path, java.library.path or the jar file 
...same... 
+0

Co dało Ci pojęcie o zaangażowaniu '/ tmp'? – Siguza

+0

@Siguza, to jest powód tego błędu. jeśli wyśledzę to, to gdzie mnie dopadło. mogę skutecznie obejść ten błąd przez usunięcie 'noexec' lub ustawienie' java.io.tmpdir =/home/me/tmp' – gcb

+0

To było tutaj wcześniej: https://stackoverflow.com/questions/3344903/problem-launching- android-avm-sdk-gui-using-the-tools-android-executable-in-the, choć faktyczny powód, dla którego pakiet SDK dla Androida kopiuje biblioteki SWT do '/ tmp', wciąż pozostaje tajemnicą. – dhke

Odpowiedz

0

Wierzę, że jeśli zmienić folder narzędzi Android SDK (w/opt) być zapisywalny przez używasz chown, wtedy rozpakowanie nastąpi w folderze sdk. Możesz to zrobić, tworząc grupę "androidsdk".

+0

Katalog SDK jest już zapisywalny. Wciąż nie mam pojęcia, dlaczego na ziemi java/aplikacja próbuje rozpakować biblioteki w tmp zamiast używać dokładnie tych samych wersji, które są łatwo dostępne w systemie ... – gcb

Powiązane problemy