Comprendere l'architettura della CPU Android (ABI): perché arm64-v8a, armeabi-v7a e x86 sono importanti
Se ti è mai capitato di unire una serie di file APK divisi e di guardare il tuo telefono restituire "App non installata" o, peggio, di vederlo installarsi correttamente solo per bloccarsi nell'istante in cui hai toccato l'icona, c'è una buona possibilità che il vero problema non abbia nulla a che fare con un download danneggiato. Quasi certamente si trattava di architettura: una mancata corrispondenza tra la CPU su cui funziona il telefono e la CPU per cui è stato compilato il codice nativo dell'app. La maggior parte degli utenti Android non deve mai pensarci, fino al momento in cui qualcosa si rompe silenziosamente, e poi diventa rilevante rapidamente. Ecco cosa significa l'architettura della CPU per un APK, perché una singola app sul Play Store viene segretamente distribuita come diverse build di se stessa e come verificare la compatibilità prima di installare qualsiasi cosa.
Cos'è un ABI
ABI sta per Application Binary Interface. In termini pratici, è il set di istruzioni che un chip capisce: il formato di codice macchina grezzo che un processore può eseguire direttamente. La maggior parte di un'app Android, le parti scritte in Java o Kotlin, vengono compilate in bytecode che viene eseguito all'interno di Android Runtime (ART), e ART non si preoccupa particolarmente su quale chip si trova. Questo livello è indipendente dall'architettura in base alla progettazione, il che è una parte importante del motivo per cui le app Android generalmente "funzionano" su una gamma così ampia di hardware.
Il codice nativo è una storia diversa. Molte app, in particolare giochi, app per fotocamera, strumenti di apprendimento automatico e qualsiasi cosa effettui un'elaborazione audio o video pesante, forniscono librerie native scritte in C o C++ tramite Android NDK. Tali librerie vengono compilate in anticipo nel codice macchina per uno specifico set di istruzioni e un chip creato per un set di istruzioni generalmente non può eseguire codice macchina scritto per un altro. Questo è l'unico motivo per cui le ABI esistono come qualcosa che vale la pena comprendere: nel momento in cui un'app include anche una libreria .so nativa, la sua compatibilità diventa legata alle architetture per cui è stata creata la libreria.
Le architetture in cui ti imbatterai
Un tempo c'era più varietà in questo spazio (ricordate il semplice armeabi o MIPS?), ma entro il 2026 il campo si è ristretto a quattro ABI che vale la pena conoscere:
| ABI | Larghezza di bit | Dispositivi tipici | Note |
|---|---|---|---|
| arm64-v8a | BRACCIO a 64 bit | Praticamente tutti i telefoni venduti dal 2019 circa | La destinazione predefinita per le nuove app; Google richiede il supporto a 64 bit per i nuovi invii al Play Store ormai da diversi anni. |
| armeabi-v7a | BRACCIO a 32 bit | Dispositivi più vecchi o economici, alcuni telefoni a basso costo sono ancora venduti nei mercati emergenti | Ancora fornito da molte app per compatibilità con le versioni precedenti, anche se la maggior parte dei dispositivi attivi non ne ha più bisogno. |
| x86 | Intel a 32 bit | Vecchi tablet basati su Intel, emulatori legacy | Per lo più obsoleto; oggi incontrerai raramente un vero telefono x86 a 32 bit. |
| x86_64 | Intel a 64 bit | Alcuni Chromebook, emulatori desktop Android, alcuni tablet x86 | Importante se testi le app in un emulatore come Android Studio AVD basato su x86 o determinate build BlueStacks. |
Se hai in mano un telefono acquistato negli ultimi cinque o sei anni, è quasi certamente arm64-v8a. Le eccezioni che vale la pena ricordare sono gli emulatori e i Chromebook, che spesso funzionano invece su x86_64, poiché corrisponde alla CPU del laptop o desktop sottostante.
Perché le app si preoccupano di spedire più build
Una domanda ovvia è perché gli sviluppatori non si limitano a stipare le librerie native di ogni architettura in un singolo APK e a farla finita. Alcune app fanno esattamente questo e si chiama APK universale o "grasso". Lo svantaggio è la dimensione. Un gioco con librerie native per arm64-v8a, armeabi-v7a, x86 e x86_64 tutte raggruppate insieme può facilmente raddoppiare o triplicare le dimensioni rispetto a una build contenente solo l'architettura necessaria al tuo dispositivo. Moltiplicalo per milioni di installazioni e otterrai una quantità davvero significativa di larghezza di banda e spazio di archiviazione sprecati, per un codice che non verrà mai eseguito su quel dispositivo.
Per evitare questo spreco, Google Play e il formato Android App Bundle dividono un'app in un piccolo APK di base più una serie di APK di configurazione, uno dei quali è dedicato all'architettura. Quando il tuo telefono richiede l'app, Play Store fornisce l'APK di base insieme solo alla suddivisione dell'architettura che corrisponde al tuo chip, insieme alla densità dello schermo e alle suddivisioni linguistiche corrispondenti. Ti ritroverai con un'installazione che si comporta come una singola app ma è assemblata da diversi pezzi appositamente creati dietro le quinte.
Come lo utilizzano gli APK suddivisi e gli app bundle
Se hai mai aperto un pacchetto .apks o .xapk e hai notato nomi di file come split_config.arm64_v8a.apk, split_config.armeabi_v7a.apk, split_config.xxhdpi.apk e split_config.en.apk accanto a uno base.apk, è esattamente questo sistema in azione, semplicemente esportato come un insieme di file invece di essere consegnato silenziosamente dal Play Store. Le divisioni di densità e lingua sono generalmente sicure da installare indiscriminatamente poiché un telefono ignorerà semplicemente le risorse di cui non ha bisogno. La suddivisione dell'architettura è diversa: installa quella sbagliata o non riesci a installare quella corrispondente e ti troverai nei guai seri.
Quando utilizzi un convertitore per unire nuovamente un pacchetto diviso in un singolo APK installabile, il processo di unione deve scegliere quale architettura dividere da incorporare. Un buon convertitore mantiene ogni architettura divisa che è veramente utile o ti consente di scegliere, anziché mantenerne silenziosamente solo una e sperare che corrisponda al tuo dispositivo.
Cosa succede quando l'architettura non corrisponde
Esistono due distinte modalità di errore che vale la pena conoscere a parte, perché appaiono e vengono percepite in modo diverso da un utente normale.
Il primo è un vero e proprio errore di installazione. Se un'app è costruita quasi interamente attorno al codice nativo senza fallback significativo, il gestore dei pacchetti di Android si rifiuterà di installarla, di solito presentando un errore come INSTALL_FAILED_NO_MATCHING_ABIS. Non riuscirai nemmeno ad aprire l'app; l'installatore ti ferma alla porta.
Il secondo risultato, più frustrante, è un silenzioso successo parziale. Se un'app ha un punto di ingresso Java o Kotlin che si carica correttamente da solo, ma poi tenta di richiamare una libreria nativa che semplicemente non è presente per la tua architettura, l'installazione viene completata normalmente. Tutto sembra a posto finché non tocchi l'icona, a quel punto l'app si blocca quasi immediatamente, spesso con uno UnsatisfiedLinkError sepolto nei registri. Questa è la classica storia "L'ho convertito, l'ho installato, poi si chiude all'istante", ed è quasi sempre un problema di architettura piuttosto che un file danneggiato.
Come controllare l'architettura del tuo telefono
Per la stragrande maggioranza delle persone questo è semplice: se il tuo telefono è del 2019 o successivo, assumi arm64-v8a e vai avanti. Se vuoi essere sicuro o hai a che fare con un dispositivo vecchio o insolito, alcune opzioni pratiche:
- Cerca il modello esatto del chipset del tuo telefono (visibile sulla confezione, nel manuale o su un sito come GSMArena) e cerca se quel chipset è ARM a 32 o 64 bit.
- Installa un'app leggera per le informazioni di sistema che segnala direttamente l'architettura della CPU, ne esistono diverse gratuite appositamente per questo scopo.
- Controlla se il telefono è stato fornito con Android 9 o versioni successive come versione del sistema operativo originale; I requisiti a 64 bit di Google di quell'epoca rendono arm64-v8a essenzialmente garantito su tutto ciò che è idoneo.
Come verificare quali architetture supporta un APK
Prima di installare un file esterno al Play Store, vale la pena confermare cosa c'è al suo interno piuttosto che indovinare. Le librerie native di un APK risiedono in cartelle denominate in base alla loro architettura all'interno della directory lib/, come lib/arm64-v8a/ o lib/armeabi-v7a/. Qualsiasi strumento in grado di ispezionare la struttura interna di un APK può dirti esattamente quali di queste cartelle sono presenti, il che ti dice esattamente su quali dispositivi verrà eseguito il file.
Controlla prima di installare
Il nostro Strumento Informazioni APK legge la cartella lib/ interna dell'APK ed elenca tutte le architetture per cui è stato creato, così puoi confermare la compatibilità prima di eseguire il sideload di qualsiasi cosa. Quando converti un pacchetto diviso con il nostro Convertitore da XAPK a APK, lo mostriamo automaticamente anche dopo ogni conversione, elencando le architetture trovate nel file unito e contrassegnandolo quando in una build sembra mancare una sezione di cui avrebbero bisogno i dispositivi comuni.
APK universale e APK ABI singolo: quale dovresti utilizzare?
| Metrica | APK universale/fat | APK ABI singolo |
|---|---|---|
| Dimensioni del file | Più grande, a volte 2-4x | Piccolo, contiene solo ciò di cui il tuo dispositivo ha bisogno |
| Compatibilità | Funziona su quasi tutti i dispositivi | Funziona solo su un'architettura corrispondente |
| Meglio per | Condivisione di un file che dovrebbe funzionare ovunque, destinatari incerti | Il tuo dispositivo, quando ne conosci già l'architettura |
| Rischio | Rischio molto basso di mismatch ABI | Fallirà o si bloccherà se scegli quello sbagliato |
Errori comuni che le persone commettono con i pacchetti suddivisi
- Supponendo che ogni divisione sia facoltativa. Le divisioni di densità e lingua di solito lo sono, ma la divisione dell'architettura non lo è; non saltarlo mai durante un'unione.
- Catturare solo un'architettura divisa da un sito mirror. Se un download di terze parti offre solo, ad esempio, la porzione armeabi-v7a, potrebbe semplicemente fallire su un dispositivo che necessita invece di arm64-v8a, anche se l'app stessa è legittima.
- Dimenticando che tablet e Chromebook non sono sempre ARM. Molti Chromebook che eseguono app Android e alcuni tablet meno recenti sono x86 o x86_64 anziché ARM.
- Test di un APK solo ARM all'interno di un emulatore x86. Alcune build di emulatori meno recenti funzionano su x86 e un APK che fornisce solo librerie native ARM semplicemente non si avvia al loro interno, indipendentemente da come è stato confezionato l'APK.
- Confondere "universale" con "ABI singolo". Un APK universale è intenzionalmente più grande perché include tutto; un APK ABI singolo è piccolo e intenzionalmente limitato a una famiglia di chip.
Punti chiave
- Un ABI è il set di istruzioni che un chip comprende; è importante solo per le app che includono codice nativo (C/C++).
- arm64-v8a copre quasi tutti i telefoni moderni; armeabi-v7a è per dispositivi meno recenti; x86/x86_64 vengono visualizzati principalmente negli emulatori e nei Chromebook.
- Le app sono comunemente suddivise per architettura per evitare di inviare codice nativo non necessario a ogni dispositivo.
- Un'architettura non corrispondente blocca completamente l'installazione o provoca un arresto anomalo immediato dopo un'installazione apparentemente riuscita.
- Puoi controllare sia l'architettura del tuo dispositivo che le architetture supportate da un APK prima di installare qualsiasi cosa, evitando completamente congetture.
Domande Frequenti (FAQ)
Devo conoscere l'architettura del mio telefono per installare una normale app Play Store?
No. Il Play Store rileva automaticamente il tuo dispositivo e fornisce solo la suddivisione dell'architettura corrispondente, quindi questo diventa rilevante solo quando esegui il sideload degli APK dall'esterno del Play Store.
Un APK può supportare più architetture contemporaneamente?
SÌ. Un APK universale o fat raggruppa le librerie native per ogni architettura supportata in un unico file. È più grande ma si installa su qualsiasi dispositivo compatibile indipendentemente dal chip.
Perché il mio APK convertito si è installato ma poi si è bloccato immediatamente?
Questo di solito accade quando l'app ha una piccola quantità di codice Java che si installa correttamente, ma poi tenta di caricare una libreria nativa che non era inclusa per l'architettura del tuo dispositivo, generando un UnsatisfiedLinkError in fase di runtime.
arm64-v8a è retrocompatibile con le app armeabi-v7a?
Generalmente sì. La maggior parte dei chip arm64-v8a può anche eseguire istruzioni ARM a 32 bit, quindi un APK solo armeabi-v7a di solito funzionerà ancora su un moderno telefono arm64, ma non il contrario.
I dispositivi Android x86 sono ancora in circolazione nel 2026?
Sono rari nei telefoni di oggi, ma troverai ancora x86 o x86_64 in alcuni tablet meno recenti basati su Intel, in una manciata di Chromebook che eseguono app Android e nella maggior parte degli emulatori Android desktop.
Non è necessario memorizzare nulla di tutto ciò. La versione breve: i telefoni moderni sono quasi sempre arm64-v8a, le app vengono divise per architettura per risparmiare spazio e se qualcosa si rifiuta di installarsi o si blocca subito dopo l'apertura, la mancata corrispondenza dell'architettura è una delle prime cose che vale la pena escludere prima di presumere che il file stesso sia danneggiato.