Come funziona Android. Elettronica indossabile ed elettrodomestici

27.04.2019 Errori

Come funziona Android

Impara al riguardo opportunità nascoste sistemi software Puoi capire come funzionano. In alcuni casi, questo è difficile da fare, poiché il codice di sistema può essere chiuso, ma in caso Android possiamo studiare l'intero sistema dentro e fuori. In questo articolo non parlerò di tutte le sfumature di Android e mi concentrerò solo su come si avvia il sistema operativo e quali eventi si verificano tra la pressione del pulsante di accensione e l'aspetto del desktop.

Lungo la strada, spiegherò cosa possiamo cambiare in questa catena di eventi e in che modo gli sviluppatori di firmware personalizzati utilizzano queste funzionalità per implementare cose come l'ottimizzazione dei parametri del sistema operativo, l'espansione dello spazio di archiviazione delle applicazioni, l'abilitazione dello scambio, varie personalizzazioni e molto altro. Tutte queste informazioni possono essere utilizzate per creare il proprio firmware e implementare vari hack e modifiche.

Primo passo. U-BOOT e tabella delle partizioni

Tutto inizia con il bootloader principale. Dopo l'accensione, il sistema esegue il codice del bootloader memorizzato nella memoria permanente del dispositivo. Molto spesso, il suo ruolo è giocato da versione modificata Bootloader u-boot con supporto integrato per il protocollo fastboot, ma il produttore del chip mobile o dello smartphone/tablet ha il diritto di scegliere qualsiasi altro bootloader di suo gusto. Ad esempio, Rockchip utilizza il proprio bootloader non fastboot e devono utilizzare strumenti proprietari per riprogrammarlo e gestirlo.

Il protocollo fastboot, a sua volta, è un sistema di gestione del bootloader da PC che consente di eseguire azioni come lo sblocco del bootloader, il flashing di un nuovo kernel e il ripristino, l'installazione del firmware e molti altri. Il punto del fastboot è poter riportare lo smartphone al suo stato originale in una situazione in cui tutti gli altri mezzi falliscono. Fastboot rimarrà al suo posto anche se, a seguito di esperimenti, cancellerai dal tuo smartphone tutto il contenuto di tutte le sezioni della memoria NAND, perdendo l'accesso sia ad Android che al ripristino.

Dopo aver ricevuto il controllo, u-boot controlla la tabella delle partizioni e trasferisce il controllo al kernel flashato sulla partizione denominata boot, dopodiché il kernel estrae l'immagine RAM dalla stessa partizione in memoria e inizia a caricare Android o la console di ripristino. La memoria NAND nei dispositivi Android è suddivisa in sei sezioni condizionalmente obbligatorie:

boot - contiene il kernel e il disco RAM, di solito di circa 16 MB di dimensione;
recovery - console di ripristino, consiste in un kernel, un set applicazioni della console e file delle impostazioni, dimensione 16 Mb;
sistema: contiene Android, nei dispositivi moderni ha una dimensione di almeno 1 GB;
cache - progettato per memorizzare i dati memorizzati nella cache, utilizzato anche per salvare il firmware durante un aggiornamento OTA e quindi ha una dimensione simile a sezione di sistema;
userdata - contiene impostazioni, applicazioni e dati utente, tutto lo spazio di memoria NAND rimanente gli viene allocato;
misc - contiene un flag che determina in quale modalità deve essere avviato il sistema: Android o recovery.

Nella terminologia di Linux, un disco RAM è una specie di virtuale duro un disco che esiste solo nella RAM. In una fase di avvio iniziale, il kernel estrae il contenuto del disco dall'immagine e lo monta come file system root (rootfs).

Oltre a queste potrebbero esserci anche altre sezioni, tuttavia il markup generale viene determinato in fase di progettazione dello smartphone e, nel caso di u-boot, viene cucito nel codice del bootloader. Ciò significa che: 1) la tabella delle partizioni non può essere uccisa, poiché può sempre essere ripristinata utilizzando comandi di avvio rapido formato originale; 2) per cambiare la tabella delle partizioni, dovrai sbloccare e aggiornare il bootloader con nuovi parametri. Ci sono eccezioni a questa regola, tuttavia. Ad esempio, il bootloader dello stesso Rockchip memorizza le informazioni sulla partizione nel primo blocco di memoria NAND, quindi non è necessario eseguire il flashing del bootloader per modificarlo.

Particolarmente interessante è la sezione varie. Si presume che sia stato originariamente creato per archiviare varie impostazioni indipendente dal sistema principale, ma in questo momento viene utilizzato per un solo scopo: dire al bootloader da quale partizione avviare il sistema: avvio o ripristino. Questa possibilità, in particolare, utilizza l'applicazione Gestore ROM per riavvio automatico sistemi in recovery con installazione automatica del firmware. Sulla sua base, il meccanismo doppio avvio Ubuntu Touch, che cuci Caricatore di avvio di Ubuntu

in recovery e consente di controllare quale sistema avviare successivamente. Cancella la partizione misc - Android è caricato, pieno di dati - il ripristino è caricato ... cioè Ubuntu Touch.

Parte del codice del bootloader che definisce la tabella delle partizioni:

partizioni di partizione struct static = ( ( "-", 123 ), ( "xloader", 128 ), ( "bootloader", 256 ), /* La partizione "misc" è richiesta per il ripristino */ ( "misc", 128 ), ( "-", 384), ( "efs", 16384 ), ( "recupero", 8*1024 ), ( "avvio", 8*1024 ), ( "sistema", 512*1024 ), ( "cache" , 256*1024 ), ("dati utente", 0 ), ( 0, 0 ) );

Passo due. partizione di avvio

Se la sezione misc non ha un flag di avvio di ripristino, u-boot trasferisce il controllo al codice che si trova nella sezione di avvio. Non è altro che il kernel Linux; si trova all'inizio della sezione e subito dopo è un'immagine del disco RAM impacchettata utilizzando gli archivi cpio e gzip, contenente le directory necessarie per il funzionamento di Android, il sistema di inizializzazione init e altri strumenti. Non esiste un file system sulla partizione di avvio, il kernel e il disco RAM si susseguono semplicemente. Il contenuto del disco RAM è:

data - directory per il montaggio della partizione con lo stesso nome;
dev - file del dispositivo;
proc - procfs è montato qui;
sbin - un insieme di utilità e demoni ausiliari (adbd, per esempio);
res - una serie di immagini per il caricatore (vedi sotto);
sys - sysfs è montato qui;
sistema - directory per il montaggio della partizione di sistema;
caricatore: un'applicazione per visualizzare il processo di ricarica;
build.prop- Impostazioni di sistema;
init - sistema di inizializzazione;
init.rc - impostazioni del sistema di inizializzazione;
ueventd.rc - impostazioni per il demone uventd incluso in init.

Questo è, per così dire, lo scheletro del sistema: un insieme di directory per il collegamento di file system da partizioni di memoria NAND e un sistema di inizializzazione che si occuperà di tutto il resto del lavoro di avvio del sistema. L'elemento centrale qui è l'applicazione init e la sua configurazione init.rc, che tratterò più dettagliatamente in seguito. Nel frattempo, voglio prestare attenzione ai file charger e ueventd.rc, nonché alle directory sbin, proc e sys.

Il file del caricatore è una piccola applicazione il cui unico compito è visualizzare l'icona della batteria. Non ha nulla a che fare con Android e viene utilizzato quando il dispositivo è collegato al caricabatterie nello stato spento. In questo caso, Android non si avvia e il sistema avvia semplicemente il kernel, collega il disco RAM e avvia il caricabatterie. Quest'ultimo mostra l'icona della batteria, la cui immagine in tutti i possibili stati è memorizzata in normali file PNG all'interno della directory res.

Il file ueventd.rc è una configurazione che definisce quali file di dispositivo nella directory sys devono essere creati nella fase di avvio del sistema. In base al kernel Sistemi Linux si accede all'hardware tramite file speciali all'interno della directory dev e il demone ueventd, che fa parte di init, è responsabile della loro creazione in Android. Normalmente funziona in modalità automatica, accettando i comandi per creare file dal kernel, ma alcuni file devono essere creati da soli. Sono elencati in ueventd.rc.

directory di sbin magazzino Android di solito non contiene altro che adbd, ovvero il demone ADB, che è responsabile del debug del sistema dal PC. Si avvia in una fase iniziale dell'avvio del sistema operativo e consente di identificare possibili problemi nella fase di inizializzazione del sistema operativo. Nel firmware personalizzato, puoi trovare un sacco di altri file in questa directory, come mke2fs, che potrebbe essere necessario se le partizioni devono essere riformattate in ext3/4. Inoltre, i modder spesso mettono lì un BusyBox, con il quale puoi chiamare centinaia di comandi Linux.

Durante il processo di avvio, Android visualizza tre diverse schermate di avvio: la prima appare subito dopo aver premuto il pulsante di accensione e viene flashata nel kernel Linux, la seconda viene visualizzata durante le prime fasi dell'inizializzazione e viene scritta nel file /initlogo.rle (quasi non utilizzato oggi), l'ultimo viene avviato utilizzando l'applicazione bootanimation ed è contenuto nel file /system/media/bootanimation.zip.

La directory proc per Linux è standard, nei passaggi di avvio successivi init vi collegherà procfs, un file system virtuale che fornisce l'accesso alle informazioni su tutti i processi sul sistema. Il sistema collegherà sysfs alla directory sys, che apre l'accesso alle informazioni sull'hardware e le sue impostazioni. Con sysfs, ad esempio, puoi mettere il dispositivo in modalità di sospensione o modificare l'algoritmo di risparmio energetico utilizzato.

Il file build.prop è destinato alla memorizzazione di basso livello impostazioni Android. Successivamente, il sistema ripristinerà queste impostazioni e le sovrascriverà con i valori del file system/build.prop, che non è ancora disponibile.

Fase due, alternativa. sezione di recupero

Nel caso in cui sia impostato il flag di avvio di ripristino nella sezione misc o l'utente abbia acceso lo smartphone tenendo premuto il tasto di riduzione del volume, u-boot trasferirà il controllo al codice che si trova all'inizio della sezione di ripristino. Come la partizione di avvio, contiene il kernel e un disco RAM, che viene decompresso in memoria e diventa la radice del file system. Tuttavia, il contenuto del disco RAM è leggermente diverso qui.

a differenza di partizione di avvio, fungendo da collegamento di transizione tra le diverse fasi del caricamento del sistema operativo, partizione di ripristinoè completamente autosufficiente e contiene un sistema operativo in miniatura che non è in alcun modo correlato ad Android. Il ripristino ha un proprio core, un proprio set di applicazioni (comandi) e una propria interfaccia che consente all'utente di attivare funzioni di utilità.

In un ripristino standard (stock), di solito ci sono solo tre di queste funzioni: installazione del firmware firmato con la chiave del produttore dello smartphone, cancellazione e riavvio. Nella recovery modificata di terze parti, come ClockworkMod e TWRP, ci sono molte più funzioni. Possono formattare file system, installare firmware firmato con qualsiasi chiave (leggi: personalizzato), montare file system su altre partizioni (per il debug del sistema operativo) e includere il supporto di script che consente di automatizzare il processo del firmware e molte altre funzioni.

Con l'aiuto degli script, ad esempio, puoi fare in modo che dopo il caricamento il ripristino si trovi automaticamente sulla scheda di memoria firmware richiesto, li ha installati e riavviati in Android. Questa funzione è utilizzata da ROM Manager, strumenti di flash automatico e automatico aggiornamenti mod cianogeno e altro firmware.

Recupero personalizzato supporta anche gli script di backup che si trovano nella directory /system/addon.d/. Davanti ripristino del firmware controlla gli script e li esegue prima di eseguire il flashing. Grazie a tali script, i gapp non scompaiono dopo l'installazione nuova versione firmware.

Fase tre. Inizializzazione

Quindi, dopo aver ricevuto il controllo, il kernel collega il disco RAM e, dopo l'inizializzazione di tutti i suoi sottosistemi e driver, avvia il processo di inizializzazione, da cui inizia l'inizializzazione di Android. Come ho detto, init ha file di configurazione init.rc, da cui il processo apprende cosa deve fare esattamente per far apparire il sistema. Negli smartphone moderni, questa configurazione ha una lunghezza impressionante di diverse centinaia di righe ed è anche dotata di un trailer di diverse configurazioni figlio che sono collegate a quella principale tramite la direttiva import. Tuttavia, il suo formato è abbastanza semplice ed è essenzialmente un insieme di comandi diviso in blocchi.

Ogni blocco definisce una fase di caricamento o, nel linguaggio degli sviluppatori Android, un'azione. I blocchi sono separati l'uno dall'altro da una direttiva on seguita da un nome di azione, ad esempio su early-init o su post-fs. Il blocco di comandi verrà eseguito solo se viene attivato il trigger con lo stesso nome. All'avvio, init attiverà a turno i trigger early-init, init, early-fs, fs, post-fs, early-boot e boot, eseguendo così i blocchi di comando appropriati.

Se il file di configurazione estrae molte altre configurazioni elencate all'inizio (e questo è quasi sempre il caso), i blocchi di comandi con lo stesso nome al loro interno verranno uniti alla configurazione principale, in modo che quando il trigger si attiva, init verrà eseguito comandi dai blocchi corrispondenti di tutti i file. Questo viene fatto per la comodità di generare file di configurazione per più dispositivi, quando la configurazione principale contiene comandi comuni a tutti i dispositivi e comandi specifici per ciascun dispositivo vengono scritti in file separati.

La più notevole delle configurazioni aggiuntive è initrc.devicename.rc dove il nome della variabile viene determinato automaticamente in base al contenuto del file ro.hardware. Questo è un file di configurazione specifico della piattaforma che contiene blocchi di comandi specifici per dispositivo specifico. Oltre ai comandi responsabili dell'ottimizzazione del kernel, contiene anche qualcosa del genere:

mount_all ./fstab.devicename

Significa che init ora dovrebbe montare tutti i file system elencati nel file ./fstab.devicename, che ha la seguente struttura:

device_name (partizione) mount_point file_system fs_options altre opzioni

Di solito contiene le istruzioni per collegare i file system dalle partizioni NAND interne alle directory /system (OS), /data (impostazioni dell'applicazione) e /cache (dati memorizzati nella cache). Tuttavia, modificando leggermente questo file, possiamo forzare init ad avviare il sistema dalla memory stick. Per fare ciò, è sufficiente suddividere la scheda di memoria in tre o quattro partizioni: 1 GB / ext4, 2 GB / ext4, 1 GB / ext4 e lo spazio rimanente fat32. Successivamente, è necessario determinare i nomi delle partizioni della scheda di memoria nella directory /dev (per dispositivi diversi sono diversi) e sostituirli con nomi originali dispositivi nel file fstab.

Alla fine del blocco di avvio, init molto probabilmente incontrerà il comando class_start default, che ti dirà di avviare tutti i servizi elencati nella configurazione relativi alla classe predefinita. Le descrizioni dei servizi iniziano con una direttiva di servizio seguita dal nome del servizio e dal comando che deve essere eseguito per avviarlo. A differenza dei comandi elencati in blocchi, i servizi devono essere sempre eseguiti, quindi per tutta la vita dello smartphone init si bloccherà in background e lo monitorerà.

Android moderno include decine di servizi, ma due di essi hanno uno stato speciale e determinano l'intero ciclo di vita del sistema.

Fase quattro. Zigote e App_process

Ad un certo punto del caricamento, init incontrerà un blocco come questo alla fine della configurazione:

servizio zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server classe default socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart riavvia il supporto onrestart riavvia netd

Questa è una descrizione del servizio Zygote, un componente chiave di qualsiasi sistema Android responsabile dell'inizializzazione, dell'avvio dei servizi di sistema, dell'avvio e dell'arresto delle applicazioni utente e di molte altre attività. Zygote viene avviato utilizzando una piccola applicazione /system/bin/app_process, che è molto chiaramente visibile nella parte di configurazione sopra. Il compito di app_proccess è avviare la macchina virtuale Dalvik, il cui codice si trova nella libreria condivisa /system/lib/libandroid_runtime.so, e quindi eseguire Zygote su di essa.

Quando tutto questo è fatto e Zygote ha il controllo, inizia a costruire l'ambiente di runtime Java caricando tutte le classi Java del framework (attualmente oltre 2000). Quindi avvia system_server, che include la maggior parte dei servizi di sistema di alto livello (scritti in Java), inclusi Window Manager, Status Bar, Package Manager e, soprattutto, Activity Manager, che in futuro sarà responsabile di ricevere applicazioni di segnali di inizio e fine.

Dopodiché, Zygote apre il socket /dev/socket/zygote e va a dormire, in attesa di dati. In questo momento, Activity Manager lanciato in precedenza trasmette l'intento Intent.CATEGORY_HOME per trovare l'applicazione responsabile della creazione del desktop e dà il nome a Zygote tramite il socket. Quest'ultimo, a sua volta, esegue il fork e avvia l'applicazione sopra macchina virtuale. Voilà, abbiamo un desktop trovato sullo schermo da Activity Manager e lanciato da Zygote, e una barra di stato lanciata da system_server come parte del servizio Status Bar. Dopo aver toccato l'icona, il desktop invierà un intento con il nome di questa applicazione, verrà accettato dall'Activity Manager e passerà il comando per avviare l'applicazione al demone Zygote.

Tutto questo può sembrare un po' confuso, ma la cosa più importante è ricordare tre semplici cose:

Per molti versi, Android è molto diverso dagli altri sistemi operativi e non puoi capirlo in un colpo solo. Tuttavia, se capisci come funziona tutto, si aprono semplicemente possibilità infinite. A differenza di iOS e Windows Phone, il sistema operativo di Google ha un'architettura molto flessibile che consente di modificarne seriamente il comportamento senza dover scrivere codice. Nella maggior parte dei casi, è sufficiente correggere le configurazioni e gli script necessari.

][ 05.14

Nella vastità di Runet è difficile trovare informazioni costruttive e ben presentate sul dispositivo del sistema operativo Android. Per la maggior parte, le informazioni sono frammentate e incomplete, non esiste una parte introduttiva concetti basilari il che rende difficile la comprensione e la comprensione per i principianti. Privo di conoscenza di base dispositivo e l'algoritmo del sistema operativo Android, è impossibile eseguire il debug o personalizzare il firmware, sviluppare con il sistema operativo Android. Questo è ciò che mi ha spinto a scrivere questo articolo, in cui proverò, nel solito e linguaggio semplice, trasmettere cose "difficili".

Il materiale è rivolto principalmente allo studio degli utenti ordinari e si presenta come un'escursione introduttiva al mondo dei sistemi operativi Android. Pertanto, qui verranno presentate informazioni concise e superficiali senza approfondimenti e sfumature tecniche. Questo materiale sarà utile a tutti coloro che sono impegnati nel flashing e nella personalizzazione del firmware, nello sviluppo con il sistema operativo Android, nella riparazione di dispositivi mobili sistemi informatici e l'utente medio, per una migliore comprensione dei principi di funzionamento e delle capacità del proprio Android "a.

Partizioni della memoria interna di Android

La memoria interna del dispositivo su Android è suddivisa in diversi dischi logici (partizioni). Ecco un classico markup di memoria:

Boot loader- ecco un programma (bootloader) che permette di eseguire il sistema operativo Android, Recovery e altre modalità di servizio.

Recupero- come suggerisce il nome, è installato qui menu di ingegneria Recupero o solo Recupero.

Stivale- il cuore del sistema operativo Android, ecco il kernel, i driver e le impostazioni per la gestione del processore e della memoria.

Sistema- la partizione di sistema, che contiene tutti i file necessari per il funzionamento del sistema operativo Android, file, è come Cartella Windows sull'unità C:\ (di seguito, ci assoceremo al sistema operativo Windows)

Dati- una sezione per l'installazione delle applicazioni e la memorizzazione dei loro dati. (file di programma)

utente- questa è una nota sdcard o, più semplicemente, un posto per i file degli utenti (My Documents) Qui siamo costretti a fare una digressione, perché. Questa sezione ha diverse opzioni:

La partizione non è nella memoria interna e viene utilizzata invece un'unità esterna, l'opzione più popolare. (Fig. 1)
Nei dispositivi con ampia memoria incorporata, questa sezione visto come sdcard e scheda esterna la memoria è vista come sdcard2 o extsd (potrebbero esserci altri nomi). Di solito si trova su dispositivi con Android 3.2. (Fig.2 Opzione 1)
Questa opzione è stata sostituita opzione precedente, insieme ad Android 4.0. La sezione Utente è stata sostituita con una cartella multimediale nella sezione Dati, che ha consentito di utilizzare tutta la memoria a disposizione dell'utente per l'installazione dei programmi e la memorizzazione dei dati, e non la quantità che il produttore ci ha assegnato. In altre parole, sdcard e dati sono una cosa sola. (Fig.2 Opzione 2)

Ora che sappiamo cosa e dove si trova, scopriamo perché è lì e come queste informazioni possono esserci utili.

Iniziamo con Bootloader. Questo è un bootloader che avvia Android, recovery, ecc. Quando premiamo il pulsante di accensione, il bootloader si avvia e, in caso contrario comandi aggiuntivi(tasti premuti), avvia il caricamento del boot. Se è stata premuta la combinazione di tasti (ogni dispositivo ha la sua), viene avviata, a seconda del comando, recovery, fastboot o apx. La figura seguente mostra chiaramente cosa viene avviato dal Bootloader e come le partizioni sono interconnesse.

Come si può vedere dalla Figura 3, la partizione di ripristino non influisce sul caricamento del sistema operativo Android, ma allora perché è necessaria? Proviamo a capirlo.

Il ripristino (ripristino) è essenzialmente una piccola utility sul kernel Linux e viene caricato indipendentemente da Android. La sua normale funzionalità non è ricca: è possibile ripristinare il dispositivo alle impostazioni di fabbrica o aggiornare il firmware (precedentemente scaricato su sdcard). Ma, grazie agli artigiani, abbiamo modificato recovery attraverso il quale è possibile installare firmware (custom) modificato, configurare Android, creare backup e molto altro. La presenza o meno della recovery, così come la sua versione, non pregiudicano le prestazioni del sistema operativo Android (molto domande frequenti sui forum).

I lettori particolarmente attenti potrebbero notare un certo Fastboot in Fig. 3. Questa è un'interfaccia per lavorare direttamente con le sezioni di memoria interna usando la riga di comando. Attraverso di esso, è possibile eseguire il flashing del ripristino, del kernel o della nuova versione del firmware o formattare (eliminare tutte le informazioni) l'una o l'altra partizione.

Dato che stiamo parlando di interfacce, voglio parlarne un'altra, abbastanza nota: adb (debugbridge Android). Questa è la cosiddetta modalità di debug ed è chiamata così per un motivo: attraverso di essa è possibile monitorare il lavoro sia del sistema nel suo insieme che delle singole applicazioni. Ma non è tutto, adb aiuto Puoi prenderlo accesso completo al file system del dispositivo e modificare i file di sistema o eseguire il pull Informazioni importanti quando il dispositivo è bloccato durante il caricamento. Non descriverò tutte le funzioni della modalità di debug. il mio obiettivo è trasmettere informazioni generali, non panoramica dettagliata sulle funzioni di una modalità particolare.

Dopo aver affrontato la teoria, eseguiamo il sistema operativo Android.

Premiamo il pulsante di accensione - Bootloader si avvia, che carica il kernel (avvio), a sua volta avvia il sistema (Sistema), beh, carica già i programmi (dati) e lo spazio utente (utente). (Fig.3)

E ora andiamo alla directory principale e guardiamo l'interno del sistema operativo Android stesso:

In questo schema, abbiamo fornito solo le directory necessarie per la familiarizzazione. In effetti, ce ne sono molti di più e sarà necessario un intero articolo per rivedere solo una cartella di sistema.

E così, la cartella dei dati. Come puoi intuire dal nome, è in qualche modo collegato ai dati, ma con cosa? Sì, con quasi tutti, si tratta di dati su sincronizzazione e account, password per punti di accesso wifi e impostazioni VPN, eccetera. Tra le altre cose, puoi trovare le cartelle app, data e dalvik-cache qui - considera il loro scopo:

app: qui vengono installati programmi e giochi.
dati: qui vengono memorizzati i dati dell'applicazione, le relative impostazioni, i salvataggi di gioco e altre informazioni.
dalvik-cache - area del programma cache per Programmi Dalvik. Dalvik Macchina virtuale Java, che è la base per il funzionamento dei programmi con estensione *.apk.
Per rendere più veloce l'avvio dei programmi, viene creata la loro cache.

La cartella Sistema contiene i dati di sistema e tutto il necessario per il funzionamento del sistema operativo. Diamo un'occhiata ad alcune di queste cartelle:

app - qui ci sono le applicazioni di sistema (sms, telefono, calendario, impostazioni, ecc.), nonché le applicazioni installate dal produttore del dispositivo (widget con marchio, sfondi animati, ecc.).
caratteri - caratteri di sistema
media: contiene melodie standard per chiamate, notifiche, sveglie e suoni dell'interfaccia, nonché animazioni di avvio (bootanimation)
build.prop - Questo file è menzionato, quasi il primo, in conversazioni e articoli sulla messa a punto del sistema. Contiene un numero enorme di impostazioni, come densità dello schermo, ritardo del sensore di prossimità, controllo wifi, nome e produttore del dispositivo e molte altre opzioni.

Diritti di root nel sistema operativo Android

Come in qualsiasi sistema simile a Linux, nel sistema operativo Android, l'accesso ai file e alle directory di sistema viene effettuato con i diritti di superutente Root. In questa sezione, abbiamo deciso di considerare il principio di funzionamento dei diritti di superutente del sistema operativo Android, la possibilità di modificare file di sistema o sezioni logiche dello spazio file con diritti di superutente Root.

- Sapere quale cartella è buona, ma puoi fare qualcosa al riguardo?

- Sì! Ma sono necessari i diritti di superutente (root) o, se tracciamo un'analogia con Windows, i diritti di amministratore. Inizialmente, tutti i dispositivi Android sono privi dei diritti di root per utente finale, cioè. quando acquistiamo un dispositivo, non ne siamo proprietari a tutti gli effetti. Questo è stato fatto per proteggersi malware, e dall'utente stesso - dopotutto, in mani incapaci, l'accesso completo al sistema può portare alla "morte" del sistema operativo e alla conseguente necessità di eseguire il flashing del dispositivo.

"Beh, a che serve una cosa così pericolosa?"- tu chiedi.

Ora diremo:

La possibilità di eseguire il backup dei dati e ripristinarli dopo il flashing o l'eliminazione accidentale.
Messa a punto del sistema manualmente o utilizzando programmi speciali.
Rimozione di applicazioni di sistema, melodie, sfondi, ecc.
La variazione aspetto esteriore Sistema operativo (ad es. visualizzazione della percentuale della batteria)
Aggiunta di funzionalità (supporto per reti ad hoc, ad esempio)

Questo elenco può essere continuato per molto tempo, ma penso che questi esempi saranno sufficienti per avere un'idea delle possibilità e dell'ampiezza di applicazione dei privilegi di root.

- Tutto questo è fantastico, ma ora qualsiasi programma sarà in grado di accedere al "cuore" del sistema operativo e ai miei dati?

- Non. Decidi di consentire a una particolare applicazione di ricevere accesso alla radice, o no. Per questo, c'è il programma Superuser o la sua sorella avanzata SuperSU. Senza questo o un programma simile, non è possibile utilizzare root.

Come puoi vedere, Android non è così complicato. sistema operativo per capire l'utente. Se hai già avuto esperienza con sistemi operativi simili a Linux, troverai molte somiglianze con i sistemi Android e questa somiglianza è giustificata. Il sistema Android è un derivato e si basa sul kernel Linux. Spero che dopo aver letto l'articolo tu abbia imparato qualcosa di nuovo o ricevuto una risposta a una domanda che ti interessava da tempo.

Ogni smartphone è composto da tanti componenti complessi e non ci penserai sempre prima di scegliere un modello di telefono. Tuttavia, è importante sapere quale hardware aiuta il tuo smartphone a funzionare.

In questo articolo, analizzeremo le parti principali di quello che è diventato uno dei dispositivi elettronici più importanti sul mercato. Considera in cosa consiste uno smartphone e perché è necessario questo o quel componente. Ora ci sono molti diversi modelli di smartphone, diversi design, con caratteristiche diverse, durata della batteria e così via. Ma se capisci l'imbottitura hardware di uno smartphone, scegliere il modello giusto sarà molto più semplice.

1.Display

Uno dei componenti più evidenti di uno smartphone è il suo schermo. Tutto ciò che vedi sullo schermo viene elaborato e controllato da componenti interni. Ora ci sono due tecnologie per la produzione di display:

Schermi LCD, sono realizzati con tecnologia IPS o TFT;
Schermi LED realizzati con tecnologia AMOLED o Super AMOLED.

Il display a cristalli liquidi utilizza una retroilluminazione per produrre un'immagine. La luce bianca passa attraverso i filtri e grazie alla capacità di controllare le proprietà dei cristalli, puoi vedere colori diversi. La luce non è creata dallo schermo stesso, è creata da una fonte di luce dietro di esso.

Lo schermo LED funziona in modo diverso. Ogni pixel che vedi sullo schermo è un LED separato. Qui, lo schermo stesso crea colori luminosi e colorati. Il vantaggio di Super AMOLED rispetto a IPS è che quando il pixel è spento vedrai nero, non utilizza la batteria. Pertanto, gli smartphone con AMOLED sono più efficienti per la durata della batteria. Ma Schermi AMOLED più costoso dell'IPS, quindi uno smartphone con un tale display costerà molto di più.

2. Batteria

Gli smartphone in genere utilizzano batterie agli ioni di litio e possono essere rimovibili o meno. Grazie a questa tecnologia, non è necessario calibrare o testare la batteria come faresti con le batterie a base di nichel. Tuttavia, queste batterie hanno molti problemi propri.

3. System-on-a-Chip (SoC)

SoC o scheda madre con un processore è il componente più importante del tuo smartphone. Alcuni utenti potrebbero pensare che sia il processore del dispositivo, ma è più di questo. Il SoC include non solo la CPU, ma anche la GPU, il modem LTE, il controller dello schermo, gli adattatori wireless e altri blocchi di silicio che fanno funzionare il telefono.

Esistono smartphone che utilizzano SoC di Qualcomm, MediaTek, Samsung, chip proprietari di Krirn, Apple, ma utilizzano tutti la stessa architettura: ARM. ARM non solo produce processori, ma concede anche in licenza la loro architettura ad altre aziende, in modo che tutti possano utilizzare la stessa tecnologia per creare SoC moderni e potenti.

Alcune aziende rilasciano le loro linee architettoniche compatibili con ARM e utilizzabili negli smartphone. Un esempio potrebbero essere i chipset Apple in esecuzione su processori Cyclone o processori Qualcomm Kryo. SoC: questi sono i componenti principali di ciò in cui è composto uno smartphone.

4. Interno e RAM

Nessuno smartphone può funzionare senza RAM e memoria di sistema. La maggior parte dei dispositivi utilizza RAM LPDDR3 o LPDDR4 e alcuni modelli di fascia alta vengono forniti con LPDDR4X. La combinazione LP significa Low Power, la tensione di alimentazione di questi microcircuiti è ridotta, e questo li rende più efficienti in termini di consumo energetico.

LPDDR4 è più efficiente di LPDDR3 e LPDDR4X è più efficiente ed economico di entrambi. C'è anche una memoria ancora più affettiva: LPDDR5.

Per quanto riguarda la memoria interna, qui viene utilizzata una memoria flash da 32 a 256 GB. Le esigenze degli utenti sono in costante crescita e i volumi aumenteranno di conseguenza. Quando accendi il telefono, vedrai che la dimensione dell'unità è inferiore a quella pubblicizzata. Ad esempio, dice che l'unità è 64 GB e 53-55 GB sono disponibili per la registrazione. Questa memoria è occupata dal sistema operativo e dalle applicazioni.

5. Modem

Poiché gli smartphone sono ancora telefoni, hanno bisogno di componenti di comunicazione per ricevere ed effettuare chiamate, inviare messaggi di testo e connessione a Internet. Ecco a cosa servono i modem. Ogni produttore di SoC ha il proprio marchio di modem, questi sono Qualcomm, Samsung, Huawei e altri.

Ciascuno dei produttori sta cercando di rilasciare il chip LTE più veloce. Attualmente il chip 9-LTE più veloce, ma non ha senso prenderlo se la tua rete cellulare non supporta tale velocità.

6. Fotocamera

Tutti gli smartphone sono dotati di fotocamera frontale e frontale. Le camere sono composte da tre parti principali:

Sensore- rileva la luce;
Lente- concentra l'immagine;
Processore di immagini.

Il numero di megapixel della fotocamera di uno smartphone è ancora un criterio molto importante, ma ora conta molto meno. Ora il principale fattore limitante è il sensore della fotocamera, così come la sua sensibilità quando la luce lo attraversa.

Il sensore potrebbe comportarsi in modo diverso in ogni smartphone, quindi una foto o un video avranno contrasto, tonalità, saturazione diversi rispetto ad altri smartphone. Poiché gli smartphone hanno un sensore di dimensioni ridotte, tendono a funzionare male in condizioni di scarsa illuminazione.

7. Sensori

La maggior parte degli smartphone moderni ha cinque sensori principali integrati che ti permetteranno di utilizzare il tuo smartphone in modo più conveniente. Eccoli:

Accelerometro- utilizzato dalle applicazioni per determinare l'orientamento del dispositivo e i suoi movimenti. Ad esempio, consente di utilizzare scuotendo lo smartphone per cambiare musica;
Giroscopio- funziona con l'accelerometro per rilevare la rotazione del telefono. Utile per i giochi di corse;
bussola digitale- aiuta a trovare il nord per il normale orientamento sulle mappe;
Sensore di luce- Questo sensore consente di impostare automaticamente la luminosità dello schermo in base alla luce ambientale e aiuta ad aumentare la durata della batteria.
Sensore di prossimità- Durante una chiamata, se il dispositivo si avvicina all'orecchio, questo sensore bloccherà automaticamente lo schermo per evitare tocchi indesiderati.

Questi erano tutti gli elementi principali di uno smartphone, in vari modelli potrebbero esserci altri sensori, come un sensore di pulsazioni, pressione e temperatura, ma sono molto meno comuni.

conclusioni

Abbiamo esaminato in cosa consiste uno smartphone. Ora che hai maggiori informazioni riguardo ai complessi componenti che compongono ogni smartphone, puoi scegliere il tuo futuro acquisto confrontando le caratteristiche dei vari componenti. Quindi scegli il miglior dispositivo che soddisferà pienamente le tue esigenze.

Ti sei mai chiesto come funzionano fastboot o ADB? Oppure perché è quasi impossibile trasformare uno smartphone Android in un mattone? O forse desideri da tempo sapere dove si trova la magia del framework Xposed e perché sono necessari gli script di avvio /system/etc/init.d? E la console di ripristino? Fa parte di Android o è una cosa in sé, e perché la solita recovery non è adatta per l'installazione di firmware di terze parti? Troverai le risposte a tutte queste e molte altre domande in questo articolo.

Come funziona Android

Puoi conoscere le caratteristiche nascoste dei sistemi software comprendendo il principio del loro lavoro. In alcuni casi, questo è difficile da fare, poiché il codice di sistema può essere chiuso, ma nel caso di Android possiamo studiare l'intero sistema dentro e fuori. In questo articolo non parlerò di tutte le sfumature di Android e mi concentrerò solo su come si avvia il sistema operativo e quali eventi si verificano tra la pressione del pulsante di accensione e l'aspetto del desktop.

Primo passo. ABOOT e tabella delle partizioni

Tutto inizia con il bootloader principale. Dopo l'accensione, il sistema esegue il codice del bootloader memorizzato nella memoria permanente del dispositivo. Quindi trasferisce il controllo al bootloader aboot con supporto integrato per il protocollo fastboot, ma il produttore del chip mobile o dello smartphone/tablet ha il diritto di scegliere qualsiasi altro bootloader di sua scelta. Ad esempio, Rockchip utilizza il proprio bootloader non compatibile con l'avvio rapido, che richiede l'uso di strumenti proprietari per la riprogrammazione e la gestione.

Il protocollo fastboot, a sua volta, è un sistema di gestione del bootloader da PC che consente di eseguire azioni come lo sblocco del bootloader, il flashing di un nuovo kernel e il ripristino, l'installazione del firmware e molti altri. Il punto del fastboot è poter riportare lo smartphone al suo stato originale in una situazione in cui tutti gli altri mezzi falliscono. Fastboot rimarrà al suo posto anche se, a seguito di esperimenti, cancellerai tutte le sezioni di memoria NAND contenenti Android e le ripristini dal tuo smartphone.

Dopo aver ricevuto il controllo, aboot controlla la tabella delle partizioni e trasferisce il controllo al kernel flashato nella partizione denominata boot, dopodiché il kernel estrae l'immagine RAM dalla stessa partizione in memoria e inizia a caricare Android o la console di ripristino. La memoria NAND nei dispositivi Android è suddivisa in sei sezioni condizionalmente obbligatorie:

boot - contiene il kernel e il disco RAM, di solito di circa 16 MB di dimensione;
recovery - console di ripristino, composta da un kernel, un set di applicazioni console e un file di impostazioni, dimensione 16 MB;
sistema: contiene Android, nei dispositivi moderni ha una dimensione di almeno 1 GB;
cache - progettata per memorizzare i dati memorizzati nella cache, utilizzata anche per salvare il firmware durante un aggiornamento OTA e quindi ha una dimensione simile alla dimensione della partizione di sistema;
userdata - contiene impostazioni, applicazioni e dati utente, tutto lo spazio di memoria NAND rimanente gli viene allocato;
misc - contiene un flag che determina in quale modalità deve essere avviato il sistema: Android o recovery.

Oltre a queste potrebbero esserci anche altre sezioni, tuttavia il markup generale viene determinato in fase di progettazione dello smartphone e, in caso di aboot, viene cucito nel codice del bootloader. Ciò significa che: 1) la tabella delle partizioni non può essere uccisa, poiché può sempre essere ripristinata utilizzando il comando fastboot oem format; 2) per cambiare la tabella delle partizioni, dovrai sbloccare e aggiornare il bootloader con nuovi parametri. Ci sono eccezioni a questa regola, tuttavia. Ad esempio, il bootloader dello stesso Rockchip memorizza le informazioni sulla partizione nel primo blocco di memoria NAND, quindi non è necessario eseguire il flashing del bootloader per modificarlo.

Parte del codice del bootloader che definisce la tabella delle partizioni

Particolarmente interessante è la sezione varie. Si presume che sia stato originariamente creato per memorizzare varie impostazioni indipendentemente dal sistema principale, ma al momento viene utilizzato per un solo scopo: dire al bootloader da quale partizione avviare il sistema: avvio o ripristino. Questa funzione, in particolare, utilizza l'applicazione ROM Manager per riavviare automaticamente il sistema in recovery con l'installazione automatica del firmware. Sulla base di esso, viene creato il meccanismo di doppio avvio di Ubuntu Touch, che esegue il flashing del bootloader di Ubuntu in recovery e consente di controllare quale sistema avviare la volta successiva. Cancella la partizione misc - Android è caricato, pieno di dati - il ripristino è caricato ... cioè Ubuntu Touch.

Passo due. partizione di avvio

Se la sezione misc non ha un flag di avvio di ripristino, aboot trasferisce il controllo al codice che si trova nella sezione di avvio. Non è altro che il kernel Linux; si trova all'inizio della sezione e subito dopo è un'immagine del disco RAM impacchettata utilizzando gli archivi cpio e gzip, contenente le directory necessarie per il funzionamento di Android, il sistema di inizializzazione init e altri strumenti. Non esiste un file system sulla partizione di avvio, il kernel e il disco RAM si susseguono semplicemente. Il contenuto del disco RAM è:

data - directory per il montaggio della partizione con lo stesso nome;
dev - file del dispositivo;
proc - procfs è montato qui;
res - una serie di immagini per il caricatore (vedi sotto);
sbin - un insieme di utilità e demoni ausiliari (adbd, per esempio);
sys - sysfs è montato qui;
sistema - directory per il montaggio della partizione di sistema;
caricatore: un'applicazione per visualizzare il processo di ricarica;
build.prop - impostazioni di sistema;
init - sistema di inizializzazione;
init.rc - impostazioni del sistema di inizializzazione;
ueventd.rc - impostazioni per il demone uventd incluso in init.

Il file ueventd.rc è una configurazione che definisce quali file di dispositivo nella directory sys devono essere creati nella fase di avvio del sistema. Sui sistemi basati su kernel Linux, si accede all'hardware tramite file speciali all'interno della directory dev e il demone ueventd, che fa parte di init, è responsabile della loro creazione in Android. Normalmente funziona in modalità automatica, accettando i comandi per creare file dal kernel, ma alcuni file devono essere creati da soli. Sono elencati in ueventd.rc.

La directory sbin in stock Android di solito contiene nient'altro che adbd, che è il demone ADB responsabile del debug del sistema dal PC. Si avvia in una fase iniziale dell'avvio del sistema operativo e consente di identificare possibili problemi nella fase di inizializzazione del sistema operativo. Nel firmware personalizzato, puoi trovare un sacco di altri file in questa directory, come mke2fs, che potrebbe essere necessario se le partizioni devono essere riformattate in ext3/4. Inoltre, i modder spesso mettono lì un BusyBox, con il quale puoi chiamare centinaia di comandi Linux.

Il file build.prop è progettato per memorizzare le impostazioni Android di basso livello. Successivamente, il sistema ripristinerà queste impostazioni e le sovrascriverà con i valori del file system/build.prop, che non è ancora disponibile.

Partizione radice OUYA TV Box

Fase due, alternativa. sezione di recupero

Nel caso in cui sia impostato il flag di avvio di ripristino nella sezione varie o l'utente abbia acceso lo smartphone tenendo premuto il tasto di riduzione del volume, aboot trasferirà il controllo al codice che si trova all'inizio della sezione di ripristino. Come la partizione di avvio, contiene il kernel e un disco RAM, che viene decompresso in memoria e diventa la radice del file system. Tuttavia, il contenuto del disco RAM è leggermente diverso qui.

A differenza della partizione di avvio, che funge da collegamento di transizione tra le diverse fasi dell'avvio del sistema operativo, la partizione di ripristino è completamente autosufficiente e contiene un sistema operativo in miniatura che non ha nulla a che fare con Android. Il ripristino ha un proprio core, un proprio set di applicazioni (comandi) e una propria interfaccia che consente all'utente di attivare funzioni di utilità.

Con l'aiuto degli script, ad esempio, puoi fare in modo che dopo il caricamento il ripristino trovi automaticamente il firmware necessario sulla scheda di memoria, li installi e si riavvii in Android. Questa funzione è utilizzata da ROM Manager, strumenti di flasher automatico, nonché dal meccanismo di aggiornamento automatico per CyanogenMod e altri firmware.

Il ripristino personalizzato supporta anche gli script di backup che si trovano nella directory /system/addon.d/. Prima di eseguire il flashing, il ripristino verifica la presenza di script e li esegue prima di eseguire il flashing. Grazie a tali script, i gapps non scompaiono dopo l'installazione di una nuova versione del firmware.

Fase tre. Inizializzazione

Quindi, dopo aver ricevuto il controllo, il kernel collega il disco RAM e, dopo l'inizializzazione di tutti i suoi sottosistemi e driver, avvia il processo di inizializzazione, da cui inizia l'inizializzazione di Android. Come ho detto, init ha un file di configurazione init.rc, da cui il processo impara cosa deve fare esattamente per far funzionare il sistema. Negli smartphone moderni, questa configurazione ha una lunghezza impressionante di diverse centinaia di righe ed è anche dotata di un trailer di diverse configurazioni figlio che sono collegate a quella principale tramite la direttiva import. Tuttavia, il suo formato è abbastanza semplice ed è essenzialmente un insieme di comandi diviso in blocchi.

Parte della configurazione init.rc di CyanogenMod

La più notevole delle configurazioni aggiuntive è initrc.devicename.rc, dove il nome del dispositivo viene determinato automaticamente in base al contenuto della variabile di sistema ro.hardware. Questo è un file di configurazione specifico della piattaforma che contiene blocchi di comandi specifici del dispositivo. Oltre ai comandi responsabili dell'ottimizzazione del kernel, contiene anche qualcosa del genere:

Mount_all ./fstab.device_name

Significa che init ora dovrebbe montare tutti i file system elencati nel file ./fstab.devicename, che ha la seguente struttura:

device_name (partizione) mount_point file_system fs_options altre opzioni

Di solito contiene le istruzioni per collegare i file system dalle partizioni NAND interne alle directory /system (OS), /data (impostazioni dell'applicazione) e /cache (dati memorizzati nella cache). Tuttavia, modificando leggermente questo file, possiamo forzare init ad avviare il sistema dalla memory stick. Per fare ciò, è sufficiente suddividere la scheda di memoria in tre 4 sezioni: 1 GB / ext4, 2 GB / ext4, 1 GB / ext4 e lo spazio rimanente fat32. Successivamente, è necessario determinare i nomi delle partizioni della scheda di memoria nella directory /dev (differiscono per i diversi dispositivi) e sostituire con essi i nomi dei dispositivi originali nel file fstab.

Contenuto tipico di un file fstab

L'Android moderno include dozzine di servizi, ma due di essi hanno uno stato speciale e determinano l'intero ciclo di vita del sistema.

Fase quattro. Zigote e app_process

Ad un certo punto del caricamento, init incontrerà un blocco come questo alla fine della configurazione:

Servizio zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class socket predefinito flusso zygote 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart riavvia il supporto onrestart riavvia netd

Questa è una descrizione del servizio Zygote, un componente chiave di qualsiasi sistema Android responsabile dell'inizializzazione, dell'avvio dei servizi di sistema, dell'avvio e dell'arresto delle applicazioni utente e di molte altre attività. Zygote viene avviato utilizzando una piccola applicazione /system/bin/app_process, che è molto chiaramente visibile nel pezzo di configurazione sopra. Il compito di app_proccess è avviare la macchina virtuale Dalvik, il cui codice si trova nella libreria condivisa /system/lib/libandroid_runtime.so, e quindi eseguire Zygote su di essa.

Dopodiché, Zygote apre il socket /dev/socket/zygote e va a dormire, in attesa di dati. In questo momento, Activity Manager lanciato in precedenza trasmette l'intento Intent.CATEGORY_HOME per trovare l'applicazione responsabile della creazione del desktop e dà il nome a Zygote tramite il socket. Quest'ultimo, a sua volta, esegue il fork ed esegue l'applicazione sulla macchina virtuale. Voilà, abbiamo un desktop trovato sullo schermo da Activity Manager e lanciato da Zygote, e una barra di stato lanciata da system_server come parte del servizio Status Bar. Dopo aver toccato l'icona, il desktop invierà un intento con il nome di questa applicazione, verrà accettato dall'Activity Manager e passerà il comando per avviare l'applicazione al demone Zygote

Tutto questo può sembrare un po' confuso, ma la cosa più importante è ricordare tre semplici cose:

Servizi di sistema e thread del kernel

conclusioni

Per molti versi, Android è molto diverso dagli altri sistemi operativi e non puoi capirlo in un colpo solo. Tuttavia, se capisci come funziona tutto, le possibilità sono semplicemente infinite. A differenza di iOS e Windows Phone, il sistema operativo di Google ha un'architettura molto flessibile che permette di modificarne seriamente il comportamento senza dover scrivere codice. Nella maggior parte dei casi, è sufficiente correggere le configurazioni e gli script necessari.

Chi usa l'iPhone da molto tempo sa come funzionavano i primi. versioni iOS. In effetti, era un sistema operativo single-tasking che ti permetteva di lavorare in background o interrompere il lavoro. applicazione corrente solo app preinstallate: stai leggendo un libro, ti chiamano - il lettore di libri è ridotto a icona e sullo schermo viene visualizzata una finestra di chiamata. Ma operazione inversa impossibile: il lettore di libri non solo non può interrompere il lavoro di altre applicazioni, ma verrà ucciso immediatamente dopo la riduzione a icona.

La ragione dell'esistenza di un tale sistema, ovviamente, è di risparmiare il processore, la RAM e la durata della batteria. Grazie a lei (ma non solo), l'iPhone ha potuto funzionare velocemente in condizioni di risorse limitate ed è stato molto attento alla batteria.

Come funziona il sistema operativo Android

Android ha sempre funzionato in modo diverso. Qui puoi eseguire molte applicazioni diverse e tutte rimarranno in memoria e potranno persino funzionare in background. Apri un browser, inserisci un indirizzo e, durante il caricamento della pagina, avvia il tuo client di posta elettronica e leggi le e-mail. Tutto è come sul desktop, con l'eccezione che non è necessario occuparsi della chiusura delle applicazioni, il sistema lo farà da solo quando il la memoria farà alla fine, o non sarà sufficiente ospitare un'applicazione in esecuzione (ovviamente, le applicazioni usate raramente andranno a spese prima di tutto). Questo meccanismo è chiamato killer di memoria insufficiente.

Come root, le impostazioni di low memorykiller possono essere regolate direttamente o con l'aiuto di applicazioni speciali

I servizi erano un elemento importante del sistema multitasking. Si tratta di componenti applicativi speciali che potrebbero funzionare in background assolutamente in qualsiasi condizione: lo schermo è acceso o spento, applicazione ridotta al minimo o distribuito, ai servizi non interessa nemmeno se è in esecuzione domanda del genitore generalmente. Diceva semplicemente "Ehi Android, ho bisogno di risorse della CPU, voglio fare alcuni calcoli" e ha ricevuto quelle risorse. Nella terminologia Android, viene chiamata tale richiesta al sistema sveglia(più precisamente, un wakelock del processore).

Tuttavia, il supporto di uno strumento così potente e utile ha giocato uno scherzo crudele su Google. È apparso un numero enorme di applicazioni che producevano servizi per tutti, eseguivano costantemente una sorta di lavoro e non lasciavano dormire lo smartphone. Installando un centinaio di applicazioni su uno smartphone, l'utente ha ricevuto diverse dozzine di servizi, ognuno dei quali periodicamente ha fatto qualcosa (l'aggiornamento del feed di Twitter mentre il telefono è inattivo è importantissimo).

La situazione era così deplorevole che i produttori cinesi, non gravati dal compito di mantenere la compatibilità con androide originale(questo è richiesto se vuoi installare sul tuo Gli smartphone giocano Store), ha semplicemente disabilitato i meccanismi di mantenimento del ciclo di vita dei servizi per le applicazioni non di sistema nei propri smartphone.

Gli utenti avanzati sono andati dall'altra parte: hanno ottenuto i diritti di root e hanno installato l'applicazione Greenify, che ha permesso loro di bloccare i servizi di applicazioni selezionate in modo che nessuno potesse svegliarle. C'erano anche opzioni più radicali, ad esempio, per demolire tutto il software che usi meno di una volta al giorno.

La stessa Google è intervenuta anche per combattere i servizi "velenosi". Un grande passo in questa direzione è stato compiuto con Android 4.4, che ha introdotto un meccanismo intelligente che determinava se il servizio era in esecuzione troppo a lungo e se richiedeva un uso intensivo della CPU e, in tal caso, lo bloccava e ne impediva l'avvio. Anche ad uno sguardo superficiale, questa versione del sistema viveva con una batteria molto più lunga delle precedenti.

In Android 6.0, Google è andato ancora oltre e lo ha dotato di un meccanismo Sonnecchiare, che dopo un certo tempo di inattività dello smartphone (circa un'ora) lo ha trasferito su un apposito modalità di risparmio energetico. Una delle caratteristiche di questa modalità è il divieto di wakelock, ovvero né le applicazioni né i servizi possono semplicemente svegliare lo smartphone per fare qualsiasi lavoro. A occhio, Android 6.0 non ha vissuto più a lungo, quindi non è noto se questo meccanismo abbia funzionato.

Dozzina la scala di lavoro

E infine, in Android 8.0, Google ha compiuto un passo radicale: ha vietato il lavoro servizi in background. Ma con due eccezioni:

L'applicazione in alcuni casi, ad esempio, quando è sullo schermo, può avviare i servizi, ma Android li ucciderà dopo che l'applicazione va in modalità di sospensione.
I servizi visibili all'utente sono comunque consentiti. Questo cosiddetto servizio in primo piano, un servizio che è visibile nella barra delle notifiche e ha un'icona nella barra di stato.

Sembrerebbe di sì, i servizi sono malvagi, ma che dire di applicazioni come l'antifurto, che dovrebbero funzionare tranquillamente in background? O lo stesso client di posta? A causa della necessità di controllare periodicamente la posta, dovrebbe rimanere bloccata nella barra delle notifiche?

Non proprio. Google si sta muovendo verso il divieto dei servizi dalla versione 5.0, dove il cosiddetto JobScheduler. Questo è un sottosistema speciale che consente alle applicazioni di chiedere ad Android di eseguire questo o quel lavoro in un determinato momento o quando si verifica un tale evento (connessione a Internet, ad esempio). E sì, JobScheduler assomiglia molto a una funzione simile di iOS.

Raccoglitore

Contrariamente alla credenza popolare, Android ha utilizzato sandbox per isolare le applicazioni sin dalle sue prime versioni. E sono stati implementati in un modo molto interessante. Ogni applicazione è stata lanciata per conto di un separato Utente Linux e quindi aveva accesso solo alla propria directory all'interno di /data/data .

Le applicazioni potrebbero comunicare tra loro e con il sistema operativo solo attraverso il meccanismo IPC. Raccoglitore, che richiedeva l'autorizzazione per eseguire un'azione. Lo stesso meccanismo è stato utilizzato per molti altri scopi: con il suo aiuto, il sistema notificava alle applicazioni eventi di sistema, come chiamate in arrivo, SMS in arrivo, addebiti e così via. Le candidature hanno ricevuto messaggi e potrebbero rispondervi.

Binder è alimentato da un driver nel kernel Linux e Service Manager

Questa funzione ha fornito ad Android funzionalità di automazione molto ricche, di cui siamo a conoscenza grazie ad applicazioni come Tasker, Automate o Locale. Tutte queste app sono disponibili anche per Android 8, tranne per il fatto che alcune funzionalità pericolose, come l'abilitazione/disabilitazione della modalità aereo, ora non possono essere utilizzate dalle normali app.

Il sistema di notifica si basa su intenti (intento), uno speciale meccanismo implementato su Binder e progettato per scambiare informazioni tra applicazioni (o sistema operativo e applicazioni), nonché per avviare componenti dell'applicazione. Utilizzando gli intenti, puoi notificare alle applicazioni degli eventi, chiedere al sistema di aprire un'applicazione per elaborare determinati tipi di dati (ad esempio, per aprire pagina specifica nel browser è sufficiente inviare un intento di trasmissione con un collegamento alla pagina e tutte le applicazioni in grado di visualizzare pagine Web risponderanno ad esso, o solo il browser predefinito) o semplicemente avviare un componente di un'applicazione. Ad esempio, le applicazioni in Android non vengono avviate direttamente, ma con l'aiuto degli intenti.

Sfortunatamente, come i servizi, gli intenti sono diventati un problema per gli utenti di Google e Android. Il fatto è che gli intenti di trasmissione utilizzati per notificare alle applicazioni gli eventi arrivano immediatamente a tutte le applicazioni che hanno dichiarato di essere in grado di rispondervi. E affinché l'applicazione possa rispondere all'intento, deve essere avviata. L'immagine è questa: sullo smartphone ci sono venti app in grado di rispondere all'intento android.net.conn.CONNECTIVITY_CHANGE, e ogni volta che ci si connette e si disconnette dalla rete, il sistema avvia queste applicazioni in modo che possano rispondere alle intento. In che modo ciò influisce sul consumo di energia: immagina tu stesso.

Google ha risolto nuovamente questo malinteso in Android 8.0. Le applicazioni ora possono registrare solo gestori di intenti di trasmissione mentre sono in esecuzione (con alcune eccezioni).

Servizi Google

A Google piace ostentare che Android è un sistema operativo open source. Questo, ovviamente, non è del tutto vero. Da un lato, codice Androidè davvero aperto, motivo per cui abbiamo accesso a così tante ROM personalizzate diverse. D'altra parte, costruendo Android da fonti ufficiali, otterrai un sistema senza diversi componenti importanti: 1) singoli driver, la cui fonte il produttore nasconde come segreto commerciale, 2) Servizi Google, necessari prima di tutto per accedere all'account, lanciare Google Play e backup su cloud.

Google Mobile Services è anche responsabile di molte altre cose, incluso il supporto per le notifiche push, le app istantanee, Google Maps, accesso al calendario, localizzazione tramite ripetitori cellulari e router Wi-Fi, meccanismo serratura intelligente, che ti consente di sbloccare il dispositivo in base a determinate condizioni.

V versioni moderne Servizi Android Google si è assunto così tanto lavoro che la vita senza di loro è possibile, ma molto problematica. E non è nemmeno divertente con loro: la versione minima del pacchetto GApps (che contiene solo i servizi Google e Google Play) pesa più di 120 MB e i servizi stessi sono famosi per la loro passione per la RAM e la durata della batteria. E sono chiusi, cioè solo Google stesso sa cosa possono fare.

Scarica il pacchetto con i servizi e App Google per il firmware personalizzato, puoi dal sito opengapps.org (la parola open non significa che siano aperti)

Per questo è nato il progetto microG, il cui compito è ricreare in open source le funzionalità più importanti dei servizi Google. MicroG ti consente già di accedere al tuo account, attivare le notifiche push, accedere a Google Maps e determinare la posizione tramite i ripetitori. E tutto questo con una dimensione di quattro mega e quasi totale assenza requisiti per la RAM e la durata della batteria.

Il progetto ha un proprio assemblaggio del firmware LineageOS, che out of the box include microG e tutte le modifiche necessarie per il suo funzionamento.

kernel Linux e runtime

Android è basato sul kernel Linux. Il kernel gestisce le risorse dello smartphone, incluso l'accesso all'hardware, la gestione della RAM e della memoria permanente, l'avvio, l'arresto e il trasferimento dei processi tra i core del processore e molte altre attività. Come ogni altro OS, il kernel è il cuore di Android, la parte centrale senza la quale tutto il resto andrebbe in pezzi.

Torta a strati Android

La presenza del kernel Linux, oltre ad un ambiente runtime parzialmente compatibile con lo standard POSIX (principalmente una libreria bionica basata sull'implementazione libreria standard C di OpenBSD) rende Android compatibile con le applicazioni Linux. Ad esempio, il sistema di autenticazione wpa_supplicant utilizzato per connettersi alle reti Wi-Fi è esattamente lo stesso qui come in qualsiasi distribuzione Linux. V prime versioni Android utilizzava lo stack bluetooth standard di Linux chiamato bluez (successivamente sostituito dall'implementazione di Qualcomm chiamata Bluedroid). Ha anche una propria console con una serie di comandi UNIX/Linux standard implementati nel set Toybox, originariamente creato per i sistemi Linux embedded.

La maggior parte delle applicazioni console scritte per Linux possono essere trasferite su Android mediante semplice ricompilazione utilizzando un compilatore incrociato (l'importante è utilizzare la compilazione statica per non avere un conflitto di librerie) e avendo i diritti di root, puoi eseguirne uno a tutti gli effetti su un dispositivo Android senza problemi. Un avvertimento: l'accesso può essere ottenuto solo tramite la console o utilizzando una connessione VNC. Esiste anche un progetto Maru OS che ti consente di utilizzare il tuo smartphone come un PC basato su Debian quando connesso a un  monitor. Promette la stessa funzione quando si collega i suoi smartphone al monitor utilizzando il dock DeX.

Il buon vecchio mc in esecuzione su Android

A partire dalla versione 4.4, Android può utilizzare il sistema di controllo degli accessi forzati SELinux per proteggersi dall'hacking e dall'ottenimento diritti di radice. SELinux è sviluppato dalla US National Security Agency e, senza entrare nei dettagli, consente di limitare le capacità delle applicazioni (inclusi i componenti di sistema di basso livello). E non si tratta dei poteri che l'utente concede alle applicazioni, ma di cose come le chiamate di sistema e l'accesso a determinati file, nonostante le autorizzazioni UNIX standard.

Una serie di vulnerabilità Stagefright che hanno colpito Android alcuni anni fa hanno permesso di prendere il controllo del dispositivo semplicemente costringendo l'utente ad aprire un MMS in arrivo o un file speciale nel browser. Il problema era nel framework multimediale Stagefright, che contiene diverse vulnerabilità di overflow del buffer contemporaneamente. Durante l'apertura di un file multimediale appositamente preparato, l'exploit ha utilizzato la vulnerabilità ed ha eseguito il codice sul dispositivo per conto di Stagefright (che veniva eseguito come root).

Google ha risolto con successo tutti questi bug e ha anche lavorato alla modularizzazione del codice del framework e all'esecuzione in domini SELinux speciali. Questi domini impediscono ai componenti di elaborazione multimediale di utilizzare la maggior parte delle chiamate di sistema Linux, comprese le chiamate di sistema execve di gruppo coinvolte nell'esecuzione del codice dannoso.

Oggi SELinux è usato per proteggere quasi tutti componenti del sistema Androide. E questo è stato il motivo di una forte diminuzione del numero di bug riscontrati in Android. Ma ha portato i cracker a concentrarsi sul kernel, o meglio su quei driver molto chiusi, il cui codice non è stato controllato da nessuno e la cui sicurezza non è garantita (e, come si è scoperto, è in uno stato deplorevole).

(1 valutazioni, media: 5,00 su 5)

Come funziona Android. Elettronica indossabile ed elettrodomestici