Faili saidizi ya OpenVPN inashindwa kwenye Android 10: ruhusa imekataliwa

Programu ilifanya kazi kwenye Android 9 na hufa kwenye simu hiyo hiyo baada ya sasisho la Android 10. Wasifu wako haujaguswa, vyeti ni vile vile, na ajali huja kabla ya trafiki yoyote ya uthibitishaji. logcat huonyesha kielekezi sufuri kwanza, na mistari michache juu yake kuna Cannot run program ...: error=13, Permission denied. Ujumbe huo unahusu kuendesha faili, si kusoma usanidi wako.

Kosa 13 linakataa nini hasa

Android 10, kiwango cha API 29, ilisimamisha programu kuendesha faili walizokuwa wakiandika kwenye saraka yao ya data. Sheria inalenga hifadhi inayoweza kuandikwa kwanza kisha kuendeshwa, na ndivyo hasa kianzishi kinachonakili kutoka assets huunda. Miundo ya zamani ya kiini cha ics-openvpn hufungua faili inayoweza kuendeshwa openvpn kutoka APK kwenye mbio za kwanza na kuianzisha kwa ProcessBuilder. Ufunguzi bado unafanikiwa; kinachokataliwa ni uendeshaji. Programu inayolenga API 29 hurithi sheria hiyo hata inapofanya kazi kwenye kifaa kilichotolewa na toleo la zamani, ndiyo sababu sasisho linaweza kuvunja muundo ambao hakuna aliyegusa.

Hakuna chochote katika kukataa ambacho ni mahususi kwa jina moja la folda. Faili ambalo programu iliunda chini ya saraka yake ya data linachukuliwa kuwa haliwezi kuendeshwa bila kujali njia, kwa hiyo getFilesDir(), getCacheDir() na saraka ndogo maalum zote hushindwa kwa namna moja.

Tenganisha ajali ya kisaidizi na tatizo la wasifu

Soma kumbukumbu karibu na kuanza kwa mchakato badala ya kusogeza kutoka juu. Sahihi ya kutafuta ni mstari error=13, na ufuatiliaji wa rafu juu yake kwa kawaida hutaja mbinu ya kianzishi iliyoita ProcessBuilder:

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

Ikiwa kisaidizi hakikuwahi kuanza, hutaona matokeo yoyote ya kumbukumbu ya OpenVPN: hakuna majadiliano ya misimbo, hakuna njia zilizosukumwa, hakuna usanidi wa DNS. Ikiwa mistari hiyo itaonekana na kushindwa kuje baadaye, faili tendaji ilifanya kazi na tatizo liko kwenye wasifu, seva au tabaka la uelekezaji. Tofauti hiyo moja huokoa muda mwingi ambao ungetumika kuhariri faili .ovpn ambazo hazikuwa na hatia kamwe. Pia inakuambia ni ipi kati ya marekebisho mawili hapa chini unahitaji kweli.

Angalia pia kiwango cha API kwenye kifaa unachojaribu, si kile kilicho kwenye usanidi wa muundo wako. Picha ya emulator kwenye API 28 haizalishi chochote, kwa sababu kizuizi huuma tu kuanzia 29 kwenda juu. Wakati huo huo angalia SDK lengwa kwenye faili yako ya muundo: kuipandisha ndiko kunavuta sheria hii ndani.

adb shell getprop ro.build.version.sdk

Kwa nini kunakili faili tendaji mahali pengine hakusaidii

Suluhisho dhahiri, kuandika kisaidizi kwenye saraka nyingine inayoweza kuandikwa, hushindwa kwa sababu ile ile ambayo ya awali ilishindwa. Android bado inaruhusu kuendesha maktaba zinazoshirikiwa zilizosakinishwa kwenye saraka ya maktaba asilia za programu, kwa sababu msakinishaji huzifunga na si kwamba huandikwa wakati wa uendeshaji. Saraka hiyo ndiyo mahali pekee ambapo kianzishi kinapaswa kuelekeza. Kitu chochote unachofungua mwenyewe wakati wa uendeshaji, kwa jina lolote, hubaki katika kundi lililokataliwa.

Hifadhi ya nje ni mbaya zaidi: imepachikwa kwa noexec, na kisaidizi kilichowekwa hapo hakiwezi kuanzishwa na programu yoyote. Kufuta data ya programu pia hakurudishi tabia ya zamani, kwa sababu mbio zinazofuata huunda tena nakala ile ile isiyoweza kuendeshwa.

Elekeza kianzishi kwenye maktaba iliyofungwa

Badilisha jina la kisaidizi kuwa jina la maktaba inayoshirikiwa na ukitoa chini ya jniLibs kwa kila ABI unayoiunga mkono, kisha kianzishi kirudishe njia ya maktaba iliyosakinishwa kuanzia API 28:

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

Maktaba lazima ifunguliwe wakati wa usakinishaji ili njia hiyo iwe na faili halisi, kwa hiyo weka android:extractNativeLibs="true" kwenye kipengele <application>. Ikiwa kiunganishi cha manifest kinaleta thamani nyingine, ongeza tools:replace="android:extractNativeLibs" kando yake. marejeleo ya kipengele cha application huandika kile sifa hii inadhibiti.

Jihadhari na kigezo cha ndani kilichorudiwa unapobandika kianzishi kwa mkono. Vyanzo vya zamani hutangaza nativeAPI baadaye katika mbinu hiyo hiyo, na tangazo la pili ni hitilafu ya kuandaa si ya uendeshaji, kwa hiyo muundo hushindwa haraka na kosa huonekana kwa urahisi. Weka orodha ya ABI kwenye kizuizi cha Gradle sawa na folda unazoongeza.

Fanya bidhaa ya toleo ilingane na muundo wa jaribio

APK ya utatuzi inaweza kuinua handaki wakati bundle ya toleo bado inaanguka, kwa sababu bundle hufunga maktaba asilia kwa umbo tofauti na inaweza kuzitoa zikiwa zimebanwa kutoka kwenye kumbukumbu. Ikiwa ni miundo inayotokana na bundle pekee inayoshindwa, ongeza hii kwenye gradle.properties na uunde tena:

android.bundle.enableUncompressedNativeLibs=false

Kisha thibitisha kwamba kifurushi kilichosakinishwa kinaripoti ABI unayotarajia, na rudia ukaguzi kwenye kifaa cha biti 32 na biti 64 ikiwa unatoa vyote viwili. Msimamizi wa vifurushi hutaja ABI iliyochagua, kwa hiyo kifaa kilichorudi kwenye biti 32 huonekana hapa badala ya kwenye ripoti ya ajali:

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

Maktaba inayokosekana kwa ABI moja huzalisha tena kosa la awali la ruhusa kwenye kifaa hicho pekee, ndiyo sababu simu moja ya jaribio iliyofanikiwa si uthibitisho. Toa bendera ya manifest, jina la maktaba na mpangilio wa bundle pamoja; ukibadilisha kimoja na kusahau vingine unarudi kwenye ajali ile ile. Suluhisho la kudumu ni kuhamia toleo la kiini linalotunzwa badala ya kubeba kiraka milele.