Le applicazioni Android possono essere scritte utilizzando i linguaggi Kotlin, Java e C ++.
L’ android SDK compila il codice insieme a tutti i file di dati e risorse in un pacchetto che non è altro che un un file di archivio con un suffisso .APK
Un file APK contiene quindi tutte le cartelle ei file di un’applicazione Android ed è il file che i dispositivi Android utilizzano per installare l’app.
Ogni app Android risiede in una propria “scatola” protetta dalle seguenti funzionalità di Android:
- Il sistema operativo Android è un sistema Linux multi-utente in cui ogni app è un utente diverso.
- Per impostazione predefinita, il sistema Linux assegna a ciascuna app un ID utente univoco (l’ID viene utilizzato solo dal sistema ed è sconosciuto all’app). Il sistema imposta le autorizzazioni per tutti i file in un’app in modo che solo l’ID utente assegnato a quell’app possa accedervi.
- Ogni processo ha la propria macchina virtuale (VM), quindi il codice di un’app viene eseguito in maniera isolata dalle altre app.
- Per impostazione predefinita, ogni app viene eseguita nel proprio processo Linux. Il sistema Android avvia il processo quando è necessario eseguire una funzionalità qualsiasi dell’app, quindi arresta il processo quando non è più necessario o quando il sistema deve ripristinare la memoria per altre app.
Il sistema Android implementa il principio del privilegio minimo . Cioè, ogni app, per impostazione predefinita, ha accesso solo ai componenti di cui ha bisogno per svolgere il suo lavoro e non di più. Ciò crea un ambiente molto sicuro in cui un’app non può accedere a parti del sistema per le quali non è stata concessa l’autorizzazione. Tuttavia, ci sono modi in cui un’app può condividere dati con altre app e per accedere ai servizi di sistema:
- È possibile fare in modo che due app condividano lo stesso ID utente Linux, in quel caso sono in grado di accedere ai file l’una dell’altra. Per conservare le risorse di sistema, le app con lo stesso ID utente possono anche organizzarsi per essere eseguite nello stesso processo Linux e condividere la stessa VM. Anche le app devono essere firmate con lo stesso certificato.
- Un’app può richiedere l’autorizzazione per accedere ai dati del dispositivo come la posizione del dispositivo, la fotocamera e la connessione Bluetooth. L’utente deve concedere esplicitamente queste autorizzazioni.
Componenti dell’app
I componenti dell’app sono gli elementi costitutivi essenziali di un’app Android. Ogni componente è un punto di ingresso attraverso il quale il sistema o un utente può accedere alla tua app. Alcuni componenti dipendono da altri componenti.
Esistono quattro diversi tipi di componenti in un app android:
- Activities
- Services
- Broadcast receivers
- Content providers
Ogni tipo ha uno scopo distinto e ha un ciclo di vita distinto che definisce il modo in cui il componente viene creato e distrutto. Le sezioni seguenti descrivono i quattro tipi di componenti dell’app.
Activities
Un’activities è il punto di ingresso per l’interazione con l’utente. Rappresenta una singola schermata con un’interfaccia utente. Ad esempio, un’app di posta elettronica potrebbe avere un’attività che mostra un elenco di nuovi messaggi di posta elettronica, un’altra attività per editare un messaggio di posta elettronica e un’altra attività per leggere i messaggi di posta elettronica. Sebbene le activities lavorino insieme per formare un’esperienza utente coerente nell’app di posta elettronica, ognuna è indipendente dalle altre. Pertanto, un’app diversa può avviare una qualsiasi di queste activities se l’app di posta elettronica lo consente. Ad esempio, un’app della fotocamera può avviare l’ activities nell’app di posta elettronica che compone la nuova posta per consentire all’utente di condividere un’immagine. Un activities facilita le seguenti interazioni chiave tra sistema e app:
- Tenere traccia di ciò che attualmente interessa all’utente (ciò che è sullo schermo) per garantire che il sistema continui a eseguire il processo che ospita l’ activities.
- Sapendo che i processi utilizzati in precedenza contengono cose a cui l’utente può ritornare (attività interrotte), e quindi dare più priorità a mantenere quei processi attivi.
- Aiutare l’app a gestire l’arresto del processo in modo che l’utente possa tornare alle activities con il ripristino dello stato precedente.
- Fornire alle app un modo per implementare flussi di utenti e per consentire al sistema di coordinare questi flussi. (L’esempio più classico è la condivisione.)
Services
Un services è un punto di ingresso generico per mantenere un’app in esecuzione in background per tutti i piu’ svariati motivi. È un componente che viene eseguito in background per operazioni di lunga durata o per eseguire lavori per processi remoti. Un service non fornisce un’interfaccia utente. Ad esempio, un service potrebbe riprodurre musica in sottofondo mentre l’utente si trova in un’app diversa oppure potrebbe recuperare dati sulla rete senza bloccare l’interazione dell’utente con un’activitie. Un altro componente, come un’activitie, può avviare il service e o collegarsi ad esso per interagirvi. In realtà ci sono due services distinti che dicono al sistema come gestire un’app: I servizi avviati dicono al sistema di mantenerli in esecuzione fino al completamento del lavoro. Potrebbe essere per sincronizzare alcuni dati in background o riprodurre musica anche dopo che l’utente ha lasciato l’app. La sincronizzazione dei dati in background o la riproduzione di musica rappresentano anche due diversi tipi di servizi che modificano il modo in cui il sistema li gestisce:
- La riproduzione musicale è qualcosa di cui l’utente è direttamente a conoscenza, quindi l’app dice al sistema che vuole essere in primo piano con una notifica per informarne l’utente; in questo caso il sistema sa che dovrebbe sforzarsi di mantenere in esecuzione il processo di quel servizio, perché l’utente non sarà contento se viene chiuso.
- Un normale servizio in background non è qualcosa che l’utente è a conoscenza del fatto che è in esecuzione, quindi il sistema ha più libertà nella gestione del suo processo. Può consentire che venga chiuso (e quindi riavviato in un secondo momento) se ha bisogno di RAM per cose che sono di più immediato interesse per l’utente.
I servizi associati vengono eseguiti perché un’altra app (o il sistema) ha chiesto di voler utilizzare il servizio. Questo è fondamentalmente il servizio che fornisce un’API a un altro processo. Il sistema quindi sa che esiste una dipendenza tra questi processi, quindi se il processo A è associato a un servizio nel processo B, sa che deve mantenere il processo B (e il suo servizio) in esecuzione per A. Inoltre, se il processo A è un qualcosa a cui l’utente è interessato, quindi sa di trattare il processo B come qualcosa a cui l’utente tiene. A causa della loro flessibilità (nel bene e nel male), i servizi si sono rivelati un elemento fondamentale per tutti i tipi di concetti di sistema di livello superiore. Sfondi animati, ascoltatori di notifiche, salvaschermo, metodi di immissione, servizi di accessibilità,
Brodcast receivers
Un brodcast receiver è un componente che consente al sistema di fornire eventi all’app al di fuori di un normale flusso utente, consentendo all’app di rispondere ai broadcast revcevivers a livello di sistema. Poiché i brodcast receivers sono un’altra voce ben definita nell’app, il sistema può fornire trasmissioni anche ad app che non sono attualmente in esecuzione. Quindi, ad esempio, un’app può programmare un allarme per pubblicare una notifica per informare l’utente di un evento imminente … e consegnando quell’allarme a un BroadcastReceiver dell’app, non è necessario che l’app rimanga in esecuzione fino a quando l’allarme finisce. Molte trasmissioni provengono dal sistema, ad esempio una trasmissione che annuncia che lo schermo si è spento, la batteria è scarica o è stata acquisita un’immagine. Le app possono anche avviare trasmissioni, ad esempio per far sapere ad altre app che alcuni dati sono stati scaricati sul dispositivo e che possono essere utilizzati. Sebbene i broaddcast receivers non visualizzino un’interfaccia utente, potrebbero creare una notifica sulla barra di stato per avvisare l’utente quando si verifica un evento di trasmissione. Più comunemente, tuttavia, un broadcast receiver è solo un gateway per altri componenti ed è progettato per svolgere una quantità minima di lavoro.
Content provviders
Un provider di contenuti gestisce un set condiviso di dati dell’app che puoi archiviare nel file system, in un database SQLite, sul Web o in qualsiasi altro percorso di archiviazione persistente a cui l’app può accedere. Tramite il provider di contenuti, altre app possono eseguire query o modificare i dati se il provider di contenuti lo consente. Ad esempio, il sistema Android fornisce un content provviders che gestisce le informazioni di contatto dell’utente. Pertanto, qualsiasi app con le autorizzazioni appropriate può interrogare il fornitore di contenuti per leggere e scrivere informazioni su una determinata persona. Si è tentati di pensare a un fornitore di contenuti come un’astrazione di un database, perché ci sono molte API e supporto. Tuttavia, hanno uno scopo principale diverso dal punto di vista della progettazione del sistema. Per il sistema, un provider di contenuti è un punto di ingresso in un’app per la pubblicazione di elementi di dati denominati, identificati da uno schema URI. Pertanto un’app può decidere come mappare i dati che contiene a uno spazio dei nomi URI, distribuendo tali URI ad altre entità che possono a loro volta utilizzarli per accedere ai dati. Ci sono alcune cose particolari che consente di fare al sistema nella gestione di un’app:
- L’assegnazione di un URI non richiede che l’app rimanga in esecuzione, quindi gli URI possono persistere dopo la chiusura delle appa. Il sistema deve solo assicurarsi che un’app proprietaria sia ancora in esecuzione quando deve recuperare i dati dell’app dall’URI corrispondente.
- Questi URI forniscono anche un importante modello di sicurezza granulare. Ad esempio, un’app può posizionare l’URI di un’immagine che ha negli appunti, ma lasciare bloccato il provider di contenuti in modo che altre app non possano accedervi liberamente. Quando una seconda app tenta di accedere a quell’URI negli appunti, il sistema può consentire a quell’app di accedere ai dati tramite una concessione di autorizzazione URI temporanea in modo che possa accedere ai dati solo dietro quell’URI, ma a nient’altro nella seconda app .
I fornitori di contenuti sono utili anche per leggere e scrivere dati privati della tua app e non condivisi.
Un aspetto unico del design del sistema Android è che qualsiasi app può avviare il componente di un’altra app. Ad esempio, se desideri che l’utente scatti una foto con la fotocamera del dispositivo, probabilmente c’è un’altra app che lo fa e la tua app può utilizzarla invece di sviluppare un’attività per acquisire una foto da solo. Non è necessario incorporare o addirittura collegare il codice dall’app della fotocamera. Invece, puoi semplicemente avviare l’attività nell’app della fotocamera che cattura una foto. Al termine, la foto viene persino restituita alla tua app in modo da poterla utilizzare. All’utente sembra che la fotocamera faccia effettivamente parte della tua app.
Quando il sistema avvia un componente, avvia il processo per quell’app se non è già in esecuzione e crea un’istanza delle classi necessarie per il componente. Ad esempio, se la tua app avvia l’attività nell’app della fotocamera che cattura una foto, tale attività viene eseguita nel processo che appartiene all’app della fotocamera, non nel processo dell’app. Pertanto, a differenza delle app sulla maggior parte degli altri sistemi, le app Android non hanno un unico punto di ingresso.
Poiché il sistema esegue ciascuna app in un processo separato con autorizzazioni di file che limitano l’accesso ad altre app, l’app non può attivare direttamente un componente da un’altra app. Il sistema Android invece può.
Per attivare un componente in un’altra app, invia un messaggio al sistema che specifica l’intenzione di avviare un particolare componente. Il sistema quindi attiverà il componente per te.