I henhold til et sett med forpliktelser i AOSP, kan Google begynne å begrense tilgangen til udokumenterte eller skjulte API-er i Android P. Mange navnemerke-apper bruker skjulte API-er for å øke funksjonaliteten, så effekten kan være utbredt.
Oppdatering 28.02.18: Google har publisert et blogginnlegg i dag som bekrefter endringene. Flere detaljer på slutten av artikkelen.
Mens noen Android-entusiaster er det spekulerer hvilken dessert neste versjon av Android vil bli oppkalt etter, er det noen interessante utviklinger som skjer bak kulissene. Vi har sett en få bemerkelsesverdige kommende funksjoner i Android P, men en nyere oppdagelse i Android Open Source Project (AOSP) har vist seg langt mer interessant. I henhold til disse nylige forpliktelsene, kan applikasjoner være begrenset fra å få tilgang til APIer som er udokumenterte i Android SDK (for eksempel APIer merket med javadoc-attributtet @hide).
Hvorfor dette betyr noe
Android Software Development Kit (SDK) gir utviklere API-biblioteker og verktøy som de trenger for å teste og bygge nye Android-applikasjoner. Med hver nye versjon av Android kommer en hel rekke nye APIer som er tilgjengelige for utviklere gjennom Android SDK. Hvilke APIer som er tilgjengelige for en app, avhenger av hvilken kompileringsSDKV-versjon utvikleren setter. Det er derfor Googles
Google-verter dokumentasjonssider for hver klasse og alle dens metoder som er tilgjengelige på hvert API-nivå. Dette er settet med dokumenterte APIer som er tilgjengelige i den offisielle Android SDK. Du kan enkelt bla gjennom listen over klasser ved å bruke en Android-app, for eksempel den nylig utgitte Android SDK Search-appen fra Android Engineer Jake Wharton.
Pris: Gratis.
4.1.
Imidlertid er ikke alle APIer som er tilgjengelige i hver Android-utgivelse dokumentert av Google, eller tilgjengelig i den offisielle Android SDK. Det er ofte nyttige APIer som er det udokumentert, men er likevel veldig nyttige. Det anbefales ikke at utviklere bygger appene sine ved å bruke udokumenterte eller skjulte APIer, men mange gjør det fordi det rett og slett ikke er noe alternativ om de vil tilby en bestemt funksjon. Utviklere som bruker skjulte eller udokumenterte APIer kan også ha et konkurransefortrinn, siden de kan tilby funksjoner som deres konkurrenter – som holder seg til APIene som tilbys av Android SDK—kan ikke.
Selv om jeg ikke kan gi en liste over apper som bruker udokumenterte APIer (utviklere deler sannsynligvis ikke hvilke de bruker fordi det ville gi konkurrentene et ben opp), er listen sannsynligvis heller stor. Dermed vil jeg konkludere med at det å forby tilgang til skjulte APIer vil være betydelig. Mark Murphy, grunnlegger av Commonsware, er enig:
Jeg er enig i vurderingen om at bulk-forbud av tilgang til @skjul-annoterte elementer vil være en stor sak, hvis det skjer. Forhåpentligvis er det få apper som får tilgang til disse elementene som en del av nøkkelfunksjonalitet. Imidlertid mistenker jeg at mange navnemerkeapper bruker dem av og til, direkte eller gjennom et bibliotek.
Hva skjer i Android P?
Disse kommende endringene ble først notert av XDA Senior Recognized Developer rovo89, utvikleren av Xposed Framework. Han påpekte to forpliktelser til meg, en av hvilken har vært slått sammen, som introduserer et nytt byggeverktøy kalt 'hiddenapi.' Dette verktøyet endrer tilgangsflaggene til alle klassemedlemmer i en DEX-fil if signaturene deres vises på en gråliste eller svarteliste for input, og i så fall vil de merkede metodene bli behandlet som interne APIer med begrenset adgang. Den andre forpliktelsen beskriver hvordan API-svartelisten fungerer; det hindrer tilgang til støvel klasse metoder og felt merket av den nevnte 'hiddenapi' som utviklere kan få tilgang til ved statisk kobling, refleksjon og JNI.
I følge rovo89 er sluttresultatet av disse to endringene i Android P følgende:
Hvis disse forpliktelsene slås sammen, vil det bety at apper ikke lenger kan bruke/få tilgang til skjulte APIer, dvs. klasser, metoder og felt som er annotert med @hide i AOSP og derfor ikke er en del av offisiell SDK. Dette ville ikke være et problem for Xposed-moduler, da jeg enkelt kan tilbakestille disse forpliktelsene eller tillate moduler å også få tilgang til disse APIene. Men det er mange apper som drar nytte av skjulte APIer, og de ville mislykkes i framtid.
Ytterligere forpliktelser viser faktisk at dette kan være hva Google planlegger. Dette begå sier følgende:
Selv om denne bestemte forpliktelsen ikke ble slått sammen da den ble forlatt til fordel for 3 mindre forpliktelser, beskriver forpliktelsesmeldingen formålet med disse endringene. Et annet sett med forplikter seg vise at Google vil foreslå alternativer til utviklere som prøver å bruke ikke-offentlige APIer:
Imidlertid er det ofte ingen alternativer til visse skjulte APIer. Vi i XDA kan snakke av erfaring her som Dessverre kan denne endringen bety slutten på noen innovative apper, eller det kan kreve noen apper med store navn for å redusere deres funksjonalitet. Denne kommende endringen ser ut til å være lik den siste nedbryting av tilgjengelighetstjenester (det var heldigvis satt på pause ettersom Google evaluerte innovative bruksområder). Mens de fleste apper som bruker udokumenterte API-er, gjør det av godartede årsaker, kan det være noen apper som har misbrukt dem til ondsinnede formål.
På grunn av dette kan Google låse tilgangen til alle skjulte API-er i Android P for å beskytte brukere mot de få som misbruker dem. Det er vanskelig å si hvor stor innvirkning dette kan ha på brukerne, men hvis du er en utvikler vurderer å se gjennom AOSP for å finne en innovativ bruk av en skjult API, så kan det være lurt revurdere.
Oppdatering: Google bekrefter
I en blogg innlegg publisert i dag, 28. februar, har Google bekreftet disse endringene. Siterer krasjrisiko for brukere og tvinger deretter utviklere til å rulle ut nødrettinger, Google sier at selskapet gradvis har gått i retning av å fraråde utviklere å få tilgang til ikke-SDK grensesnitt. Fra og med Android P, vil begrensningene utvides til å dekke Java-språkgrensesnittene til SDK.
Selskapet uttaler at "noen ikke-SDK-metoder og felt vil være begrenset," selv om de ikke utdypet hvilke som ville være begrenset. I utgangspunktet vil begrensningen fokusere på grensesnitt som sjelden brukes, og en stund vil selskapet tillate det utviklere å fortsette å bruke ikke-SDK-metoder og felt der overgangen til en SDK-metode er teknisk sett utfordrende. Imidlertid vil begrensningene etter hvert utvides, så utviklere av apper som bruker ikke-SDK-metoder bør gå over så snart som mulig som forberedelse til Android P. Når det gjelder metoder uten et SDK-alternativ, ber Google utviklere om å legge ut på deres feilsporer med mer informasjon.
Den neste forhåndsvisningen for utviklere, som tilsynelatende kommer snart, vil tillate utviklere å teste eksisterende apper mot svartelisten eller grålisten før den endelige utgivelsen.