Senza il codice sorgente, come fanno gli sviluppatori a far funzionare componenti hardware come le fotocamere nelle ROM personalizzate? La risposta è un BLOB, uno spessore e molto debug.
Con il rilascio di Android Oreo e di molti dispositivi come Xiaomi Redmi Nota 3, Google Nexus 5 E altri lo ricevono ufficiosamente, è probabilmente giusto chiedersi perché le stesse funzionalità (principalmente la fotocamera) tendono a non funzionare quando gli sviluppatori eseguono il porting di una ROM basata su Android Open Source Project (AOSP). Probabilmente hai visto thread del forum XDA di ROM con un lungo elenco di funzionalità non funzionanti in alto. "Cosa funziona" seguito da un elenco di funzionalità funzionanti, quindi in basso l'iconico "Cosa non funziona?" Dimmelo tu!" sono due ritornelli popolari sui nostri forum che sono praticamente diventati un meme su posti come Reddit e Twitter.
Perché così tante funzionalità vengono interrotte ogni volta che uno sviluppatore tenta di trasferire una ROM AOSP sul proprio dispositivo? La risposta di base è che, poiché le funzioni cambiano nelle diverse versioni di Android, i vecchi driver di dispositivo confezionati come BLOB non funzioneranno con le versioni più recenti di Android, o anche solo con AOSP di serie. Per superare questo problema, gli sviluppatori utilizzano quello che viene chiamato “shim”, ma il processo coinvolto è complicato, richiede molto tempo e talvolta è molto difficile eseguire il debug.
In questo articolo, illustreremo come funzionano gli spessori, in particolare per quanto riguarda il corretto funzionamento della fotocamera su ROM basate su AOSP. Utilizzeremo OnePlus 3T come esempio. Tieni presente che la difficoltà nel far funzionare queste funzionalità è altamente specifica del dispositivo.
OnePlus 3T con OxygenOS. Sebbene i telefoni OnePlus siano noti per la loro facilità di sviluppo personalizzato, c'è molto lavoro che gli sviluppatori svolgono dietro le quinte per realizzare port stabili di AOSP.
Cos'è uno spessore o un BLOB?
Per iniziare a capire anche solo una parte di ciò che stanno facendo gli sviluppatori, dobbiamo prima spiegare alcune cose. Sebbene il sistema operativo Android sia open source (si chiama Android Open Source Project per un motivo), il software (senza kernel) distribuito su migliaia di dispositivi Android non lo è. Gli sviluppatori non hanno accesso al codice sorgente di Esperienza Samsung, EMUI, OxygenOSo qualsiasi altra versione di Android di terze parti.
Ora, gli sviluppatori che eseguono il porting di AOSP di serie su un dispositivo non Google probabilmente non si preoccupano del codice sorgente di queste skin Android poiché non lo saranno modificando e costruendo queste ROM. Sarebbe vero, se non fosse per una grande, grande ragione: principalmente le parti necessarie per far funzionare correttamente la fotocamera IL fotocamera HAL (Hardware Abstraction Layer), sono anche closed source.
Il problema di avere non solo l'HAL della fotocamera ma anche la ROM closed source è che gli sviluppatori che lavorano al porting di AOSP sui propri dispositivi saranno lavorare alla cieca. La ROM OEM closed source è in grado di interfacciarsi perfettamente con l'HAL della fotocamera perché l'OEM ha accesso alla sorgente HAL della fotocamera. L'HAL della fotocamera è ciò che consente alla ROM di "parlare" con l'hardware della fotocamera: senza di esso, la fotocamera non funzionerebbe. Pensa alla telecamera HAL come al volante e ai pedali dell'auto. Il volante/pedali consentono il controllo dei componenti interni del veicolo fornendo un'interfaccia esterna per il conducente (la ROM) per utilizzare i componenti interni.
Man mano che l'hardware della fotocamera diventa sempre più complesso (il avvento della doppia fotocamera, ad esempio), avere accesso alla sorgente HAL della fotocamera renderebbe molto più semplice il porting di una ROM AOSP con una fotocamera funzionante.
Tuttavia, gli OEM non forniscono l'accesso all'origine HAL della fotocamera per vari motivi. In primo luogo, se non possiedono tutti i diritti di proprietà sull'HAL della fotocamera (come quando incorporano proprietà intellettuale di altre società), non possono distribuire la fonte. In secondo luogo, il rilascio della sorgente HAL della fotocamera potrebbe mettere a repentaglio la propria proprietà intellettuale. Infine, le aziende non hanno alcun obbligo legale di fornire questo codice sorgente (a differenza del codice sorgente del kernel che sono obbligato a rilasciare sotto GPL), pertanto non hanno alcun incentivo a rilasciarlo. Quindi, senza l'accesso alla sorgente HAL della fotocamera, come fanno esattamente gli sviluppatori a far funzionare la fotocamera sulle ROM AOSP? La risposta è un BLOB, uno shim e un sacco di debug.
Un dispositivo BLOB (Binary Large OBject) contiene binari preconfezionati che sono la forma compilata di software. In questo caso, l'origine HAL della fotocamera viene compilata dall'OEM e fornita sui dispositivi come file binari. Quando gli sviluppatori parlano di BLOB, si riferiscono a quei file binari forniti su dispositivi live che sono in grado di estrarre. Ora, l'argomento "BLOB della fotocamera" ha a lungo afflitto OnePlus per molti mesi, ma la verità è che gli sviluppatori hanno sempre avuto accesso ai BLOB delle fotocamere. IL Il codice sorgente HAL della telecamera è il biglietto d'oro per gli sviluppatori qui, però, ma sarà così mai e poi mai essere rilasciato a causa del pericolo legale in cui metterebbero aziende come OnePlus.
Pertanto, gli sviluppatori che desiderano portare AOSP su un dispositivo rimangono solo con i BLOB dell'HAL della fotocamera per i quali non hanno accesso al codice sorgente. Raramente, se non mai, uno sviluppatore può accoppiare il proprio codice ROM AOSP con l'HAL BLOB della fotocamera e aspettarsi che funzioni, quindi per colmare il divario tra i due, gli sviluppatori creano quello che viene chiamato un "spessore.”
"Shim" significa "incastrare (qualcosa) o riempire uno spazio". Questo è effettivamente ciò che fa uno sviluppatore quando scrivendo uno shim: aggiungono codice per consentire al BLOB di interfacciarsi con il codice sorgente AOSP su cui stanno lavorando con. Gli spessori vengono utilizzati per far funzionare BLOB di tutti i tipi diversi con AOSP, ma di solito è il BLOB della fotocamera che richiede più spessori. Come accennato in precedenza, lo shimming è necessario non solo per il porting delle versioni più recenti di Android su un dispositivo (come tutte quelle ROM Android Oreo non ufficiali) ma necessarie anche quando si esegue il porting di AOSP della stessa versione Android su quella dispositivo.
Lettura consigliata: Dal negozio allo scaffale: una spiegazione approfondita del motivo per cui i dispositivi MSM8974 sono esclusi da Nougat
Il OnePlus 2, ad esempio, ha ricevuto il suo ultimo importante aggiornamento ufficiale del sistema operativo sotto forma di Android 6.0 Marshmallow. Il dispositivo, tuttavia, in realtà lo ha ROM personalizzate basate su AOSP completamente funzionanti basato su Android Nougat, e questo grazie al duro lavoro degli sviluppatori e dei loro spessori. Analizzeremo alcuni esempi di spessori, ma prima dobbiamo parlare di come funzionano esattamente gli spessori.
Come funziona lo shimming?
Poiché gli sviluppatori non hanno accesso all'HAL della fotocamera o alla sorgente ROM OEM (e solo ai file binari precompilati), non possono sapere quali funzioni si aspetta l'HAL della fotocamera. Per questo motivo, spesso c'è una discrepanza tra il nome della funzione cercata dall'HAL della fotocamera e il nome effettivo della funzione nel codice AOSP con cui sta lavorando lo sviluppatore.
Per risolvere questo problema, lo sviluppatore crea semplicemente una nuova funzione che utilizza lo stesso nome di funzione prevista dall'HAL BLOB della fotocamera, ma questa nuova funzione esegue semplicemente ciò che desidera lo sviluppatore a. Questa nuova funzione che funge da intermediario tra BLOB e AOSP è lo shim. Questo particolare scenario in cui il BLOB non riesce a trovare la funzione che sta cercando è uno dei più comuni in cui è necessario uno spessore.
Forse le cose avranno più senso con un ipotetico esempio che coinvolge OnePlus 3T. Creeremo un esempio utilizzando OxygenOS e la fotocamera OnePlus. Se utilizziamo i BLOB della fotocamera presi da OxygenOS Nougat per OnePlus 3T per creare una ROM Nougat basata su AOSP, potremmo riscontrare problemi. Questo perché i BLOB della fotocamera (originariamente compilati dall'OEM) saranno in grado di fare riferimento a tutte le funzioni di cui ha bisogno all'interno di OxygenOS, ma poiché La ROM AOSP compilata potrebbe non avere quelle funzioni o potrebbe averle compilate con un nome diverso (portando così a una mancata corrispondenza tra i simboli di funzione), ci sarà un errore. Questo problema può essere risolto creando una nuova funzione all'interno della ROM AOSP con il nome previsto dal BLOB: il nostro shim.
I simboli in un contesto di programmazione vengono utilizzati per fare riferimento a funzioni specifiche nel codice. I simboli sono necessari perché la posizione di una funzione può cambiare quando il codice viene modificato, e quindi per evitare l'hardcoding riferimenti alle funzioni, il compilatore crea una tabella di simboli che altre funzioni possono utilizzare per fare sempre riferimento a destra funzione. Quando si modifica il nome di una funzione prima della compilazione, cambia anche il suo simbolo, quindi praticamente qualsiasi modifica che l'OEM apporta all'origine HAL della fotocamera prima della compilazione richiederà agli sviluppatori di crearne uno nuovo spessore.
La spiegazione che abbiamo offerto finora fa sembrare che la creazione degli spessori sia facile. Cambiare alcuni nomi di funzioni qua e là non sembra troppo difficile, giusto? Se solo fosse così facile. La realtà degli spessori implica qualcosa di più della semplice ridenominazione delle funzioni. Abbiamo parlato con lo sviluppatore riconosciuto XDA Sultanxda che è stato in grado di fornirci un esempio di uno degli spessori più difficili su cui ha lavorato.
Shimming: non è così facile come sembra
Per chi non ha familiarità con il OnePlus 3T, la fotocamera frontale inizialmente era piuttosto rotta ROM personalizzate basate su AOSP. Per cominciare, tentare di scattare una foto superiore a 8 MP comporterebbe schiantarsi. Nel tentativo di risolvere questo problema, Sultanxda ne ha realizzati diversi spessori per consentire alla fotocamera frontale di OnePlus 3T di funzionare correttamente.
Spessore n. 1: modifica del nome del pacchetto della fotocamera
Per evitare che la fotocamera frontale si bloccasse ogni volta che l'utente scattava una foto superiore a 8 MP, Sultanxda ha costretto l'HAL della fotocamera a identificare tutte le fotocamere come fotocamera OnePlus. Questo perché OnePlus ha deciso di dedicare una funzione di supporto ad alcune applicazioni (isOnePlusCamera, isFacebookCamera, ecc.) per qualche motivo. Sultanxda ha risolto questo problema spostando l'HAL della fotocamera in modo che punti a una nuova funzione che restituisce sempre "true" come se l'utente stesse utilizzando la fotocamera OnePlus, anche quando non lo sta facendo.
Spessore n. 2: disabilita QuadraCfa
Per il suo prossimo spessore, ha dovuto disabilitare QuadraCfa, presumibilmente una tecnologia proprietaria Qualcomm relativa alla fotocamera. Diciamo presumibilmente perché né io né Sultanxda siamo esattamente sicuri di cosa sia QuadraCfa, ma Sultanxda sa che ha rotto la fotocamera frontale ogni volta che è stata attivata.
Ha osservato che QuadraCfa in qualche modo si sarebbe abilitata, ma non era sicuro del perché o del come lo stesse facendo. Risolvere questo problema ha richiesto una modifica piuttosto non convenzionale da parte sua. In uno shim convenzionale, la funzione shim, una volta compilata, fornisce il simbolo mancante che il BLOB sta cercando. In questo caso, il BLOB aveva già i simboli di cui aveva bisogno, quelli che presumibilmente rappresentavano le funzioni che stavano dando inizio a QuadraCfa.
Pertanto, aveva bisogno di sovrascrivere i simboli utilizzati dalla telecamera HAL e, in sostanza, di renderli "mancanti". il suo gli spessori fornirebbero quei simboli “mancanti”. L'unico modo per farlo è tramite modifica esadecimale dell'HAL della telecamera stessa. L'editing esadecimale consiste fondamentalmente nell'esaminare un mucchio di incomprensibili disorganizzate sotto forma di dati binari per trovare un ago nel pagliaio: una funzione o una stringa che stai cercando di modificare.
La modifica esadecimale di una funzione è sostanzialmente più difficile della modifica esadecimale di una stringa, ma fortunatamente Sultanxda è riuscita a evitare di dover modificare esadecimale le funzioni dietro QuadraCfa invece modificando esadecimale i nomi dei simboli per annullarli.
Spessore n. 3: correzione degli arresti anomali della luce intensa
Successivamente, Sultanxda ha scoperto che scattare una foto dalla fotocamera frontale in condizioni di illuminazione intensa avrebbe causato il crash della fotocamera. Per riprodurre questo bug sul proprio dispositivo, Sultanxda in realtà ha attivato la funzione torcia del suo OnePlus One e ha puntato la luce davanti alla fotocamera frontale del OnePlus 3T per farlo crashare e produrre log utilizzabili! Una volta scoperto quale funzione stava causando l'incidente, ha creato uno spessore per forzare il dispositivo a utilizzare sempre la modalità scarsa illuminazione per la fotocamera frontale.
Spessore n. 4: immagini della fotocamera frontale a bassa risoluzione
Dopo aver risolto il problema della luce intensa con lo shim precedente, Sultanxda ha scoperto un altro bug che in realtà è sorto come risultato diretto di quello shim: immagini a bassa risoluzione della fotocamera frontale. Invece di scattare foto alla risoluzione richiesta dall'utente (es. 16MP), la foto risultante verrebbe scattata a 4MP.
Per risolvere questo problema è stato necessario spessorare le funzioni handleSuperResolution E isSuperResolution per restituire sempre true, ma SOLO quando la fotocamera frontale è attiva (perché altrimenti la fotocamera si bloccherebbe quando si scattano foto dal sensore posteriore).
Lezione appresa: lo shimming può essere difficile
Sultanxda ammette che gli spessori che ha dovuto creare per far funzionare la fotocamera frontale di OnePlus 3T non rappresentano il tipico esempio di spessore. È piuttosto orgoglioso del suo spessore data la sua complessità e la rara necessità di modificare in modo esadecimale il BLOB stesso. Ma questo esempio dimostra semplicemente quanto possa essere difficile far funzionare l'hardware della fotocamera su determinati dispositivi.
Possano le tue avventure con la fotocamera essere meno dolorose delle mie. -Sultanxda
Registri, registri e ancora registri. Senza un modo coerente per riprodurre un arresto anomalo e senza registri, gli sviluppatori hanno poche speranze di trovare l'origine del problema. Anche se trovano la causa del problema, non è sempre una soluzione semplice. L'intero processo di individuazione ed eliminazione di questi bug può richiedere giorni o settimane ed è il motivo per cui riparare la fotocamera sulle ROM AOSP è uno dei compiti più difficili.
Se sul tuo dispositivo è stata trasferita una ROM AOSP con hardware perfettamente funzionante, si spera che tu possa iniziare a farlo apprezzo la lotta che quegli sviluppatori potrebbero aver affrontato per offrirti quelli caratteristiche. Apprezzateli per il loro lavoro, perché non è facile. Si tratta di un lavoro enorme che la stragrande maggioranza degli utenti non noterà nemmeno, poiché gli sviluppatori di talento sui nostri forum si stanno prendendo cura delle molte parti invisibili di Android.
Vorremmo ringraziare in modo speciale Sultanxda per i numerosi contributi che ha suggerito nella realizzazione di questo articolo.