OpenVPNren laguntzaile binarioak huts egiten du Android 10-en: baimena ukatuta

Aplikazioa Android 9n zebilen eta Android 10era eguneratu ondoren telefono berean hiltzen da. Zure profila ukitu gabe dago, ziurtagiriak berdinak dira, eta kraskada autentifikazio trafikoa baino lehen iristen da. Logcat-ek nul erakusle bat erakusten du lehenengo, eta horren gainetik lerro batzuk gorago dago Cannot run program ...: error=13, Permission denied. Mezu hori fitxategi bat exekutatzeaz ari da, ez zure konfigurazioa irakurtzeaz.

Zer ukatzen du benetan 13 zenbakiko erroreak

Android 10ek, API 29 mailak, aplikazioei eragotzi zien beren datu direktorioan idatzitako fitxategiak exekutatzea. Arauak idazteko moduko eta gero exekutatzeko moduko biltegiratzeari egiten dio eraso, eta hori da hain zuzen assets-etatik kopiatzen duen abiarazle batek sortzen duena. ics-openvpn nukleoaren bertsio zaharrek exekutagarri bat deskonprimatzen dute openvpn APK-tik lehen exekuzioan eta ProcessBuilder erabiliz abiarazten dute. Deskonprimatzeak oraindik arrakasta du, exekuzioa da ukatzen dena. API 29 helburu duen aplikazio batek araua heredatzen du bertsio zaharrago batekin iritsitako gailuan exekutatzen denean ere, eta horregatik eguneraketa batek inork ukitu ez duen konpilazio bat hondatu dezake.

Ukapenak ez du karpeta-izen jakin batzuetarako ezer berezirik. Aplikazioak bere datu direktorioaren azpian sortutako fitxategia exekutaezina ez den bezala tratatzen da bidea edozein dela ere, beraz getFilesDir(), getCacheDir() eta azpidirektorio propio bat berdin huts egiten dute.

Bereizi laguntzailearen kraskada profil arazo batetik

Irakurri prozesuaren hasieraren inguruko loga goitik jaisten hasi beharrean. Bilatu beharreko sinadura error=13 lerroa da, eta haren gaineko pila-arrastoak ProcessBuilder deitu zuen abiarazle metodoa izendatzen du normalean:

adb logcat -d | grep -n -i -E "cannot run program|permission denied|startOpenVPN"

Laguntzailea inoiz abiarazi ez bada, ez duzu batere OpenVPN log irteerarik ikusiko: ez zifratze negoziaziorik, ez bultzatutako ibilbiderik, ez DNS konfiguraziorik. Lerro horiek agertzen badira eta hutsegitea geroago iristen bada, binarioa exekutatu zen eta arazoa profilan, zerbitzarian edo bideratze geruzan dago. Bereizketa bakar horrek denbora asko aurreztzen du bestela .ovpn fitxategiak editatzen emango zatekeena, inoiz errudunak izan ez zirenak. Gainera esaten dizu beheko bi konponketetatik zein behar duzun benetan.

Egiaztatu probatzen ari zaren gailuko API maila ere, ez zure konpilazio konfiguraziokoa. API 28ko emulatzaile irudi batek ez du ezer birsortzen, murrizketak 29tik gora egiten baitu koska. Egiaztatu era berean zure konpilazio fitxategiko SDK helburua: hura igotzea da araua sarrarazten duena.

adb shell getprop ro.build.version.sdk

Zergatik ez duen laguntzen binarioa beste leku batera kopiatzeak

Begi-bistako konponbideak, laguntzailea idazteko moduko beste direktorio batean idazteak, jatorrizkoak huts egin zuen arrazoi beragatik huts egiten du. Androidek oraindik baimendu egiten du aplikazioaren liburutegi natiboen direktorioan instalatutako liburutegi partekatuak exekutatzea, instalatzaileak paketatzen baititu, ez baitira exekuzio denboran idazten. Direktorio hori da abiarazleak seinalatu beharko lukeen toki bakarra. Exekuzio denboran zeuk deskonprimatzen duzun edozer, edozein izen emanda ere, ukatuen kategorian geratzen da.

Kanpo biltegia okerragoa da: noexec muntatuta dago, eta han jarritako laguntzaile bat ezin du inongo aplikaziok abiarazi. Aplikazioaren datuak garbitzeak ere ez du jokabide zaharra berreskuratzen, hurrengo exekuzioak exekutaezina den kopia bera sortzen baitu berriro.

Zuzendu abiarazlea paketatutako liburutegi batera

Aldatu laguntzailearen izena liburutegi partekatu baten izenera eta banatu jniLibs azpian onartzen duzun ABI bakoitzeko, eta gero egin abiarazleak API 28tik aurrera instalatutako liburutegiaren bidea itzul dezan:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
    return new File(context.getApplicationInfo().nativeLibraryDir,
                    "libovpnexec.so").getPath();
}

Liburutegia instalatzean deskonprimatu behar da bide horrek benetako fitxategi bat izan dezan, beraz ezarri android:extractNativeLibs="true" elementuan <application>. Manifestu bateratzaile batek beste balio bat ekartzen badu, gehitu tools:replace="android:extractNativeLibs" haren ondoan. application elementuaren erreferentzia atributuak zer kontrolatzen duen dokumentatzen du.

Kontuz tokiko aldagai bikoiztu batekin abiarazlea eskuz adabakitzen duzunean. Iturri zaharrek nativeAPI deklaratzen dute metodo berean geroago, eta bigarren deklarazio bat konpilazio errorea da, ez exekuzio errorea, beraz konpilazioak azkar huts egiten du eta errorea erraza da ikusten. Eduki ezazu Gradle blokeko ABI zerrenda gehitzen dituzun karpetekin batera.

Egin kaleratze artefaktua proba konpilazioarekin bat

Debug APK batek tunela altxa dezake kaleratze bundle batek oraindik kraskatzen duen bitartean, bundle batek liburutegi natiboak beste forma batean paketatzen baititu eta artxibotik konprimatuta zerbitza baititzake. Bundle-tik eratorritako konpilazioek bakarrik huts egiten badute, gehitu hau gradle.properties fitxategian eta berrikonpilatu:

android.bundle.enableUncompressedNativeLibs=false

Gero egiaztatu instalatutako paketeak espero duzun ABIa jakinarazten duela, eta errepikatu egiaztapena 32 biteko eta 64 biteko gailu batean biak banatzen badituzu. Pakete kudeatzaileak hautatu zuen ABIa izendatzen du, beraz 32 bitetara itzuli den gailu bat hemen agertzen da, kraskada txosten batean agertu beharrean:

adb shell dumpsys package com.example.openvpn | grep -i primaryCpuAbi

ABI baterako falta den liburutegi batek jatorrizko baimen errorea gailu horretan bakarrik birsortzen du, eta horregatik probako telefono bakarrean ondo ibiltzea ez da froga. Banatu manifestuaren bandera, liburutegiaren izena eta bundlearen ezarpena elkarrekin; bat aldatzeak eta besteak ahazteak kraskada berera eramango zaitu. Konponbide iraunkorra mantentzen den nukleo bertsio batera aldatzea da, adabakia betiko eramaten ibili beharrean.