Volgens een reeks afspraken in AOSP zou Google de toegang tot ongedocumenteerde of verborgen API's in Android P kunnen gaan beperken. Veel merkapps gebruiken verborgen API's om de functionaliteit te vergroten, dus het effect kan wijdverspreid zijn.
Bijgewerkt 28-2-2018: Google heeft vandaag een blogpost gepubliceerd waarin de wijzigingen worden bevestigd. Meer details aan het einde van het artikel.
Terwijl sommige Android-enthousiastelingen dat wel zijn speculeren naar welk dessert de volgende versie van Android zal worden vernoemd, zijn er achter de schermen een aantal interessante ontwikkelingen gaande. We hebben een gezien weinig noemenswaardig aankomende functies in Android P, maar een recentere ontdekking in het Android Open Source Project (AOSP) is veel interessanter gebleken. Volgens deze recente toezeggingen kan het zijn dat applicaties geen toegang hebben tot API's die niet gedocumenteerd zijn in de Android SDK (zoals API's gemarkeerd door het javadoc-attribuut @hide).
Waarom dit ertoe doet
De Android Software Development Kit (SDK) biedt ontwikkelaars API-bibliotheken en tools die ze nodig hebben om nieuwe Android-applicaties te testen en te bouwen. Bij elke nieuwe release van Android komt een hele reeks nieuwe API's die beschikbaar zijn voor ontwikkelaars via de Android SDK. Welke API's beschikbaar zijn voor een app, hangt af van de compileSDKVersie die de ontwikkelaar instelt. Daarom die van Google nieuwe Play Store-vereisten zijn zo belangrijk: het zal applicaties dwingen om te updaten en te migreren naar het gebruik van nieuwere API's.
Google-hosts documentatiepagina's voor elke klasse en alle methoden die beschikbaar zijn op elk API-niveau. Dit is de set gedocumenteerde API's die beschikbaar zijn in de officiële Android SDK. U kunt eenvoudig door de lijst met klassen bladeren met behulp van een Android-app, zoals de onlangs uitgebrachte Android SDK Search-app van Android Engineer Jake Wharton.
Prijs: gratis.
4.1.
Niet alle API's die beschikbaar zijn in elke Android-release zijn echter gedocumenteerd door Google of beschikbaar in de officiële Android SDK. Er zijn vaak nuttige API's die dat wel zijn ongedocumenteerd, maar zijn toch zeer nuttig. Het wordt afgeraden dat ontwikkelaars hun apps bouwen met behulp van ongedocumenteerde of verborgen API's, maar velen doen dit omdat er eenvoudigweg geen alternatief is als ze een bepaalde functie willen aanbieden. Ontwikkelaars die verborgen of ongedocumenteerde API's gebruiken, kunnen zichzelf ook een concurrentievoordeel opleveren, omdat ze functies kunnen bieden die hun concurrenten, die vasthouden aan de API's van Android, kunnen bieden SDK: kan niet.
Hoewel ik geen lijst kan geven met apps die ongedocumenteerde API's gebruiken (de ontwikkelaars delen deze waarschijnlijk niet). welke ze gebruiken omdat het hun concurrenten een voorsprong zou geven), is de lijst waarschijnlijk nogal groot. Ik zou dus concluderen dat het verbieden van toegang tot verborgen API's aanzienlijk zou zijn. Mark Murphy, oprichter van Commonsware, is het ermee eens:
Ik ben het eens met de inschatting dat het in bulk verbieden van de toegang tot @hide-geannoteerde items een groot probleem zal zijn, als dat gebeurt. Hopelijk hebben maar weinig apps toegang tot deze items als onderdeel van de belangrijkste functionaliteit. Ik vermoed echter dat veel apps van bekende merken ze af en toe gebruiken, rechtstreeks of via een bibliotheek.
Wat gebeurt er in Android P?
Deze aanstaande veranderingen werden voor het eerst opgemerkt door XDA Senior Recognized Developer rovo89, de ontwikkelaar van de Xposed-framework. Hij wees mij op twee verplichtingen, waarvan er één welke is geweest samengevoegd, die een nieuwe build-tool introduceert genaamd 'hiddenapi.' Deze tool wijzigt de toegangsvlaggen van alle klasleden binnen een DEX-bestand als hun handtekeningen verschijnen op een grijze of zwarte lijst voor invoer, en als dat het geval is, worden de gemarkeerde methoden behandeld als interne API's met beperkte toegang. toegang. De andere commit beschrijft hoe de API-blacklist werkt; het verhindert de toegang tot opstartklasse methoden en velden gemarkeerd door de bovengenoemde 'hiddenapi' waartoe ontwikkelaars toegang kunnen krijgen via statische koppeling, reflectie en JNI.
Volgens rovo89 is het eindresultaat van deze twee veranderingen in Android P het volgende:
Als deze commits worden samengevoegd, zou dit betekenen dat apps niet langer verborgen API's kunnen gebruiken/toegang hebben klassen, methoden en velden die zijn geannoteerd met @hide in AOSP en daarom geen deel uitmaken van de officiële SDK. Dit zou geen probleem zijn voor Xposed-modules, omdat ik die commits gemakkelijk zou kunnen terugdraaien of modules dat ook zou kunnen toestaan toegang tot deze API's. Maar er zijn veel apps die profiteren van verborgen API's, en die zouden falen in de toekomst.
Uit verdere toezeggingen blijkt inderdaad dat Google dit misschien wel van plan is. Dit verbinden vermeldt het volgende:
Hoewel deze specifieke commit niet werd samengevoegd omdat deze werd opgegeven ten gunste van drie kleinere commits, beschrijft het commit-bericht het doel van deze wijzigingen. Nog een setje pleegt laten zien dat Google alternatieven zal voorstellen aan ontwikkelaars die niet-openbare API's willen gebruiken:
Voor bepaalde verborgen API’s bestaan echter vaak geen alternatieven. Wij bij XDA kunnen hier uit ervaring spreken helaas kan deze verandering het einde betekenen van een aantal innovatieve apps, of kan het nodig zijn dat sommige apps van grote namen hun aantal terugdringen functionaliteit. Deze komende verandering lijkt qua geest vergelijkbaar met de recente hardhandig optreden tegen toegankelijkheidsdiensten (dat was gelukkig gepauzeerd zoals Google innovatieve toepassingen evalueerde). Hoewel de meeste apps die ongedocumenteerde API's gebruiken dit om goedaardige redenen doen, kunnen er enkele apps zijn die deze voor snode doeleinden hebben misbruikt.
Daarom vergrendelt Google mogelijk de toegang tot alle verborgen API's in Android P om gebruikers te beschermen tegen de weinigen die er misbruik van maken. Het is moeilijk te zeggen hoeveel impact dit op gebruikers kan hebben, maar als je een ontwikkelaar bent Als u overweegt via AOSP te zoeken naar een innovatief gebruik van een verborgen API, dan wilt u dat misschien wel doen heroverwegen.
Update: Google bevestigt
In een blogpost vandaag gepubliceerd, 28 februari, heeft Google deze wijzigingen bevestigd. Google noemt crashrisico's voor gebruikers en dwingt ontwikkelaars vervolgens om noodoplossingen uit te rollen stelt dat het bedrijf geleidelijk is overgegaan op het ontmoedigen van ontwikkelaars om toegang te krijgen tot niet-SDK interfaces. Vanaf Android P worden de beperkingen uitgebreid tot de Java-taalinterfaces van de SDK.
Het bedrijf stelt dat "sommige niet-SDK-methoden en -velden beperkt zullen zijn", hoewel ze niet hebben uitgewerkt welke beperkt zouden zijn. In eerste instantie zal de beperking zich richten op interfaces die zelden worden gebruikt, en een tijdje zal het bedrijf dit toestaan ontwikkelaars om niet-SDK-methoden en velden te blijven gebruiken waar de overstap naar een SDK-methode technisch gezien is uitdagend. Uiteindelijk zullen de beperkingen echter groter worden, dus ontwikkelaars van apps die niet-SDK-methoden gebruiken, moeten zo snel mogelijk overstappen ter voorbereiding op Android P. Wat betreft methoden zonder een SDK-alternatief vraagt Google ontwikkelaars om op hun bug-tracker met meer informatie.
De volgende preview voor ontwikkelaars, die ogenschijnlijk binnenkort verschijnt, zal ontwikkelaars in staat stellen bestaande apps te testen aan de hand van de zwarte of grijze lijst vóór de definitieve release.