Android 12s Fabricated Overlay API bringer tilbake rotløse temaer

Den fulle stallen Android 12 utgivelsen er rett rundt hjørnet, og Google har til og med la ut kildekoden til sin AOSP-repo. Det er en mye som er nytt i Android 12, inkludert et tillegg til ressursoverlegg kalt Fabricated Overlays. Det som var ment som et API for å hjelpe systemet med å administrere de dynamiske endringene som brukes i Materiale deg og monet kan bli til noe mye større – i hvert fall inntil Android 13 slippes.

Bakgrunn

Mishaal Rahman oppdaget dette nye API-et og gjorde meg oppmerksom på det. Han hadde brukt shell-kommandoen for å teste ut forskjellige ressursverdier i Android 12 uten å ha det å manuelt kompilere overleggs-APK-er, og han trodde det kunne gi en interessant appidé for rotfestede enheter. Da han gjorde meg oppmerksom på det, tok jeg mye på kildekoden for Android 12 og la merke til noe jeg syntes var ganske interessant. Jeg testet det jeg fant, og nå er vi her -- som det viser seg, kan Fabricated Overlay API brukes til å bringe tilbake rotløse temaer. Før jeg går for langt inn i hva som skjer her, skal jeg forklare hva Fabricated Overlays faktisk er.

Hva er fabrikkerte overlegg?

Fabricated Overlays er en ny funksjon introdusert i Android 12. De ligner de klassiske Runtime Resource Overlays (RROs) som Android har hatt i noen år nå. Både RROer og Fabricated Overlays kan overstyre ulike ressurser for ulike applikasjoner. Du kan endre en boolsk fra usann til sann (eller omvendt), angi hvor stor du vil at statuslinjen skal være, og så videre.

Fabriserte overlegg har imidlertid noen bemerkelsesverdige forskjeller fra RRO-er. For det første trenger du ikke å generere en overleggs-APK og deretter installere den. I stedet forteller du bare Android hvilke verdier du vil endre for hvilken applikasjon, og den tar seg av å registrere endringene dine som et overlegg du deretter kan aktivere.

De er også litt mer begrensede enn RRO-er. Før Android 11 kunne RRO-er overstyre stort sett enhver ressurs: booleaner, heltall, dimensjoner, attributter, layouter og til og med rådatafiler. Android 11 gjorde noen endringer i hvordan RRO-er fungerer, noe som gjorde at overordnede oppsett ikke lenger var mulige, selv om det gjorde RRO-er mer stabile totalt sett.

Fabricated Overlays, derimot, kan bare overstyre verdier som kan representeres som heltall. Det inkluderer heltall (duh), dimensjoner, booleaner og farger. Du kan ikke bruke dem til å overstyre rådataressurser, oppsett, strenger eller matriser - i hvert fall ikke lett. Dette er noe vilkårlig begrensning i APIen: den aksepterer bare heltallsverdier og ressurskategorier som definert av TypedValue-klassen. TypedValue gjør det Brukerstøtte strenger og de andre ressurstypene, men bare for å referere til ressursen deres, ikke holde deres faktiske data.

Disse begrensningene er imidlertid ikke for store for det tiltenkte formålet med Fabricated Overlays: Material You og monetære effekter. Fabriserte overlegg gjør det enkelt for systemet å generere og bruke farge- og dimensjonsoverlegg i farten, uten å måtte starte på nytt eller vente på at en APK skal kompileres.

Nå, normalt, ville dette bare være nok et pent API for folk med rotfestede enheter å dra nytte av. Med mindre det er et smutthull laget av produsenten (som det Synergy drar nytte av på Samsung-enheter), kan overlegg bare installeres av tredjeparter med root-tilgang. Det er imidlertid den beste delen - Google glemte å lappe et hull i Android 12.

Fabriserte overlegg uten rot

Android 8 introduserte den nye Overlay Manager Service (eller OMS) API, og folk oppdaget ganske raskt at overleggs-APK-er kunne installeres som vanlige apper og deretter aktiveres ved hjelp av ADB. Dessverre lappet Google dette i Android 9, og siden den gang kan bare overlegg signert med samme nøkkel som systemet installeres dynamisk.

Som det viser seg, har Android 12s Fabricated Overlays et smutthull som minner om det som finnes i Android 8: de trenger ikke root-tilgang eller tillatelser på signaturnivå. De trenger bare noe som kjører som shell-bruker (dvs. ADB) for å registrere dem.

Det er ganske tydelig at Google hadde til hensikt at Fabricated Overlays bare skulle være tilgjengelig for rot- og systembrukere. Det er en ADB-kommandoimplementering for å lage dem, og den vil ikke kjøre hvis den utførende brukeren ikke er root. Smutthullet er at sjekken bare er i kommandoen, ikke selve API-en, noe som betyr at vi kan dra nytte av det med litt arbeid.

ADB på enheten

I lang tid har Android hatt en trådløs ADB-funksjon. Dette lar en datamaskin (eller noe med binær ADB og nettverkstilgang) koble til en enhet trådløst. Den er hovedsakelig beregnet på Android-enheter som ikke har brukertilgjengelige USB-tilkoblinger, for eksempel smartklokker og TV-er. Videre, før Android 11, trengte du en kablet ADB-tilkobling for å aktivere Trådløs modus.

Android 11 er det som offisielt brakte trådløs ADB til telefoner og nettbrett. Det er litt mer komplisert enn den klassiske trådløse ADB, med sammenkobling og autentiseringskoder, men den kan aktiveres av brukeren helt på enheten, så lenge enheten er koblet til WiFi. Det betyr at det er mulig å koble til enheten din via ADB fra enheten din, og alt du trenger er en WiFi forbindelse.

Bruke forhøyede APIer i en app

Det er mange grunner til at du kanskje vil bruke begrensede APIer i appen din. Vanligvis er det fordi de gir noen spesiell funksjonalitet du trenger. Så lenge API-en du trenger har en shell-kommandoimplementering, er det ganske enkelt å bruke den fra en app. Alt du trenger å gjøre er å lage en shell-prosess som root (eller ADB), kjøre den riktige kommandoen og analysere resultatet, hvis noen.

Hva om API-en ikke har en shell-implementering, eller shell-implementeringen mangler noe du trenger? Hvis du er på en rotet enhet, kan du bruke noe sånt som libRootJava. libRootJava lar deg samhandle med Android-ramme-API-ene som om appen din kjører som root-bruker. Dette er både mer praktisk og mye raskere enn å kjøre skallkommandoer, siden alt er på samme språk, og du trenger ikke å bekymre deg for å analysere strenger manuelt. Den har noen begrensninger, men for det meste fungerer den utmerket.

libRootJava API er ganske fleksibelt. Du kan tilpasse den til å kjøre som shell-bruker i stedet for root. Heldigvis trenger du ikke det, for noen har allerede laget det, og det heter Shizuku. Shizuku er nesten som en kombinasjon av Magisk Manager og libRootJava.

Shizuku Manager-appen veileder deg gjennom å sette opp en prosess som kjører som skallbrukeren som Shizuku har tilgang til. Shizuku API-biblioteket kan implementeres i apper for å la dem få tilgang til system-APIer som om de var shell-brukeren. Det er en mye mer sentralisert prosess enn libRootJava, siden Shizuku bare må settes opp én gang før hver app som implementerer Shizuku API-biblioteket kan bruke den. Hvis du er interessert i hvordan Shizuku fungerer og hvordan du kan integrere den i appen din, Jeg har en guide for det her.

Shizuku og Fabricated Overlays

Nå kan du sikkert se hvor dette går. Vi kan bruke en tjeneste som Shizuku for å få tilgang til Fabricated Overlays API som skallbruker, og vi kan bruke Android 11s trådløse ADB-funksjon for å få tilgang på skallnivå, alt på enheten. Siden root-brukerbegrensningen bare er tilstede i Fabricated Overlays-shell-kommandoen og ikke den faktiske API-en, er det nok å kjøre som shell-brukeren til å bruke den direkte.

Implementering: Bibliotek og prøveapp

Hva med implementeringsdetaljene? Vel, jeg har deg dekket for det også.

Som forberedelse til dette laget jeg både en bibliotek og en fullt funksjonell prøveapp bruke det biblioteket.

Selve biblioteket er mest for enkelhets skyld. Den pakker inn noen av de skjulte system-API-ene og gir deg noen praktiske metoder for å håndtere Shizuku-tillatelser. Den er også fleksibel, slik at du kan gi din egen forekomst av IOverlayManager API hvis du har en annen måte å hente den på.

Eksempelappen viser hvordan du kan gå frem for å implementere biblioteket ved hjelp av Shizuku. Det er også en fullt funksjonell og nyttig app. Hovedsiden viser for øyeblikket registrerte fabrikkerte overlegg som ble opprettet gjennom den, gruppert etter målapp. Du kan også aktivere, deaktivere og slette dem derfra.

Hvis du trykker på "Legg til overlegg"-knappen nederst, kommer du til en liste over alle apper som kan legges over. Søk eller rull for å finne den du trenger, og trykk på den. Deretter kan du trykke på "Legg til"-knappen nederst på skjermen for å se listen over ressurser som kan overstyres i den appen. Velg en ressurs, angi dens verdi og gjenta for så mange verdier du vil endre. Trykk på "Lagre", skriv inn et navn, bekreft, og du vil bli brakt tilbake til hovedskjermen, som nå viser det nye overlegget, klart til å aktiveres.

Her er noen skjermbilder fra appen, takket være Mishaal Rahman.

Som en sidenotat har jeg også en generell overleggsbehandlingsapp kalt... Overleggsbehandling. Selve den forhåndskompilerte appen er kun tilgjengelig på min Patreon, men kildekoden er fritt tilgjengelig til alle som ønsker å kompilere eller endre det.

Konklusjon

Den nye Fabricated Overlays API i Android 12 er ganske bra, mest fordi den ikke trenger root. Det er kanskje ikke så sofistikert som en full-on RRO APK, men det gir deg mye mer fleksibilitet uten root-tilgang.

Sjekk ut Fabricate Overlay-appen på GitHub

Hvis du har en enhet som kjører Android 12 og du vil prøve dette, sjekk ut GitHub-depotet lenket ovenfor. Utgivelsesdelen vil ha en APK å laste ned og bruke. Biblioteket skal være enkelt å inkludere i din egen applikasjon ved hjelp av JitPack.

Selvfølgelig bør du ikke forvente at denne funksjonen vil holde seg lenge. Google liker virkelig ikke tredjeparts overlegg, så dette vil nesten definitivt bli fikset når Android 13 slippes. I mellomtiden kan du imidlertid nyte det så lenge det varer!