OpenVPN-i abibinaar ei tööta Android 10-s: juurdepääs keelatud

Rakendus töötas Android 9-s ja sureb samas telefonis pärast Android 10-ks uuendamist. Teie profiil on puutumatu, sertifikaadid on samad ja krahh saabub enne igasugust autentimisliiklust. Logcat näitab kõigepealt nullosutit ja paar rida kõrgemal seisab Cannot run program ...: error=13, Permission denied. See teade räägib faili käivitamisest, mitte teie konfiguratsiooni lugemisest.

Mida viga 13 tegelikult keeldub tegemast

Android 10, API tase 29, keelas rakendustel käivitada faile, mille nad oma andmekataloogi kirjutasid. Reegel sihib salvestusruumi, mis on esmalt kirjutatav ja seejärel käivitatav, ja täpselt seda loob käivitaja, mis kopeerib assetitest. ics-openvpn tuuma vanemad buildid pakivad esimesel käivitusel APK-st lahti käivitatava faili openvpn ja käivitavad selle abil ProcessBuilder. Lahtipakkimine õnnestub endiselt, keelatud on just käivitamine. API 29-le suunatud rakendus pärib reegli ka siis, kui see töötab seadmes, mis tuli välja vanema versiooniga, mistõttu võib uuendus lõhkuda buildi, mida keegi ei puutunud.

Keeldumises pole midagi ühele kaustanimele omast. Faili, mille rakendus oma andmekataloogi alla lõi, käsitletakse mittekäivitatavana sõltumata teest, seega getFilesDir(), getCacheDir() ja kohandatud alamkataloog ebaõnnestuvad kõik ühtemoodi.

Eraldage abifaili krahh profiiliprobleemist

Lugege logi protsessi käivitamise ümbruses, mitte ärge kerige ülalt. Otsitav signatuur on rida error=13, ja selle kohal olev pinu jälg nimetab tavaliselt käivitaja meetodi, mis kutsus ProcessBuilder:

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

Kui abifail ei käivitunud kunagi, ei näe te üldse ühtki OpenVPN-i logi väljundit: ei šifri läbirääkimist, ei lükatud marsruute, ei DNS-i konfiguratsiooni. Kui need read siiski ilmuvad ja tõrge tuleb hiljem, töötas binaar ja probleem on profiilis, serveris või marsruutimiskihis. See üks erinevus säästab palju aega, mis muidu kuluks failide .ovpn muutmisele, mis polnud kunagi süüdi. See ütleb teile ka, kumb kahest allolevast parandusest teil tegelikult vaja on.

Kontrollige ka API taset seadmes, mida testite, mitte seda, mis on teie buildi konfiguratsioonis. API 28 emulaatori pilt ei taasta midagi, sest piirang hammustab alles alates 29-st ülespoole. Kontrollige samal ajal siht-SDK-d oma buildi failis: just selle tõstmine toob reegli sisse.

adb shell getprop ro.build.version.sdk

Miks binaari mujale kopeerimine ei aita

Ilmselge möödaviik, abifaili kirjutamine teise kirjutatavasse kataloogi, ebaõnnestub samal põhjusel nagu originaal. Android lubab endiselt käivitada jagatud teeke, mis on paigaldatud rakenduse natiivsete teekide kataloogi, sest need pakendab paigaldaja, mitte ei kirjutata neid käitusajal. See kataloog on ainus koht, kuhu käivitaja peaks osutama. Kõik, mille te ise käitusajal lahti pakite, ükskõik kuidas te seda nimetate, jääb keelatud kategooriasse.

Väline salvestusruum on hullem: see on mountitud noexec-iga ja sinna pandud abifaili ei saa ükski rakendus käivitada. Rakenduse andmete kustutamine ei taasta samuti vana käitumist, sest järgmine käivitus loob lihtsalt sama mittekäivitatava koopia.

Suunake käivitaja pakendatud teegile

Nimetage abifail ümber jagatud teegi nimeks ja tarnige see jniLibs alla iga toetatud ABI jaoks, seejärel laske käivitajal alates API 28-st tagastada paigaldatud teegi tee:

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

Teek tuleb paigaldamise ajal lahti pakkida, et see tee sisaldaks päris faili, seega määrake android:extractNativeLibs="true" elemendil <application>. Kui manifesti liitja toob sisse teise väärtuse, lisage selle kõrvale tools:replace="android:extractNativeLibs". application-elemendi viide dokumenteerib, mida see atribuut juhib.

Pöörake tähelepanu dubleeritud lokaalsele muutujale, kui paigute käivitajat käsitsi. Vanemad allikad deklareerivad nativeAPI hiljem samas meetodis ja teine deklaratsioon on kompileerimisviga, mitte käitusaegne viga, seega build ebaõnnestub kiiresti ja viga on lihtne märgata. Hoidke Gradle'i ploki ABI loend kooskõlas kaustadega, mille lisate.

Viige väljalaskeartefakt testbuildiga kooskõlla

Debug-APK suudab tunnelit tõsta, samal ajal kui väljalaske-bundle ikka kukub, sest bundle pakib natiivsed teegid teistsugusel kujul ja võib neid arhiivist pakitud kujul serveerida. Kui ainult bundle'ist tulenevad buildid ebaõnnestuvad, lisage see gradle.properties faili ja ehitage uuesti:

android.bundle.enableUncompressedNativeLibs=false

Seejärel kinnitage, et paigaldatud pakett teatab ABI, mida ootate, ja korrake kontrolli 32-bitises ja 64-bitises seadmes, kui tarnite mõlemat. Paketihaldur nimetab ABI, mille see valis, seega 32 bitile tagasi langenud seade ilmub siin, mitte krahhiaruandes:

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

Ühe ABI jaoks puuduv teek taastoodab algse õigusetõrke ainult selles seadmes, mistõttu üks edukas testtelefon ei ole tõestus. Tarnige manifesti lipp, teegi nimi ja bundle'i seade koos; kui muudate ühte ja unustate teised, olete tagasi sama krahhi juures. Kestev lahendus on liikuda hooldatud tuuma väljalaskeni, mitte kanda plaastrit igavesti.