AndroidManifest.xml — ce este, componentele principale și configurarea manifestului

Ce este AndroidManifest.xml

AndroidManifest.xml este fișierul principal de configurare în format XML pe care fiecare proiect Android trebuie să îl conțină în directorul app/src/main. Sistemul Android îl analizează înainte de a executa orice cod al aplicației — în etapa de parsare a APK-ului la instalare. Dacă în manifest există o eroare de sintaxă sau lipsește o declarație obligatorie, instalarea este întreruptă cu un mesaj de eroare.

Fișierul conține declarația completă a aplicației: lista tuturor componentelor (Activity, Service, BroadcastReceiver, ContentProvider), permisiunile solicitate, versiunea minimă SDK, cerințele hardware și configurarea temelor și stilurilor. Fiecare componentă care poate fi apelată de sistem sau de alte aplicații trebuie declarată explicit în manifest. Aceasta este o cerință de securitate: fără o declarație explicită, componenta nu este disponibilă pentru apelare.

Fără un manifest configurat corect, aplicația nu poate fi instalată prin Google Play sau sideloading. Sistemul verifică manifestul în etapa de parsare a APK-ului și respinge instalarea în caz de erori. Google Play scanează și manifestul pentru configurații nesigure: pentru exported=true pe o componentă fără intent-filter se emite un avertisment, iar la lipsa permisiunilor obligatorii pentru targetSdk 34+ publicarea este blocată. De aceea, înțelegerea structurii manifestului este o abilitate obligatorie pentru dezvoltatorul Android.

Componentele aplicației în manifest

Fiecare componentă a aplicației Android trebuie să fie înregistrată explicit în manifest. Aceasta este o cerință obligatorie a platformei pentru toate cele patru tipuri de componente. Fără înregistrare, componenta nu poate fi creată de sistem, iar încercarea de a o lansa va duce la o excepție ActivityNotFoundException sau similară. Componentele se înregistrează în interiorul tagului application într-o ordine care nu afectează funcționarea lor.

Activity

Tagul activity înregistrează ecranul aplicației. Atributul exported determină dacă alte aplicații pot lansa această Activity. Începând cu Android 12, absența lui exported în prezența intent-filter cauzează o eroare de compilare — aceasta este o cerință de securitate. Punctul de intrare se stabilește prin intent-filter cu action MAIN și category LAUNCHER. Fiecare Activity trebuie să aibă un nume android:name unic, corespunzător numelui complet sau relativ al clasei.

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:windowSoftInputMode="adjustResize">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Service

Tagul service definește un serviciu de fundal. Începând cu Android 8, serviciile de fundal au restricții stricte: foreground service necesită o notificare obligatorie cu pictogramă vizibilă pentru utilizator, iar bound service trăiește doar când există un client conectat. Serviciile care rulează în fundal fără notificare sunt terminate automat de sistem la câteva minute după ce aplicația trece în modul fundal. Pentru sarcini de lungă durată, utilizați WorkManager în loc de Service.

<service
    android:name=".SyncService"
    android:exported="false"
    android:foregroundServiceType="dataSync" />

BroadcastReceiver

Tagul receiver declară un receptor de mesaje de difuzare sistem sau personalizate. Începând cu Android 8, majoritatea difuzărilor implicite nu mai sunt livrate receptoarelor declarate static în manifest. În schimb, se recomandă înregistrarea receptoarelor dinamic prin Context.registerReceiver în cod. Excepție fac unele difuzări de sistem, cum ar fi BOOT_COMPLETED, care încă necesită înregistrare statică în manifest.

<receiver
    android:name=".ConnectivityReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>

Permisiunile (Permissions) în Android

Fiecare permisiune periculoasă în Android necesită declarare în manifest prin tagul uses-permission. Începând cu Android 6, permisiunile periculoase sunt solicitate în timpul execuției printr-un dialog cu utilizatorul, dar declararea în manifest rămâne obligatorie. Fără ea, metoda requestPermissions aruncă o excepție SecurityException. Permisiunile de nivel normal, cum ar fi INTERNET și ACCESS_NETWORK_STATE, sunt acordate automat la instalare.

Tagul uses-permission-sdk-23 specifică permisiunile necesare doar pe Android 6.0+. Acest lucru permite păstrarea compatibilității cu versiunile vechi fără a solicita permisiuni inexistente. De exemplu, POST_NOTIFICATIONS este disponibil doar pe Android 13+, de aceea trebuie specificat prin uses-permission-sdk-33 pentru ca pe dispozitivele mai vechi să nu apară o eroare de permisiune necunoscută. Atributul maxSdkVersion în uses-permission permite retragerea automată a permisiunilor inutile la actualizarea aplicației pe versiuni noi de Android.

Permisiunile de nivel normal (INTERNET, ACCESS_NETWORK_STATE) sunt acordate automat la instalare și nu necesită solicitare în timpul execuției. Ele se declară și prin uses-permission, dar nu sunt afișate utilizatorului într-un dialog. Pentru controlul accesului la componentele aplicației din alte aplicații se utilizează mecanismul permission-protected components: se poate specifica o permisiune personalizată la nivel de Activity sau Service care va fi verificată de sistem la apelarea componentei din exterior. Acest lucru asigură un nivel suplimentar de securitate pentru comunicarea interproces.

Intent Filters și linkuri profunde

Tagul intent-filter în manifest declară ce intenturi implicite poate gestiona o componentă. Acesta este mecanismul prin care Android leagă acțiunile de sistem sau personalizate de aplicație. Intent filter constă din trei elemente: action (acțiune), category (categorie) și data (date). Toate trei pot fi combinate pentru a descrie precis ce intenturi ar trebui să primească componenta. Sistemul selectează componenta potrivită pe baza celui mai specific filtru.

<activity android:name=".DeepLinkActivity">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="https"
            android:host="itsectr.com"
            android:pathPrefix="/app" />
    </intent-filter>
</activity>

Atributul autoVerify activează verificarea Android App Links: sistemul contactează serverul pentru a confirma proprietatea domeniului. Fără verificare, linkurile profunde funcționează prin dialogul standard de alegere, unde utilizatorul selectează cu ce aplicație să deschidă linkul. După verificarea reușită, linkurile se deschid direct în aplicație fără dialog. Google Search Console folosește și autoVerify pentru indexarea deep link-urilor și afișarea lor în rezultatele căutării.

Filtrele cu action.VIEW și categoriile DEFAULT și BROWSABLE gestionează linkurile din browser, email și alte aplicații. Acesta este mecanismul principal de implementare a linkurilor profunde în Android. Pentru suportarea schemelor URL personalizate, de exemplu myapp://, este suficient să se specifice scheme fără host. Cu toate acestea, Google recomandă utilizarea linkurilor profunde HTTPS în locul schemelor personalizate, deoarece sunt mai sigure și nu necesită permisiuni suplimentare. Schemele personalizate pot fi interceptate de orice aplicație care a înregistrat aceeași schemă.

Atributele aplicației și metadatele

Tagul rădăcină manifest conține atributele pachetului, versiunii și SDK-ului. Tagul application stochează setările globale: tema, pictograma, eticheta și flagurile de depanare. Atributele manifest stabilesc versionarea la nivel de pachet, iar atributele application definesc aspectul și comportamentul general al aplicației. Valorile pot fi referințe la resurse prin sintaxa @ sau literali șir.

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.itsectr.myapp"

    <uses-sdk
        android:minSdkVersion="24"
        android:targetSdkVersion="34" />

    <application
        android:label="MyApp"
        android:icon="@mipmap/ic_launcher"
        android:theme="@style/Theme.MyApp"
        android:supportsRtl="true"
        android:allowBackup="true">
        <!--  Componentele aplicației  -->
    </application>
</manifest>

Tagul meta-data în interiorul application permite stocarea de perechi cheie-valoare arbitrare. Acest lucru este convenabil pentru configurarea bibliotecilor terțe: chei API, adrese endpoint și flaguri de funcționalitate. Datele din meta-data sunt accesibile prin PackageManager.getApplicationInfo().metaData în timpul execuției. De exemplu, Firebase și Google Maps folosesc meta-data pentru a transmite chei de acces fără codificare rigidă în codul sursă. Cheile se stabilesc în manifest și pot diferi pentru diferite variante de compilare.

Atributul android:extractNativeLibs controlează extragerea bibliotecilor native din APK. Pentru aplicațiile cu targetSdk 34+, acest atribut trebuie specificat explicit, altfel compilarea poate eșua cu eroarea INSTALL_FAILED_INVALID_APK. Dacă extractNativeLibs=false, bibliotecile native rămân în interiorul APK-ului fără a fi decompresate, ceea ce reduce dimensiunea aplicației instalate, dar crește timpul de încărcare a bibliotecilor. Pentru majoritatea aplicațiilor moderne, se recomandă extractNativeLibs=false pentru a reduce spațiul ocupat pe discul utilizatorului.

Atributul android:networkSecurityConfig permite specificarea unui fișier de configurare a securității rețelei. Acest lucru este deosebit de important pentru aplicațiile cu targetSdk 28+, unde traficul HTTP este blocat implicit. Fișierul de configurare definește certificatele de încredere, domeniile pentru conexiunile HTTP și regulile de fixare a certificatelor. Acesta înlocuiește atributul învechit android:usesCleartextTraffic și oferă un mecanism mai flexibil de gestionare a securității conexiunilor la nivelul sistemului de operare.

Atributul android:largeHeap solicită o dimensiune mărită a heap-ului pentru aplicație. În mod implicit, Android alocă fiecărei aplicații o cantitate limitată de memorie, dependentă de dispozitiv și versiunea sistemului de operare. Dacă aplicația lucrează cu imagini grele, video sau seturi mari de date, largeHeap poate preveni OutOfMemoryError. Cu toate acestea, abuzul acestui atribut este dăunător: o aplicație cu consum mare de memorie este terminată mai repede de sistem la lipsa resurselor. Utilizați largeHeap doar după profilare și confirmarea necesității.