Vastavalt AOSP-s tehtud kohustustele võib Google hakata piirama juurdepääsu dokumenteerimata või varjatud API-dele Android P-s. Paljud nimemärgirakendused kasutavad funktsionaalsuse suurendamiseks peidetud API-sid, seega võib mõju olla laialt levinud.
Värskendus 28.02.18: Google avaldas täna muudatusi kinnitava ajaveebipostituse. Täpsemalt artikli lõpus.
Kuigi mõned Androidi entusiastid on spekuleerides millise magustoidu järgi Androidi järgmine versioon nime saab, on kulisside taga toimumas huvitavaid arenguid. Oleme märganud a vähe tähelepanu väärivaid Android P tulevased funktsioonid, kuid uuem avastus Androidi avatud lähtekoodiga projektis (AOSP) on osutunud palju huvitavamaks. Nende hiljutiste kohustuste kohaselt võidakse rakendustel piirata juurdepääsu API-dele, mis on Android SDK-s dokumenteerimata (nt API-d, mis on tähistatud javadoci atribuudiga @hide).
Miks see oluline on
Androidi tarkvaraarenduskomplekt (SDK) pakub arendajatele API-teeke ja tööriistu, mida nad vajavad uute Androidi rakenduste testimiseks ja loomiseks. Iga uue Androidi väljalasega kaasneb terve hulk uusi API-sid, mis on arendajatele Android SDK kaudu saadaval. Millised API-d on rakendusele saadaval, sõltuvad sellest, millise SDKV-versiooni kompileerimise arendaja määrab. Sellepärast Google'i oma
Google hosts dokumentatsiooni leheküljed iga klassi ja kõigi selle meetodite jaoks, mis on saadaval igal API tasemel. Need on dokumenteeritud API-de komplekt, mis on saadaval ametlikus Androidi SDK-s. Saate hõlpsasti sirvida klasside loendit, kasutades Androidi rakendust, näiteks Android Engineeri hiljuti välja antud Android SDK otsingurakendust Jake Wharton.
Hind: tasuta.
4.1.
Google ei dokumenteeri aga kõiki Androidi versioonides saadaolevaid API-sid ega ole saadaval ametlikus Androidi SDK-s. Sageli on kasulikke API-sid dokumenteerimata, kuid on sellest hoolimata väga kasulikud. Arendajatel ei soovitata luua oma rakendusi dokumenteerimata või peidetud API-de abil, kuid paljud teevad seda, sest teatud funktsiooni pakkumisel pole lihtsalt alternatiivi. Arendajad, kes kasutavad peidetud või dokumenteerimata API-sid, võivad end samuti konkurentsieelisele seada, kuna nad saavad pakkuda funktsioone, mida nende konkurendid, kes jäävad Androidi pakutavate API-de juurde SDK – ei saa.
Kuigi ma ei saa esitada loendit rakendustest, mis kasutavad dokumenteerimata API-sid (arendajad ilmselt ei jaga milliseid nad kasutavad, sest see annaks konkurentidele jalgu), on nimekiri ilmselt pigem suur. Seega järeldan, et varjatud API-dele juurdepääsu keelamine oleks märkimisväärne. Mark Murphy, asutaja Commonsware, nõustub:
Nõustun hinnanguga, et @peida märkustega üksustele juurdepääsu hulgi keelamine on suur asi, kui see juhtub. Loodetavasti pääsevad vähesed rakendused nendele üksustele põhifunktsioonide osana juurde. Siiski kahtlustan, et paljud nimemärgirakendused kasutavad neid aeg-ajalt otse või raamatukogu kaudu.
Mis toimub Android P-s?
Neid eelseisvaid muudatusi märkis esmakordselt XDA tunnustatud vanemarendaja rovo89, arendaja Xposed Framework. Ta juhtis mulle tähelepanu kahele kohustusele, ühele neist mis on olnud liidetud, mis tutvustab uut ehitustööriista nimega "hiddenapi". See tööriist muudab kõigi klassiliikmete juurdepääsulippe DEX-failis if nende allkirjad ilmuvad sisendi hallis või mustas nimekirjas ja kui jah, siis käsitletakse märgitud meetodeid kui sisemisi API-sid, millel on piiratud juurdepääs. Teine kohustus kirjeldab API musta nimekirja toimimist; see takistab juurdepääsu saapaklass meetodid ja väljad, mis on tähistatud ülalnimetatud 'hiddenapi'ga, millele arendajad pääsevad juurde staatilise linkimise, peegelduse ja JNI kaudu.
Rovo89 sõnul on nende kahe Android P muudatuse lõpptulemus järgmine:
Kui need kohustused liidetakse, tähendaks see, et rakendused ei saa enam peidetud API-sid kasutada/juurde pääseda. klassid, meetodid ja väljad, millele on AOSP-s lisatud märkused @hide ja mis seetõttu ei ole osa ametlik SDK. See ei oleks Xposedi moodulite puhul probleem, kuna saan need sissekanded hõlpsalt tagasi võtta või lubada moodulitel ka juurdepääsu nendele API-dele. Kuid on palju rakendusi, mis kasutavad ära peidetud API-sid ja need ebaõnnestuvad tulevik.
Tõepoolest, edasised kohustused näitavad, et see võib olla see, mida Google plaanib. See pühenduma teatab järgmist:
Kuigi seda konkreetset kohustust ei liidetud, kuna see loobuti kolme väiksema kohustuse kasuks, kirjeldab kohustuste sõnum nende muudatuste eesmärki. Veel üks komplekt kohustab näidata, et Google soovitab alternatiive arendajatele, kes soovivad kasutada mitteavalikke API-sid:
Siiski pole teatud peidetud API-dele sageli alternatiive. Meie, XDA, saame rääkida oma kogemusest kahjuks võib see muudatus tähendada mõne uuendusliku rakenduse lõppu või mõne nimeka rakenduse puhul nende funktsionaalsust. See eelseisev muudatus näib olemuselt sarnane hiljutise muudatusega juurdepääsetavuse teenuste mahasurumine (see oli õnneks peatatud nagu Google hindas uuenduslikke kasutusviise). Kuigi enamik rakendusi, mis kasutavad dokumenteerimata API-sid, teevad seda healoomulistel põhjustel, võivad mõned rakendused neid pahatahtlikel eesmärkidel kuritarvitada.
Seetõttu võib Google lukustada juurdepääsu kõigile Android P peidetud API-dele, et kaitsta kasutajaid väheste nende kuritarvitajate eest. Raske on öelda, kui suurt mõju see kasutajatele võib avaldada, kuid kui olete arendaja kui kaalute varjatud API uuendusliku kasutusvõimaluse leidmiseks AOSP-d, siis võiksite seda teha uuesti läbi mõelda.
Värskendus: Google kinnitab
Sees ajaveebi postitus täna, 28. veebruaril avaldatud, kinnitas Google need muudatused. Google, viidates kasutajate krahhiriskidele ja sunnides seejärel arendajaid hädaolukorras parandusi välja töötama väidab, et ettevõte on järk-järgult liikunud selle poole, et takistada arendajaid mitte-SDK-le juurde pääsemast liidesed. Alates Android P-st laienevad piirangud SDK Java keeleliidestele.
Ettevõte teatab, et "mõned mitte-SDK meetodid ja väljad on piiratud", kuigi nad ei täpsustanud, milliseid neist piiratakse. Esialgu keskendub piirang harva kasutatavatele liidestele ja mõnda aega ettevõte lubab arendajad jätkama mitte-SDK meetodite ja väljade kasutamist, kus SDK meetodile üleminek on tehniliselt vajalik väljakutseid pakkuv. Kuid lõpuks piirangud laienevad, nii et mitte-SDK-meetodeid kasutavate rakenduste arendajad peaksid Android P-ks valmistudes võimalikult kiiresti üle minema. Mis puutub SDK alternatiivita meetoditesse, siis Google palub arendajatel oma kohta postitada veajälgija rohkema infoga.
Järgmine arendaja eelvaade, mis ilmselt peagi saabub, võimaldab arendajatel testida olemasolevaid rakendusi mustas või hallis loendis enne lõplikku väljalaset.