Ifølge et sæt commits i AOSP kan Google begynde at begrænse adgangen til udokumenterede eller skjulte API'er i Android P. Mange navnemærke-apps bruger skjulte API'er til at øge funktionaliteten, så effekten kan være udbredt.
Opdatering 28.02.18: Google har offentliggjort et blogindlæg i dag, der bekræfter ændringerne. Flere detaljer i slutningen af artiklen.
Mens nogle Android-entusiaster er spekulerer hvilken dessert den næste version af Android bliver opkaldt efter, er der nogle interessante udviklinger i gang bag kulisserne. Vi har set en få bemærkelsesværdige kommende funktioner i Android P, men en nyere opdagelse i Android Open Source Project (AOSP) har vist sig langt mere interessant. Ifølge disse nylige tilsagn kan applikationer være begrænset fra at få adgang til API'er, der er udokumenterede i Android SDK (såsom API'er markeret med javadoc'ens attribut @hide).
Hvorfor dette betyder noget
Android Software Development Kit (SDK) giver udviklere API-biblioteker og værktøjer, som de skal bruge for at teste og bygge nye Android-applikationer. Med hver ny udgivelse af Android kommer en lang række nye API'er, der er tilgængelige for udviklere gennem Android SDK. Hvilke API'er der er tilgængelige for en app afhænger af, hvilken compileSDKVersion udvikleren indstiller. Det er derfor Googles
Google-værter dokumentationssider for hver klasse og alle dens metoder, der er tilgængelige på hvert API-niveau. Disse er det sæt af dokumenterede API'er, der er tilgængelige i den officielle Android SDK. Du kan nemt gennemse listen over klasser ved hjælp af en Android-app, såsom den nyligt udgivne Android SDK Search-app fra Android Engineer Jake Wharton.
Pris: Gratis.
4.1.
Det er dog ikke alle API'er, der er tilgængelige i hver Android-udgivelse, som er dokumenteret af Google eller tilgængelige i den officielle Android SDK. Det er der ofte nyttige API'er udokumenteret, men er ikke desto mindre meget nyttige. Det anbefales ikke, at udviklere bygger deres apps ved hjælp af udokumenterede eller skjulte API'er, men mange gør det, fordi der simpelthen ikke er noget alternativ, hvis de vil tilbyde en bestemt funktion. Udviklere, der bruger skjulte eller udokumenterede API'er, kan også give sig selv en konkurrencefordel, da de kan tilbyde funktioner, som deres konkurrenter - som holder sig til de API'er, der tilbydes af Android SDK – kan ikke.
Selvom jeg ikke kan give en liste over apps, der bruger udokumenterede API'er (udviklere deler sandsynligvis ikke hvilke de bruger, fordi det ville give deres konkurrenter et ben op), er listen nok snarere stor. Derfor vil jeg konkludere, at det ville være væsentligt at forbyde adgang til skjulte API'er. Mark Murphy, grundlægger af Commonsware, er enig:
Jeg er enig i vurderingen af, at bulk-forbud mod adgang til @skjul-annoterede elementer vil være en stor sag, hvis det sker. Forhåbentlig er der få apps, der får adgang til disse elementer som en del af nøglefunktionalitet. Jeg har dog mistanke om, at masser af navnemærke-apps bruger dem lejlighedsvis, direkte eller gennem et bibliotek.
Hvad sker der i Android P?
Disse kommende ændringer blev først bemærket af XDA Senior Recognized Developer rovo89, udvikleren af Xposed Framework. Han påpegede to forpligtelser til mig, en af hvilken har været fusioneret, som introducerer et nyt byggeværktøj kaldet 'hiddenapi.' Dette værktøj ændrer adgangsflag for alle klassemedlemmer i en DEX-fil if deres signaturer vises på en input gråliste eller sortliste, og hvis det er tilfældet, vil de markerede metoder blive behandlet som interne API'er med begrænset adgang. Den anden commit beskriver, hvordan API-sortlisten fungerer; det forhindrer adgang til støvle klasse metoder og felter markeret med den førnævnte 'hiddenapi', som udviklere kan få adgang til ved statisk linking, refleksion og JNI.
Ifølge rovo89 er slutresultatet af disse to ændringer i Android P følgende:
Hvis disse commits bliver slået sammen, vil det betyde, at apps ikke længere kan bruge/få adgang til skjulte API'er, dvs. klasser, metoder og felter, som er annoteret med @skjul i AOSP og derfor ikke er en del af officielle SDK. Dette ville ikke være et problem for Xposed-moduler, da jeg nemt kunne gendanne disse commits eller tillade, at moduler også få adgang til disse API'er. Men der er mange apps, der drager fordel af skjulte API'er, og de ville mislykkes i fremtid.
Faktisk viser yderligere tilsagn, at dette kan være, hvad Google planlægger. Det her begå anfører følgende:
Selvom denne særlige commit ikke blev slået sammen, da den blev opgivet til fordel for 3 mindre commits, beskriver commit-meddelelsen formålet med disse ændringer. Endnu et sæt forpligter sig vise, at Google vil foreslå alternativer til udviklere, der søger at bruge ikke-offentlige API'er:
Der er dog ofte ingen alternativer til visse skjulte API'er. Vi hos XDA kan tale af erfaring her som desværre kan denne ændring betyde enden på nogle innovative apps, eller det kan kræve nogle store navne-apps for at reducere deres funktionalitet. Denne kommende ændring ligner i ånden den seneste nedkæmpelse af tilgængelighedstjenester (det var heldigvis sat på pause som Google vurderede innovative anvendelser). Mens de fleste apps, der bruger udokumenterede API'er, gør det af godartede årsager, kan der være nogle apps, der har misbrugt dem til ondsindede formål.
På grund af dette kan Google låse adgangen til alle skjulte API'er i Android P for at beskytte brugere mod de få, der misbruger dem. Det er svært at sige, hvor stor en indflydelse dette kan have på brugerne, men hvis du er en udvikler overvejer at kigge gennem AOSP for at finde en innovativ brug af en skjult API, så vil du måske genoverveje.
Opdatering: Google bekræfter
I en blogindlæg offentliggjort i dag, den 28. februar, har Google bekræftet disse ændringer. Citerer nedbrudsrisici for brugere og tvinger efterfølgende udviklere til at udrulle nødrettelser, Google fastslår, at virksomheden gradvist har bevæget sig mod at afskrække udviklere fra at få adgang til ikke-SDK grænseflader. Fra Android P vil begrænsningerne udvides til at dække Java-sproggrænseflader i SDK.
Virksomheden oplyser, at "nogle ikke-SDK metoder og felter vil være begrænset," selvom de ikke uddybede, hvilke der ville være begrænset. I første omgang vil begrænsningen fokusere på grænseflader, der sjældent bruges, og i et stykke tid vil virksomheden tillade det udviklere til at fortsætte med at bruge ikke-SDK-metoder og felter, hvor overgangen til en SDK-metode er teknisk set udfordrende. Men i sidste ende vil begrænsningerne udvides, så udviklere af apps, der bruger ikke-SDK-metoder, bør skifte så hurtigt som muligt som forberedelse til Android P. Hvad angår metoder uden et SDK-alternativ, anmoder Google udviklere om at skrive på deres bug tracker med flere oplysninger.
Den næste forhåndsvisning af udviklere, der tilsyneladende ankommer snart, vil give udviklere mulighed for at teste eksisterende apps mod sortlisten eller grålisten før den endelige udgivelse.