AOSP: n sitoumusten mukaan Google saattaa alkaa rajoittaa pääsyä dokumentoimattomiin tai piilotettuihin sovellusliittymiin Android P: ssä. Monet nimimerkkisovellukset käyttävät piilotettuja sovellusliittymiä toiminnallisuuden lisäämiseen, joten vaikutus voi olla laajalle levinnyt.
Päivitys 28.2.18: Google on julkaissut tänään blogitekstin, jossa vahvistetaan muutokset. Tarkemmat tiedot artikkelin lopussa.
Vaikka jotkut Android-harrastajat ovat spekuloimalla minkä jälkiruoan mukaan seuraava Android-versio nimetään, kulissien takana tapahtuu mielenkiintoista kehitystä. Olemme havainneet a muutama huomionarvoinen Android P: n tulevat ominaisuudet, mutta uudempi löytö Android Open Source Projectissa (AOSP) on osoittautunut paljon mielenkiintoisemmaksi. Näiden viimeaikaisten sitoumusten mukaan sovelluksia voidaan rajoittaa pääsemästä sovellusliittymiin, jotka ovat dokumentoimattomia Android SDK: ssa (kuten API: t, jotka on merkitty javadocin @hide-attribuutilla).
Miksi tällä on väliä
Android Software Development Kit (SDK) tarjoaa kehittäjille API-kirjastoja ja työkaluja, joita he tarvitsevat uusien Android-sovellusten testaamiseen ja rakentamiseen. Jokaisen uuden Android-julkaisun mukana tulee joukko uusia sovellusliittymiä, jotka ovat kehittäjien saatavilla Android SDK: n kautta. Sovelluksen käytettävissä olevat API: t riippuvat kehittäjän asettamasta käännösSDKV-versiosta. Siksi Googlen
uudet Play Kaupan vaatimukset ovat niin merkittäviä – se pakottaa sovellukset päivittämään ja siirtymään käyttämään uudempia sovellusliittymiä.Googlen isännät dokumentaatiosivut jokaiselle luokalle ja kaikille sen menetelmille, jotka ovat saatavilla kullakin API-tasolla. Nämä ovat dokumentoituja sovellusliittymiä, jotka ovat saatavilla virallisessa Android SDK: ssa. Voit selata luokkaluetteloa helposti käyttämällä Android-sovellusta, kuten Android Engineerin äskettäin julkaisemaa Android SDK Search -sovellusta. Jake Wharton.
Hinta: Ilmainen.
4.1.
Google ei kuitenkaan dokumentoi kaikkia kussakin Android-julkaisussa saatavilla olevia sovellusliittymiä eivätkä ne ole saatavilla virallisessa Android SDK: ssa. Usein löytyy hyödyllisiä API: ita dokumentoimaton, mutta ne ovat kuitenkin erittäin hyödyllisiä. Ei ole suositeltavaa, että kehittäjät rakentavat sovelluksiaan dokumentoimattomien tai piilotettujen sovellusliittymien avulla, mutta monet tekevät niin, koska ei yksinkertaisesti ole vaihtoehtoa, jos he haluavat tarjota tietyn ominaisuuden. Kehittäjät, jotka käyttävät piilotettuja tai dokumentoimattomia sovellusliittymiä, voivat myös asettaa itsensä kilpailuetulle, koska he voivat tarjota ominaisuuksia, joita kilpailijansa – jotka pitävät kiinni Androidin tarjoamista API: ista SDK – ei voi.
Vaikka en voi tarjota luetteloa sovelluksista, jotka käyttävät dokumentoimattomia sovellusliittymiä (kehittäjät eivät todennäköisesti jaa mitä he käyttävät, koska se antaisi kilpailijoilleen jalkansa), luettelo on luultavasti melkoinen suuri. Näin ollen päättelen, että piilotettujen sovellusliittymien käytön kieltäminen olisi merkittävää. Mark Murphy, perustaja Commonsware, samaa mieltä:
Olen samaa mieltä arviosta, jonka mukaan @piilota-merkittyjen kohteiden pääsyn joukkokielto on iso juttu, jos se tapahtuu. Toivottavasti harvat sovellukset käyttävät näitä kohteita osana keskeisiä toimintoja. Epäilen kuitenkin, että monet nimimerkkisovellukset käyttävät niitä silloin tällöin, suoraan tai kirjaston kautta.
Mitä Android P: ssä tapahtuu?
Nämä tulevat muutokset huomasi ensimmäisenä XDA Senior Recognized Developer rovo89, kehittäjä Xposed Framework. Hän osoitti minulle kaksi sitoumusta, yksi niistä mikä on ollut yhdistetty, joka esittelee uuden rakennustyökalun nimeltä "hiddenapi". Tämä työkalu muuttaa kaikkien DEX-tiedoston luokan jäsenten käyttöoikeuslippuja if heidän allekirjoituksensa näkyvät harmaalla tai mustalla listalla, ja jos on, merkittyjä menetelmiä käsitellään sisäisinä API: ina, joilla on rajoitettu pääsy. Toinen sitoumus kuvaa, kuinka API musta lista toimii; se estää pääsyn boot luokka menetelmät ja kentät, jotka on merkitty edellä mainitulla "hiddenapilla", joita kehittäjät voivat käyttää staattisen linkin, reflektoinnin ja JNI: n avulla.
Rovo89:n mukaan näiden kahden Android P: n muutoksen lopputulos on seuraava:
Jos nämä sitoumukset yhdistetään, se tarkoittaisi, että sovellukset eivät voi enää käyttää/käyttää piilotettuja sovellusliittymiä. luokat, menetelmät ja kentät, joihin on merkitty @hide AOSP: ssä ja jotka eivät siksi ole osa virallinen SDK. Tämä ei olisi ongelma Xposed-moduuleille, koska voisin helposti perua nämä toimitukset tai sallia moduulien käyttää näitä sovellusliittymiä. Mutta on monia sovelluksia, jotka hyödyntävät piilotettuja sovellusliittymiä, ja ne epäonnistuvat tulevaisuutta.
Itse asiassa lisäsitoumukset osoittavat, että tämä saattaa olla Googlen suunnittelema. Tämä tehdä toteaa seuraavaa:
Vaikka tätä nimenomaista sitoumusta ei yhdistetty, koska se hylättiin kolmen pienemmän sitoumuksen hyväksi, toimitusviesti kuvaa näiden muutosten tarkoitusta. Toinen sarja sitoutuu osoittavat, että Google ehdottaa vaihtoehtoja kehittäjille, jotka haluavat käyttää ei-julkisia sovellusliittymiä:
Tietyille piilotetuille API-liittymille ei kuitenkaan usein ole vaihtoehtoja. Me XDA: lla voimme puhua kokemuksesta täällä valitettavasti tämä muutos saattaa merkitä joidenkin innovatiivisten sovellusten loppua tai se saattaa edellyttää joidenkin nimekkäiden sovellusten vähentämistä toiminnallisuutta. Tämä tuleva muutos näyttää hengeltään samanlaiselta kuin viimeaikainen esteettömyyspalveluita vastaan (tämä oli onneksi keskeytetty kuten Google arvioi innovatiivisia käyttötapoja). Vaikka useimmat dokumentoimattomia sovellusliittymiä käyttävät sovellukset tekevät niin hyväntahtoisista syistä, jotkut sovellukset voivat käyttää niitä väärin ilkeisiin tarkoituksiin.
Tämän vuoksi Google saattaa estää pääsyn kaikkiin piilotettuihin sovellusliittymiin Android P: ssä suojellakseen käyttäjiä harvoilta väärinkäyttäviltä käyttäjiltä. On vaikea sanoa, kuinka paljon tämä voi vaikuttaa käyttäjiin, mutta jos olet kehittäjä harkitset etsimistä AOSP: n kautta löytääksesi innovatiivisen käyttötavan piilotetulle API: lle, niin saatat haluta harkita uudelleen.
Päivitys: Google vahvistaa
Jonkin sisällä blogipostaus julkaistu tänään 28. helmikuuta, Google on vahvistanut nämä muutokset. Google viittaa käyttäjien kaatumisriskeihin ja pakottaa kehittäjät ottamaan käyttöön hätäkorjauksia toteaa, että yritys on vähitellen siirtymässä luopumaan kehittäjiä käyttämästä muita kuin SDK: ta käyttöliittymät. Android P: stä alkaen rajoitukset laajenevat kattamaan SDK: n Java-kielirajapinnat.
Yhtiö toteaa, että "jotkin muut kuin SDK: n menetelmät ja kentät ovat rajoitettuja", vaikka he eivät tarkentaneet, mitkä niistä rajoitetaan. Aluksi rajoitus kohdistuu harvoin käytettyihin rajapintoihin, ja jonkin aikaa yritys sallii Kehittäjät jatkavat muiden kuin SDK-menetelmien ja -kenttien käyttöä, jos siirtyminen SDK-menetelmään on teknisesti välttämätöntä haastava. Lopulta rajoitukset kuitenkin laajenevat, joten muita kuin SDK-menetelmiä käyttävien sovellusten kehittäjien tulisi siirtyä mahdollisimman pian Android P: tä valmistautuessaan. Mitä tulee menetelmiin, joissa ei ole SDK-vaihtoehtoa, Google pyytää kehittäjiä julkaisemaan julkaisunsa bugien seuranta lisätietojen kera.
Seuraava, näennäisesti pian saapuva esikatselu, jonka avulla kehittäjät voivat testata olemassa olevia sovelluksia mustalla tai harmaalla listalla ennen lopullista julkaisua.