Enligt en uppsättning åtaganden i AOSP kan Google börja begränsa åtkomsten till odokumenterade eller dolda API: er i Android P. Många namnmärkesappar använder dolda API: er för att utöka funktionaliteten, så effekten kan vara utbredd.
Uppdatering 28/2/18: Google har publicerat ett blogginlägg idag som bekräftar ändringarna. Mer information i slutet av artikeln.
Medan vissa Android-entusiaster är det spekulerar vilken efterrätt nästa version av Android kommer att döpas efter, det pågår en del intressanta utvecklingar bakom kulisserna. Vi har sett en få anmärkningsvärda kommande funktioner i Android P, men en nyare upptäckt i Android Open Source Project (AOSP) har visat sig mycket mer intressant. Enligt dessa senaste commits kan applikationer begränsas från att komma åt API: er som är odokumenterade i Android SDK (t.ex. API: er markerade med javadocs attribut @hide).
Varför detta spelar roll
Android Software Development Kit (SDK) ger utvecklare API-bibliotek och verktyg som de behöver för att testa och bygga nya Android-applikationer. Med varje ny version av Android kommer en mängd nya API: er som är tillgängliga för utvecklare via Android SDK. Vilka API: er som är tillgängliga för en app beror på vilken kompilSDKVersion utvecklaren ställer in. Det är därför Googles
nya krav på Play Butik är så viktiga – det kommer att tvinga applikationer att uppdatera och migrera till att använda nyare API: er.Google-värdar dokumentationssidor för varje klass och alla dess metoder som är tillgängliga på varje API-nivå. Dessa är uppsättningen av dokumenterade API: er som är tillgängliga i den officiella Android SDK. Du kan enkelt bläddra i listan över klasser med hjälp av en Android-app som den nyligen släppta Android SDK Search-appen från Android Engineer Jake Wharton.
Pris: Gratis.
4.1.
Alla API: er som är tillgängliga i varje Android-version är dock inte dokumenterade av Google eller tillgängliga i den officiella Android-SDK: n. Det finns ofta användbara API: er som är det odokumenterad, men är ändå väldigt användbara. Det rekommenderas inte att utvecklare bygger sina appar med hjälp av odokumenterade eller dolda API: er, men många gör det eftersom det helt enkelt inte finns något alternativ om de vill erbjuda en viss funktion. Utvecklare som använder dolda eller odokumenterade API: er kan också ha en konkurrensfördel, eftersom de kan erbjuda funktioner som deras konkurrenter – som håller sig till API: erna som erbjuds av Android SDK—kan inte.
Även om jag inte kan tillhandahålla en lista över appar som använder odokumenterade API: er (utvecklare delar förmodligen inte vilka de använder eftersom det skulle ge deras konkurrenter ett ben upp), listan är förmodligen snarare stor. Därför skulle jag dra slutsatsen att förbud mot åtkomst till dolda API: er skulle vara betydande. Mark Murphy, grundare av Commonsware, håller med:
Jag håller med om bedömningen att massförbud mot tillgång till @hide-kommenterade objekt kommer att vara en stor sak, om det blir av. Förhoppningsvis är det få appar som får tillgång till dessa objekt som en del av nyckelfunktioner. Jag misstänker dock att många namnmärkesappar använder dem ibland, direkt eller via ett bibliotek.
Vad händer i Android P?
Dessa kommande ändringar noterades först av XDA Senior Recognized Developer rovo89, utvecklaren av Xposed Framework. Han påpekade två åtaganden för mig, en av som har varit slås samman, som introducerar ett nytt byggverktyg som heter 'hiddenapi.' Detta verktyg ändrar åtkomstflaggor för alla klassmedlemmar i en DEX-fil if deras signaturer visas på en inmatningsgrålista eller svartlista, och i så fall kommer de markerade metoderna att behandlas som interna API: er med begränsade tillgång. Den andra commit beskriver hur API-svartlistan fungerar; det hindrar åtkomst till boot klass metoder och fält markerade av ovannämnda "hiddenapi" som utvecklare kan komma åt genom statisk länkning, reflektion och JNI.
Enligt rovo89 är slutresultatet av dessa två ändringar i Android P följande:
Om dessa åtaganden slås samman skulle det innebära att appar inte längre kan använda/åtkomst till dolda API: er, dvs. klasser, metoder och fält som är kommenterade med @hide i AOSP och därför inte ingår i officiella SDK. Detta skulle inte vara ett problem för Xposed-moduler eftersom jag enkelt skulle kunna återställa dessa commits eller tillåta moduler att också komma åt dessa API: er. Men det finns många appar som drar fördel av dolda API: er, och de skulle misslyckas i framtida.
Faktum är att ytterligare åtaganden visar att detta kan vara vad Google planerar. Detta begå anger följande:
Även om denna särskilda commit inte slogs samman eftersom den övergavs till förmån för 3 mindre commits, beskriver commit-meddelandet syftet med dessa ändringar. En annan uppsättning begår visa att Google kommer att föreslå alternativ till utvecklare som vill använda icke-offentliga API: er:
Det finns dock ofta inga alternativ till vissa dolda API: er. Vi på XDA kan tala av erfarenhet här som tyvärr kan den här förändringen innebära slutet på vissa innovativa appar, eller så kan det krävas några stora appar för att minska deras funktionalitet. Den här kommande förändringen verkar likna den senaste tidens anda tillslag mot tillgänglighetstjänster (det var tack och lov pausad som Google utvärderade innovativa användningsområden). Medan de flesta appar som använder odokumenterade API: er gör det av godartade skäl, kan det finnas vissa appar som har missbrukat dem för skändliga syften.
På grund av detta kan Google låsa åtkomst till alla dolda API: er i Android P för att skydda användare från de få som missbrukar dem. Det är svårt att säga hur stor inverkan detta kan ha på användare, men om du är en utvecklare överväger att titta igenom AOSP för att hitta en innovativ användning av ett dold API, då kanske du vill ompröva.
Uppdatering: Google bekräftar
I en blogginlägg publicerad idag, 28 februari, har Google bekräftat dessa ändringar. Citerar kraschrisker för användare och tvingar utvecklare att rulla ut nödfixar, Google uppger att företaget gradvis har gått över till att avskräcka utvecklare från att komma åt icke-SDK gränssnitt. Från och med Android P kommer begränsningarna att utökas till att täcka Java-språkgränssnitten i SDK: n.
Företaget uppger att "vissa icke-SDK-metoder och fält kommer att begränsas", även om de inte utvecklade vilka som skulle begränsas. Inledningsvis kommer begränsningen att fokusera på gränssnitt som sällan används, och ett tag kommer företaget att tillåta utvecklare att fortsätta använda icke-SDK-metoder och områden där övergången till en SDK-metod är tekniskt sett utmanande. Men så småningom kommer begränsningarna att vidgas, så utvecklare av appar som använder icke-SDK-metoder bör övergå så snart som möjligt som förberedelse för Android P. När det gäller metoder utan ett SDK-alternativ, ber Google utvecklare att göra inlägg på deras felsökare med mer information.
Nästa förhandsvisning för utvecklare, som till synes kommer snart, kommer att göra det möjligt för utvecklare att testa befintliga appar mot svartlistan eller grålistan innan den slutliga releasen.