Concetti fondamentali dell'applicazione

Le app per Android possono essere scritte utilizzando Kotlin, il linguaggio di programmazione Java e i linguaggi C++. Gli strumenti SDK Android compilano il tuo codice insieme a tutti i file di dati e risorse in un APK o un Android App Bundle.

Un pacchetto Android, ovvero un file di archivio con suffisso .apk, contiene i contenuti di un'app per Android richiesti in fase di runtime, ed è il file che dispositivi usati per installare l'app.

Un Android App Bundle, ovvero un file di archivio con suffisso .aab, contiene i contenuti di un progetto di app per Android, inclusi alcuni metadati aggiuntivi non richiesti runtime. Un AAB è un formato di pubblicazione e non può essere installato sui dispositivi Android. it Rimanda la generazione e la firma dell'APK a una fase successiva.

Quando distribuisci la tua app tramite Google Ad esempio, i server di Google Play generano APK ottimizzati che contengono solo le risorse e richiesti dal dispositivo che richiede l'installazione dell'app.

Ogni app Android si trova nella propria sandbox per la sicurezza, protetta le seguenti funzionalità di sicurezza di Android:

• Il sistema operativo Android è un sistema Linux multiutente in cui ogni app è un un utente diverso.
• Per impostazione predefinita, il sistema assegna a ogni app un ID utente Linux univoco, utilizzato solo il sistema e non è noto all'app. Il sistema imposta le autorizzazioni per tutti i file in un affinché possa accedervi soltanto l'ID utente assegnato a quell'app.
• Ogni processo ha una propria macchina virtuale (VM), quindi il codice di un'app viene eseguito in modo isolato altre app.
• Per impostazione predefinita, ogni app viene eseguita nel proprio processo Linux. Il sistema Android avvia il processo quando dei componenti dell'app, poi arresta il processo quando non è più o quando il sistema deve recuperare memoria per altre app.

Il sistema Android implementa il principio del privilegio minimo. Vale a dire che ogni app, per impostazione predefinita, ha accesso solo ai componenti necessari per svolgere il proprio lavoro e ora non più. Questo crea un ambiente molto sicuro in cui un'app non può accedere a parti di il sistema per cui non riceve l'autorizzazione.

Tuttavia, un'app può condividere dati con altre app e per un app per accedere ai servizi di sistema:

• È possibile fare in modo che due app condividano lo stesso ID utente Linux, nel qual caso possono accedere reciprocamente ai file. Per risparmiare risorse di sistema, le app con lo stesso ID utente può essere eseguito nello stesso processo Linux e condividere la stessa VM. La le app devono essere firmate con lo stesso certificato.
• Un'app può chiedere l'autorizzazione ad accedere ai dati del dispositivo, ad esempio posizione, fotocamera e connessione Bluetooth. L'utente ha per concedere esplicitamente queste autorizzazioni. Per ulteriori informazioni sulle autorizzazioni, vedi Autorizzazioni su Android.

La parte restante del documento introduce i seguenti concetti:

• I componenti principali del framework che definiscono la tua app.
• Il file manifest in cui dichiari i componenti e il dispositivo richiesto funzionalità per dell'app.
• Risorse separate dal codice dell'app che consentono all'app ottimizzare il comportamento del dispositivo per una serie di configurazioni del dispositivo.

Componenti dell'app

I componenti dell'app sono gli elementi di base essenziali di un'app per Android. Ciascuna è un punto di accesso tramite il quale il sistema o un utente può accedere alla tua app. Alcune dipendono da altri componenti.

Esistono quattro tipi di componenti di un'app:

• Attività
• Servizi
• Broadcast receiver
• Fornitori di contenuti

Ogni tipo ha uno scopo distinto e ha un ciclo di vita distinto che definisce il modo in cui un componente viene creato ed eliminato. Le seguenti sezioni descrivono i quattro tipi di componenti dell'app.

Attività

Un'attività è il punto di accesso per interagire con l'utente. Rappresenta un singolo schermata con un'interfaccia utente. Ad esempio: un'app email potrebbe avere un'attività che mostra un elenco di nuovi email, un'altra attività per scrivere un'email e un'altra attività per la lettura delle email. Sebbene le attività lavorano insieme per creare un'esperienza utente coerente nell'app email, ognuna delle quali è indipendente dalle altre.

Un'altra app può avviare uno qualsiasi di questi attività, se l'app email lo consente. Ad esempio, un'app della fotocamera potrebbe avviare attività nell'app email per scrivere una nuova email e consentire all'utente di condividere una foto.

Un'attività facilita le seguenti interazioni chiave tra il sistema e l'app:

• Il monitoraggio degli interessi dell'utente, ovvero di ciò che c'è sullo schermo, in modo che continua a eseguire il processo che ospita l'attività.
• Sapere quali processi utilizzati in precedenza contengono attività interrotte a cui l'utente potrebbe tornare e dando priorità più elevata a questi processi per mantenerli disponibili.
• Aiutare l'app a gestire l'interruzione del processo in modo che l'utente possa tornare alle attività e ripristinato lo stato precedente.
• Consente alle app di implementare i flussi utente tra loro e al sistema di a coordinare questi flussi. L'esempio principale è la condivisione.

Puoi implementare un'attività come sottoclasse della classe Activity. Per ulteriori informazioni informazioni sul corso Activity, vedi Introduzione alle attività.

Servizi

Un servizio è un punto di ingresso generico che consente di mantenere un'app in esecuzione in background per tutti i motivi. Si tratta di un componente che viene eseguito in background operazioni o operazioni per processi remoti. Un servizio non fornisce un'interfaccia utente.

Per Ad esempio, un servizio potrebbe riprodurre musica in background mentre l'utente usa un'altra app oppure potrebbe recuperare i dati sulla rete senza bloccare l'interazione dell'utente con un'attività. Un altro come un'attività, può avviare il servizio e lasciarlo eseguire o associarlo a interagire con loro.

Esistono due tipi di servizi che indicano al sistema come gestire un'app: servizi avviati e legati ai servizi.

I servizi avviati indicano al sistema di mantenerli in esecuzione fino al termine del lavoro. ad esempio per sincronizzare alcuni dati in background o per riprodurre musica anche dopo che l'utente lascia l'app. La sincronizzazione dei dati in background o la riproduzione di musica rappresentano i diversi tipi di avvio che il sistema gestisce in modo diverso:

• L'utente è direttamente a conoscenza della riproduzione di musica e l'app comunica questo dato il sistema indicando che vuole essere in primo piano, con una notifica per comunicare all'utente che è in esecuzione. In questo caso, il sistema dà la priorità alla conservazione di un processo in esecuzione, in quanto l'utente avrà un'esperienza negativa se scompare.
• L'utente non è direttamente a conoscenza di un normale servizio in background, quindi il sistema ha più libertà di gestire il proprio processo. Potrebbe lasciarlo uccidere il servizio in un secondo momento, se ha bisogno di RAM per servizi che preoccupazione immediata per l'utente.

I servizi associati vengono eseguiti perché un'altra app (o il sistema) ha dichiarato di voler utilizzare completamente gestito di Google Cloud. Un servizio associato fornisce un'API a un altro processo e il sistema sa che c'è una dipendenza tra questi processi. Quindi se il processo A è associato a un servizio processo B, il sistema sa che deve mantenere il processo B e il suo servizio in esecuzione per A. Inoltre, se Il processo A è qualcosa di cui l'utente interessa, quindi sa che deve trattare il processo B come qualcosa interessa anche l'utente.

Grazie alla loro flessibilità, i servizi sono utili per tutti i concetti di sistema a livello superiore. Sfondi animati, notifiche listener, salvaschermo, metodi di immissione, servizi di accessibilità e molte altre funzionalità di base del sistema sono tutti creati come servizi implementati dalle applicazioni e a cui il sistema si vincola quando vengono eseguite.

Un servizio viene implementato come sottoclasse di Service. Per ulteriori informazioni sulla classe Service, consulta le Panoramica dei servizi.

Nota: se la tua app ha come target Android 5.0 (livello API 21) o versioni successive, usa la classe JobScheduler per programmare azioni. JobScheduler ha il vantaggio di risparmiare batteria grazie alla pianificazione ottimale dei job per ridurre il consumo energetico e lavorando con l'API Doze. Per ulteriori informazioni sull'utilizzo di questo corso, consulta JobScheduler documentazione di riferimento.

Ricevitori di trasmissioni

Un ricevitore di trasmissione è un componente che consente al sistema di inviare eventi al di fuori di un normale flusso utente, in modo che possa rispondere a trasmissioni a livello di sistema annunci. Poiché i broadcast receiver sono un altro modo ben definito per accedere all'app, il sistema può trasmettere annunci anche alle app che non sono attualmente in esecuzione.

Ad esempio, un'app può pianificare una sveglia per pubblicare una notifica e informare l'utente di un evento imminente. Poiché l'allarme viene inviato a un BroadcastReceiver nell'app, non è necessario che l'app rimangono in funzione fino a quando non scatta la sveglia.

Molte trasmissioni provengono dal sistema, ad esempio una trasmissione che annuncia che lo schermo è spento, la batteria è in esaurimento o è stata acquisita una foto. Le app possono anche avviare trasmissioni, ad esempio per far sapere ad altre app che alcuni dati vengono scaricati sul dispositivo e diventano disponibili per l'uso.

Sebbene la trasmissione i destinatari non visualizzano un'interfaccia utente, possono creare una notifica nella barra di stato per avvisare l'utente quando si verifica un evento di trasmissione. Più comunemente, però, un broadcast receiver è solo un gateway ad altri componenti e deve occuparsi di una mole di lavoro minima.

Ad esempio, un broadcast receiver potrebbe programmare un JobService per eseguire alcune attività basate in un evento utilizzando JobScheduler. I broadcast receiver spesso implicano l'interazione tra le app, quindi è importante conoscere e implicazioni per la sicurezza durante la loro configurazione.

Un broadcast receiver viene implementato come una sottoclasse di BroadcastReceiver, e ogni trasmissione viene pubblicata come oggetto Intent. Per ulteriori informazioni, vedi il corso BroadcastReceiver.

Fornitori di contenuti

Un fornitore di contenuti gestisce un set condiviso di dati dell'app che puoi archiviare nel file system, in un database SQLite, sul web o su qualsiasi altra risorsa la posizione a cui può accedere l'app. Tramite il fornitore di contenuti, altre app possono eseguire query o modificare i dati, se il fornitore di contenuti lo consente.

Ad esempio, il sistema Android fornisce contenuti che gestisce le informazioni di contatto dell'utente. Qualsiasi app con autorizzazioni possono interrogare il fornitore di contenuti, ad esempio utilizzando ContactsContract.Data, per leggere e scrivere informazioni su di una determinata persona.

Si potrebbe avere la tentazione di pensare a un fornitore di contenuti come a un'astrazione di un database, perché molte API e molte risorse di supporto integrate per questo caso comune. Tuttavia, hanno un diverso scopo principale dal punto di vista della progettazione del sistema.

Per il sistema, un fornitore di contenuti è un punto di ingresso in un'app per la pubblicazione di elementi di dati denominati, identificati da uno schema URI. Di conseguenza, un'app può decidere come mappare i dati che contiene a un URI, distribuendo questi URI ad altre entità che possono a loro volta utilizzarli per accedere e i dati di Google Cloud. Questo sistema consente al sistema di gestire un'app per alcuni aspetti specifici:

• L'assegnazione di un URI non richiede che l'app rimanga in esecuzione, quindi gli URI possono essere mantenuti dopo la loro le app proprietarie. Il sistema deve solo assicurarsi che un'app proprietaria è ancora in esecuzione quando recupera i dati dell'app dall'URI corrispondente.
• Questi URI forniscono inoltre un importante modello di sicurezza granulare. Ad esempio, un l'app può inserire l'URI di un'immagine presente negli appunti, ma lasciarne i contenuti provider bloccato in modo che altre app non possano accedervi liberamente. Quando una seconda app tenta per accedere all'URI negli appunti, il sistema può consentire all'app accedere ai dati utilizzando una concessione di autorizzazione URI temporanea in modo che acceda ai dati solo dietro quell'URI e a nient'altro nella seconda app.

I fornitori di contenuti sono utili anche per leggere e scrivere dati privati e non condividerli.

Un fornitore di contenuti è implementato come sottoclasse di ContentProvider e implementare un set standard di API che consentano ad altre app di eseguire transazioni. Per ulteriori informazioni, consulta lo sviluppatore dei fornitori di contenuti guida.

Un aspetto unico del design del sistema Android è che qualsiasi app può avviarne un'altra dell'app. Ad esempio, se vuoi che l'utente acquisisca con la fotocamera del dispositivo, probabilmente esiste un'altra app in grado di farlo... l'app può usarla invece di sviluppare un'attività per scattare una foto personalmente. Non devi non è necessario incorporare o addirittura collegare il codice dall'app della fotocamera. Puoi però avviare l'attività nell'app Fotocamera che acquisisce un foto. Al termine dell'operazione, la foto viene persino restituita all'app per consentirti di utilizzarla. All'utente, sembra che la videocamera faccia 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 per le classi necessarie per il componente. Ad esempio, se avvia l'attività nell'app Fotocamera che scatta una foto, tale attività viene eseguito durante il processo che appartiene all'app Fotocamera, non in quello dell'app. Pertanto, a differenza delle app installate sulla maggior parte degli altri sistemi, le app per Android non hanno una singola voce punto: non è presente alcuna funzione main().

Poiché il sistema esegue ogni app in un processo separato con permessi dei file che limitare l'accesso ad altre app, l'app non può attivare direttamente un componente da un'altra app. Tuttavia, il sistema Android può farlo. Per attivare un componente in in un'altra app, trasmetti al sistema un messaggio che specifica il tuo intent avviare un particolare componente. Il sistema attiva automaticamente il componente.

Attiva componenti

Un messaggio asincrono, chiamato intent, attiva tre dei quattro tipi di componenti: attività, servizi e i broadcast receivers. Gli intent associano tra loro i singoli componenti durante il runtime. Puoi pensare a queste funzionalità come messaggi che richiedono un'azione da altri componenti, se il componente appartiene alla tua app o a un'altra.

Viene creato un intent con un oggetto Intent, che definisce un messaggio da attivare un componente specifico (un intent esplicito) o un tipo specifico di componente (un intent implicito).

Per attività e servizi, un intent definisce l'azione da eseguire, ad esempio view o inviare qualcosa e specificare l'URI dei dati su cui agire, tra le altre cose che potrebbe essere necessario conoscere.

Ad esempio, un'intenzione può comunicare la richiesta di attività per mostrare un'immagine o aprire una pagina web. In alcuni casi, puoi avviare una l'attività per ricevere un risultato, nel qual caso l'attività restituisce anche il risultato in un Intent. Puoi anche inviare un intent per l'utente sceglie un contatto personale e te lo restituisce. L'intent di reso include URI che punta al contatto scelto.

Per i broadcast receiver, l'intent definisce la annuncio. Ad esempio, un annuncio per indicare che la batteria del dispositivo è in esaurimento. Include solo una stringa di azione nota che indica la batteria è in esaurimento.

Diversamente dalle attività, dai servizi e dai broadcast receiver, i fornitori di contenuti attivata quando il target è una richiesta da un ContentResolver. I contenuti resolver gestisce tutte le transazioni dirette con il fornitore di contenuti e il componente di eseguire transazioni con il provider chiama i metodi ContentResolver oggetto. Ciò lascia un livello di astrazione per motivi di sicurezza tra fornitore di contenuti e il componente che richiede le informazioni.

Esistono metodi diversi per attivare ogni tipo di componente:

• Puoi iniziare un'attività o assegnarle qualcosa di nuovo passare Intent a startActivity() oppure, se vuoi che l'attività restituisca un risultato, startActivityForResult().
• Su Android 5.0 (livello API 21) e versioni successive, puoi utilizzare la classe JobScheduler per programmare le azioni. Per le versioni precedenti di Android, puoi iniziare un servizio o dare nuove istruzioni a un servizio in corso passando Intent a startService(). Puoi eseguire l'associazione al servizio passando un valore Intent a bindService().
• Puoi avviare una trasmissione passando un Intent a metodi come sendBroadcast() o sendOrderedBroadcast().
• Puoi eseguire una query per un fornitore di contenuti chiamando query() su un ContentResolver.

Per ulteriori informazioni sull'uso degli intent, consulta la sezione Intent e Documento Filtri di intent. I seguenti documenti forniscono ulteriori informazioni sull'attivazione di componenti specifici: Introduzione alle attività. Panoramica dei servizi, BroadcastReceiver e Fornitori di contenuti.

Il file manifest

Prima che il sistema Android possa avviare un componente dell'app, deve sapere che esiste leggendo il file manifest dell'app, AndroidManifest.xml. La tua app dichiara tutti i suoi componenti in questo file, che è alla base del della directory del progetto dell'app.

Il file manifest esegue varie operazioni oltre alla dichiarazione dei componenti dell'app. ad esempio:

• Identifica le autorizzazioni utente richieste dall'app, come l'accesso a internet o accesso in lettura ai contatti dell'utente.
• Dichiara il minimo Livello API richieste dall'app, in base alle API utilizzate dall'app.
• Dichiara le funzionalità hardware e software usate o richieste dall'app, ad esempio una videocamera, servizi Bluetooth o uno schermo multi-touch.
• Dichiara le librerie API con cui deve essere collegata l'app (diverse dal framework Android) API), come nella libreria di Google Maps.

Dichiara i componenti

L'attività principale del file manifest è informare il sistema dei componenti dell'app. Per Ad esempio, un file manifest può dichiarare un'attività come segue:

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

In <application> , l'attributo android:icon rimanda alle risorse per trovare un'icona che identifica dell'app.

Nell'elemento <activity>, l'attributo android:name specifica il nome completo della classe del Activity e la classe L'attributo android:label specifica una stringa da utilizzare come etichetta visibile all'utente per l'attività.

Devi dichiarare tutti i componenti dell'app utilizzando i seguenti elementi:

• <activity> elemento per le attività
• <service> elementi per servizi
• <receiver> elemento per broadcast receiver
• <provider> elemento per i fornitori di contenuti

Attività, servizi e fornitori di contenuti che includi nella fonte ma che non dichiari nel file manifest non sono visibili al sistema e, di conseguenza, non possono essere eseguiti. Tuttavia, trasmettere i destinatari possono essere dichiarati nel manifest o creati dinamicamente nel codice BroadcastReceiver e registrati nel sistema richiamando registerReceiver().

Per ulteriori informazioni su come strutturare il file manifest per la tua app, consulta la Panoramica sul file manifest dell'app.

Dichiara le funzionalità dei componenti

Come spiegato nella sezione Attiva componenti, puoi utilizzare un'opzione Intent per avviare attività, servizi e broadcast receiver. Sei tu a fare assegnando un nome esplicito al componente di destinazione, utilizzando il nome della classe del componente nell'intent. Puoi anche utilizzare un intent implicito, descrive il tipo di azione da eseguire e, facoltativamente, i dati che vuoi eseguire l'azione. Un intent implicito consente al sistema di trovare un componente sul dispositivo in grado di eseguire e avviare l'azione. Se sono presenti più componenti che possono eseguire l'azione descritta dal l'intenzione, l'utente sceglie quale utilizzare.

Attenzione: se utilizzi un intent per avviare una Service, assicurati che la tua app sia sicura usando un esplicita l'intento. L'utilizzo di un intent implicito per avviare un servizio è un rischio per la sicurezza, perché non è possibile avere la certezza di quale servizio risponda all'intento e l'utente non può vedere quale servizio viene avviato. A partire da Android 5.0 (livello API 21), il sistema genera un'eccezione se chiami bindService() con un intento implicito. Non dichiarare i filtri per intent per i tuoi servizi.

Il sistema identifica i componenti che possono rispondere a un intento confrontando il intent ricevuto ai filtri di intent forniti nel file manifest di altre app su del dispositivo.

Quando dichiari un'attività nel file manifest dell'app, puoi facoltativamente includere filtri per intent che dichiarano le capacità dell'attività in modo che possa rispondere agli intent da altre app. Per farlo devi aggiungendo un elemento <intent-filter> come elemento secondario dell'elemento dichiarazione del componente.

Ad esempio, se crei un'app email con un'attività per scrivere una nuova email, puoi dichiarare un filtro di intent per rispondere a "invio" di inviare una nuova email, come mostrato nell'esempio seguente:

<manifest ... >
    ...
    <application ... >
        <activity android:name="com.example.project.ComposeEmailActivity">
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <data android:type="*/*" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
    </application>
</manifest>

Se un'altra app crea un intent con l'azione ACTION_SEND e lo passa a startActivity(), il sistema potrebbe iniziare la tua attività in modo che l'utente possa creare una bozza e inviare una email.

Per saperne di più sulla creazione di filtri per intent, consulta il documento Intent e filtri per intent.

Dichiara i requisiti dell'app

Esistono diversi dispositivi con tecnologia Android e non tutti offrono la le stesse caratteristiche e capacità. Impedire l'installazione dell'app sui dispositivi che non hanno le funzionalità necessarie all'app, è importante definire chiaramente un profilo i tipi di dispositivi supportati dalla tua app dichiarando i requisiti del dispositivo e del software nella manifest.

La maggior parte di queste dichiarazioni è solo a scopo informativo. Il sistema non legge ma i servizi esterni come Google Play li leggono per fornire filtri per gli utenti quando cercano app dal loro dispositivo.

Ad esempio, supponiamo che la tua app richieda una fotocamera e utilizzi API introdotte in Android 8.0 (livello API 26). Devi dichiarare questi requisiti. I valori per minSdkVersion e targetSdkVersion sono impostati in file build.gradle del modulo dell'app:

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 26
    targetSdkVersion 29
  }
}

Nota: non impostare minSdkVersion e targetSdkVersion direttamente nel file manifest, poiché vengono sovrascritte da Gradle durante il processo di creazione. Per ulteriori informazioni, vedi Specifica i requisiti relativi ai livelli API.

Dichiari la funzionalità della videocamera nel file manifest dell'app:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    ...
</manifest>

Con le dichiarazioni mostrate in questi esempi, i dispositivi che non dispongono di un videocamera o dispone di Con una versione di Android inferiore alla 8.0 non è possibile installare l'app da Google Play. Tuttavia, puoi anche dichiarare che la tua app utilizza la videocamera, ma non lo richiedono. Per farlo, devi impostare la required attributo a false, controlla in fase di runtime se il dispositivo dispone di una videocamera e, se necessario, disattivare tutte le funzionalità della videocamera.

Ulteriori informazioni su come gestire la compatibilità della tua app con diversi dispositivi Nella pagina Panoramica della compatibilità dei dispositivi.

Risorse app

Un'app per Android non è composta solo da codice. Richiede risorse che, separate dal codice sorgente, come immagini, file audio e qualsiasi altro contenuto relativo al presentazione dell'app. Ad esempio, puoi definire animazioni, menu, stili, colori e il layout delle interfacce utente delle attività con i file XML.

L'uso delle risorse delle app semplifica per aggiornare varie caratteristiche dell'app senza modificare il codice. Fornitura di risorse alternative consente di ottimizzare l'app per una vasta gamma di configurazioni dei dispositivi, ad esempio lingue e dimensioni dello schermo diverse.

Per ogni risorsa che includi nel tuo progetto Android, gli strumenti di creazione dell'SDK definiscono un ID intero, che puoi usare per fare riferimento alla risorsa dal codice dell'app o ad altre risorse definite in XML. Ad esempio, se l'app contiene un file immagine denominato logo.png (salvato nella directory res/drawable/), gli strumenti SDK generano un ID risorsa denominato R.drawable.logo. Questo ID viene mappato a un numero intero specifico dell'app, che che puoi utilizzare per fare riferimento all'immagine e inserirla nell'interfaccia utente.

Uno degli aspetti più importanti della fornitura di risorse separate dal codice sorgente è la capacità di fornire risorse alternative per dispositivi diversi configurazioni.

Ad esempio, definendo stringhe UI in XML, puoi le stringhe in altre lingue diverse e salvarle in file separati. Quindi Android applica le stringhe del linguaggio appropriato alla tua UI in base a un qualificatore lingua che aggiungi al nome della directory della risorsa, ad esempio res/values-fr/ per la stringa in francese e l'impostazione della lingua dell'utente.

Android supporta molti qualificatori per le tue risorse alternative. La il qualificatore è una breve stringa che includi nel nome delle directory delle risorse definiscono la configurazione del dispositivo per cui vengono utilizzate queste risorse.

Per Ad esempio, puoi creare layout diversi per le tue attività a seconda orientamento e dimensioni dello schermo del dispositivo. Quando lo schermo del dispositivo è in verticale (alto) orientamento, puoi scegliere un layout con i pulsanti disposti in verticale, ma quando lo schermo è con orientamento orizzontale (wide), puoi scegliere di allineare i pulsanti orizzontalmente. Per modificare il layout a seconda dell'orientamento, puoi definire due layout e applicare al nome della directory di ogni layout. Quindi, il sistema applica automaticamente layout in base all'orientamento corrente del dispositivo.

Per ulteriori informazioni sui diversi tipi di risorse che puoi includere nella tua applicazione e su come Per creare risorse alternative per le diverse configurazioni dei dispositivi, leggi la panoramica delle risorse per le app. A scopri di più sulle best practice e sulla progettazione di app affidabili e di qualità per la produzione, consulta la Guida all'architettura delle app.

Risorse aggiuntive

Per imparare a sviluppare Android con i video e i tutorial sul codice, consulta la Sviluppare app Android con Kotlin corso Udacity.

Continua a leggere su:

Filtri per intent e intent

Scopri come utilizzare le API Intent per attivare componenti dell'app, come attività e servizi, e come rendere i componenti dell'app disponibili per altre app.

Introduzione alle attività

Scopri come creare un'istanza della classe Activity, che offre una schermata distinta nell'applicazione con un'interfaccia utente.

Panoramica delle risorse per app

Scopri come le app per Android sono strutturate in modo da separare le risorse per app dal il codice dell'app, incluso il modo in cui fornire risorse alternative per un dispositivo specifico configurazioni.

Inoltre, ti interessano:

Panoramica della compatibilità dei dispositivi

Scopri come funziona Android su diversi tipi di dispositivi e come ottimizzare l'app per ogni dispositivo o limitarne la disponibilità su dispositivi diversi.

Autorizzazioni su Android

Scopri in che modo Android limita l'accesso delle app a determinate API con un'autorizzazione che richiede il consenso dell'utente affinché la tua app utilizzi queste API.