Android 12:n Fabricated Overlay API tuo takaisin juurettomat teemat

Täysi talli Android 12 julkaisu on aivan nurkan takana, ja Google on jopa tehnyt julkaisi lähdekoodin sen AOSP repoon. Siellä paljon uutta Android 12:ssa, mukaan lukien lisäys resurssipeittokuviin nimeltä Fabricated Overlays. Mikä oli tarkoitettu API: ksi auttamaan järjestelmää hallitsemaan dynaamisia muutoksia, joita käytetään Materiaali sinä ja monet voivat muuttua joksikin paljon suuremmaksi – ainakin Android 13:n julkaisuun asti.

Tausta

Mishaal Rahman löysi tämän uuden API: n ja toi sen huomioni. Hän oli käyttänyt siihen shell-komentoa testatakseen erilaisia ​​resurssiarvoja Android 12:ssa ilman, että olisi kääntää peittokuva-APK: t manuaalisesti, ja hän ajatteli, että se voisi olla mielenkiintoinen sovellusidea juurtuneille laitteille. Kun hän kiinnitti sen huomioni, tutkin paljon Android 12:n lähdekoodia ja huomasin jotain, mikä oli mielestäni melko mielenkiintoista. Testasin löytämiäni, ja nyt olemme täällä - kuten käy ilmi, Fabricated Overlay API: ta voidaan käyttää tuomaan takaisin juurettomat teemat. Ennen kuin menen liian pitkälle tässä tapahtuvassa, selitän, mitä valmistetut peittokuvat todellisuudessa ovat.

Mitä valmistetut peittokuvat ovat?

Valmistetut peittokuvat ovat Android 12:n uusi ominaisuus. Ne ovat samanlaisia ​​kuin perinteiset Runtime Resource Overlays (RRO) -peittokuvat, joita Androidilla on ollut muutaman vuoden ajan. Sekä RRO: t että valmistetut peittokuvat voivat ohittaa eri resurssit eri sovelluksissa. Voit muuttaa loogisen arvon epätosi arvoksi tosi (tai päinvastoin), määrittää, kuinka suuren haluat tilapalkin olevan ja niin edelleen.

Valmistetuilla peittokuvilla on kuitenkin joitain merkittäviä eroja RRO: ihin verrattuna. Ensinnäkin sinun ei tarvitse luoda peitto-APK: ta ja asentaa sitä. Sen sijaan kerrot Androidille, mitä arvoja haluat muuttaa millekin sovellukselle, ja se huolehtii muutosten rekisteröimisestä peittokuvana, jonka voit sitten ottaa käyttöön.

Ne ovat myös hieman rajoitetumpia kuin RRO: t. Ennen Android 11:tä RRO: t saattoivat ohittaa melkein minkä tahansa resurssin: loogiset arvot, kokonaisluvut, mitat, attribuutit, asettelut ja jopa raakadatatiedostot. Android 11 teki joitain muutoksia RRO: iden toimintaan, mikä teki ohittamisesta asettelut eivät enää käytännössä mahdollisia, vaikka se teki RRO: ista yleisesti ottaen vakaampia.

Valmistetut peittokuvat puolestaan ​​voivat ohittaa vain arvot, jotka voidaan esittää kokonaislukuina. Se sisältää kokonaisluvut (duh), mitat, loogiset arvot ja värit. Et voi käyttää niitä raakatietoresurssien, asettelujen, merkkijonojen tai taulukoiden ohittamiseen – ainakaan ei helposti. Tämä on jokseenkin mielivaltainen rajoitus API: ssa: se hyväksyy vain TypedValue-luokan määrittämät kokonaisluvut ja resurssikategoriat. TypedValue tekee tuki merkkijonoja ja muita resurssityyppejä, mutta vain viittaamaan niiden resursseihin, ei niiden todellisten tietojen säilyttämiseen.

Nämä rajoitukset eivät kuitenkaan ole liian suuri asia Fabricated Overlays: Material Sinä ja rahalliset vaikutukset -sovelluksen aiottuun tarkoitukseen. Valmistettujen peittokuvien avulla järjestelmän on helppo luoda ja käyttää väri- ja mittapeittokuvia lennossa ilman, että sinun tarvitsee käynnistää uudelleen tai odottaa APK: n kääntämistä.

Nyt normaalisti tämä olisi vain toinen siisti API, jota juurtuneita laitteita käyttävät ihmiset voivat hyödyntää. Ellei valmistajan luomaa porsaanreikää ole (kuten Synergy hyödyntää Samsungin laitteissa), vain kolmannet osapuolet voivat asentaa peittokuvia, joilla on pääkäyttäjän oikeudet. Se on kuitenkin paras osa – Google unohti korjata reiän Android 12:ssa.

Valmistetut peittokuvat ilman juuria

Android 8 esitteli uuden Overlay Manager Service (tai OMS) API: n, ja ihmiset huomasivat melko nopeasti, että overlay APK: t voitiin asentaa tavallisina sovelluksina ja ottaa sitten käyttöön ADB: n avulla. Valitettavasti Google korjasi tämän Android 9:ssä, ja siitä lähtien vain järjestelmän kanssa samalla avaimella allekirjoitetut peittokuvat voidaan asentaa dynaamisesti.

Kuten käy ilmi, Android 12:n valmistetuissa peittokuvissa on porsaanreikä, joka muistuttaa Android 8:ssa olevaa: ne eivät tarvitse pääkäyttäjän oikeuksia tai allekirjoitustason käyttöoikeuksia. He tarvitsevat vain jotain, joka toimii shell-käyttäjänä (eli ADB) rekisteröidäkseen heidät.

On melko selvää, että Googlen tarkoituksena oli, että valmistettuja peittokuvia ovat vain pääkäyttäjät ja järjestelmäkäyttäjät. Niiden luomiseen on ADB-komentototeutus, ja se ei toimi, jos suorittava käyttäjä ei ole pääkäyttäjä. Porsaanreikä on, että tarkistus on vain komennossa, ei varsinaisessa API: ssa, mikä tarkoittaa, että voimme hyödyntää sitä pienellä työllä.

ADB On-Device

Androidissa on ollut jo pitkään langaton ADB-ominaisuus. Näin tietokone (tai mikä tahansa ADB-binääri- ja verkkoyhteys) voi muodostaa yhteyden laitteeseen langattomasti. Se on enimmäkseen tarkoitettu Android-laitteille, joissa ei ole käyttäjän käytettävissä olevia USB-liitäntöjä, kuten älykellot ja televisiot. Lisäksi ennen Android 11:tä tarvitsit langallisen ADB-yhteyden aktivoidaksesi Langaton tila.

Android 11 toi virallisesti langattoman ADB: n puhelimiin ja tabletteihin. Se on hieman monimutkaisempi kuin klassinen langaton ADB, jossa on pariliitos- ja todennuskoodit, mutta käyttäjä voi aktivoida sen kokonaan laitteella, niin kauan kuin laite on yhteydessä WiFi-verkkoon. Tämä tarkoittaa, että laitteellesi on mahdollista muodostaa yhteys ADB: n kautta laitteestasi, ja tarvitset vain WiFin yhteys.

Korkeiden sovellusliittymien käyttäminen sovelluksessa

On monia syitä, miksi saatat haluta käyttää rajoitettuja sovellusliittymiä sovelluksessasi. Yleensä se johtuu siitä, että ne tarjoavat joitain erityisiä toimintoja, joita tarvitset. Niin kauan kuin tarvitsemasi sovellusliittymässä on shell-komentojen toteutus, sen käyttäminen sovelluksesta on melko helppoa. Sinun tarvitsee vain luoda komentotulkkiprosessi pääkäyttäjänä (tai ADB), suorittaa oikea komento ja jäsentää tulos, jos sellainen on.

Entä jos API: lla ei ole shell-toteutusta tai shell-toteutuksesta puuttuu jotain tarvitsemaasi? Jos käytät rootattua laitetta, voit käyttää jotain vastaavaa libRootJava. libRootJavan avulla voit olla vuorovaikutuksessa Android-kehyssovellusliittymien kanssa ikään kuin sovelluksesi toimisi juurikäyttäjänä. Tämä on sekä kätevämpää että paljon nopeampaa kuin komentotulkkikomentojen suorittaminen, koska se on kaikki samalla kielellä, eikä sinun tarvitse huolehtia merkkijonojen jäsentämisestä manuaalisesti. Sillä on joitain rajoituksia, mutta suurimmaksi osaksi se toimii hyvin.

LibRootJava API on melko joustava. Voit mukauttaa sen toimimaan shell-käyttäjänä rootin sijaan. Onneksi sinun ei tarvitse, koska joku on jo tehnyt sen ja sitä kutsutaan Shizuku. Shizuku on melkein kuin Magisk Managerin ja libRootJavan yhdistelmä.

Shizuku Manager -sovellus opastaa sinua määrittämään prosessin, joka toimii shell-käyttäjänä, jota Shizuku voi käyttää. Shizuku API -kirjasto voidaan toteuttaa sovelluksiin, jotta ne voivat käyttää järjestelmän sovellusliittymiä ikään kuin he olisivat shell-käyttäjä. Se on paljon keskitetympi prosessi kuin libRootJava, koska Shizuku on määritettävä vain kerran, ennen kuin jokainen Shizuku API -kirjastoa toteuttava sovellus voi käyttää sitä. Jos olet kiinnostunut siitä, miten Shizuku toimii ja kuinka voit integroida sen sovellukseesi, Minulla on siihen ohje täällä.

Shizuku ja valmistetut peitot

Nyt varmaan näkee mihin tämä on menossa. Voimme käyttää Shizukun kaltaista palvelua päästäksemme Fabricated Overlays API: hen shell-käyttäjänä, ja voimme käyttää Android 11:n langatonta ADB-ominaisuutta saadaksemme kuoritason pääsyn laitteeseen. Koska pääkäyttäjän rajoitus on vain Fabricated Overlays -komentotulkkikomennossa, ei varsinaisessa API: ssa, komentotulkin käyttäjänä suorittaminen riittää käyttämään sitä suoraan.

Toteutus: Kirjasto ja mallisovellus

Entä toteutustiedot? No, minäkin suojaan sinua siitä.

Valmistautuessani tähän tein molemmat a kirjasto ja täysin toimiva esimerkkisovellus käyttämällä sitä kirjastoa.

Itse kirjasto on lähinnä mukavuussyistä. Se kääri osan piilotetuista järjestelmän sovellusliittymistä ja antaa sinulle muutamia käteviä tapoja käsitellä Shizuku-käyttöoikeuksia. Se on myös joustava, joten voit tarjota oman ilmentymän IOverlayManager API: sta, jos sinulla on toinen tapa noutaa se.

Esimerkkisovellus näyttää, kuinka voit toteuttaa kirjaston Shizukun avulla. Se on myös täysin toimiva ja hyödyllinen sovellus. Pääsivulla näkyvät tällä hetkellä rekisteröidyt valmistetut peittokuvat, jotka on luotu sen kautta, ryhmiteltynä kohdesovelluksen mukaan. Voit ottaa ne käyttöön, poistaa käytöstä ja poistaa ne myös sieltä.

Napauttamalla "Lisää peittokuva" -painiketta alareunassa pääset luetteloon kaikista päällekkäisistä sovelluksista. Etsi tai vieritä etsimään tarvitsemasi ja napauta sitä. Sitten voit painaa "Lisää" -painiketta näytön alareunassa nähdäksesi luettelon resursseista, jotka voidaan ohittaa kyseisessä sovelluksessa. Valitse resurssi, aseta sen arvo ja toista niin monta arvoa kuin haluat muuttaa. Paina "Tallenna" -painiketta, kirjoita nimi, vahvista ja sinut tuodaan takaisin päänäyttöön, jossa näkyy nyt uusi peittokuva, joka on valmis otettaviksi käyttöön.

Tässä on joitain kuvakaappauksia sovelluksesta, kiitos Mishaal Rahmanin.

Sivuhuomautuksena minulla on myös yleinen peittokuvanhallintasovellus nimeltä... Overlay Manager. Itse esikäännetty sovellus on saatavilla vain Patreonissani, mutta lähdekoodi on vapaasti saatavilla kaikille, jotka haluavat koota tai muokata sitä.

Johtopäätös

Uusi Fabricated Overlays API Android 12:ssa on melko loistava, lähinnä siksi, että se ei tarvitse pääkäyttäjää. Se ei ehkä ole niin hienostunut kuin täysi RRO APK, mutta se antaa sinulle paljon enemmän joustavuutta ilman pääkäyttäjän oikeuksia.

Tutustu Fabricate Overlay -sovellukseen GitHubissa

Jos sinulla on Android 12 -käyttöjärjestelmää käyttävä laite ja haluat kokeilla tätä, tutustu yllä olevaan GitHub-tietovarastoon. Julkaisut-osiossa on ladattava ja käytettävä APK. Kirjaston tulee olla helppo sisällyttää omaan sovellukseesi JitPackin avulla.

Tietenkään sinun ei pitäisi odottaa tämän ominaisuuden pysyvän käytössä pitkään. Google ei todellakaan pidä kolmannen osapuolen peittokuvista, joten tämä korjataan melkein varmasti, kun Android 13 julkaistaan. Sillä välin kuitenkin nautitaan niin kauan kuin sitä kestää!