Розуміння архітектури процесора Android (ABI): Чому arm64-v8a, armeabi-v7a та x86 важливі

Якщо ви коли-небудь об’єднували набір розділених файлів APK і спостерігали, як ваш телефон повідомляє про те, що програма не встановлена, або, що ще гірше, спостерігали, як вона встановлюється нормально, а потім вилітає з ладу, коли ви торкаєтеся значка, є пристойна ймовірність, що справжня проблема не мала нічого спільного з пошкодженим завантаженням. Майже напевно це було пов’язано з архітектурою: невідповідність між ЦП, на якому працює ваш телефон, і ЦП, для якого скомпільовано рідний код програми. Більшості користувачів Android ніколи не доводиться думати про це, аж до моменту, коли він непомітно щось ламає, а потім це швидко стає актуальним. Ось що означає архітектура ЦП для APK, чому один додаток у Play Store таємно постачається як кілька різних збірок і як перевірити сумісність перед тим, як щось інсталювати.

Що таке ABI

ABI означає бінарний інтерфейс програми. З практичної точки зору, це набір інструкцій, який розуміє чіп — формат необробленого машинного коду, який процесор може виконувати безпосередньо. Більшість програм для Android, частини, написані на Java або Kotlin, компілюються в байт-код, який виконується в середовищі виконання Android (ART), і ART особливо не хвилює, на якому чіпі вона знаходиться. Цей рівень не залежить від архітектури, тому програми Android зазвичай «просто працюють» на такому широкому діапазоні обладнання.

Рідний код – це інша історія. Багато додатків, особливо ігор, додатків для камери, інструментів машинного навчання та будь-якого іншого, що виконує важку обробку аудіо чи відео, надсилають рідні бібліотеки, написані на C або C++, через Android NDK. Ці бібліотеки заздалегідь скомпільовані в машинний код для одного конкретного набору інструкцій, і мікросхема, створена для одного набору інструкцій, зазвичай не може виконувати машинний код, написаний для іншого. Це вся причина існування ABI як щось варте розуміння: у той момент, коли програма включає хоча б одну власну бібліотеку .so, її сумісність стає пов’язаною з архітектурою, для якої була створена бібліотека.

Архітектури, на які ви зіткнетеся

Раніше в цьому просторі було більше різноманітності (пам’ятаєте звичайний armeabi або MIPS?), але до 2026 року поле звузилося до чотирьох ABI, про які варто знати:

Якщо ви тримаєте в руках телефон, куплений будь-коли за останні п’ять-шість років, це майже напевно arm64-v8a. Винятками, про які варто пам’ятати, є емулятори та комп’ютери Chromebook, які натомість часто працюють на x86_64, оскільки це відповідає базовому процесору ноутбука чи настільного ПК.

Чому програми взагалі турбуються надсиланням кількох збірок

Одне очевидне питання полягає в тому, чому розробники просто не запихають рідні бібліотеки кожної архітектури в один APK і не покінчать із цим. Деякі програми роблять саме це, і це називається універсальним або «жирним» APK. Недоліком є ​​розмір. Розмір гри з вбудованими бібліотеками для arm64-v8a, armeabi-v7a, x86 і x86_64 може легко подвоїтися або потроїтися порівняно з збіркою, яка містить лише ту архітектуру, яка потрібна вашому пристрою. Помножте це на мільйони встановлень, і ви побачите справді значну кількість марнотратної смуги пропускання та пам’яті для коду, який ніколи не запуститься на цьому пристрої.

Щоб уникнути цього марнотратства, Google Play і формат Android App Bundle розбивають програму на невеликий базовий APK плюс ряд конфігураційних APK, один з яких присвячений архітектурі. Коли ваш телефон запитує програму, Play Store доставляє базовий APK разом із лише розділенням архітектури, яке відповідає вашому чіпу, разом із відповідними розділеннями щільності екрана та мови. У кінцевому підсумку ви отримуєте інсталяцію, яка веде себе як окрема програма, але збирається з кількох спеціально створених частин за лаштунками.

Як розділені APK і пакети додатків використовують це

Якщо ви коли-небудь відкривали пакет .apks або .xapk і помічали назви файлів, як-от split_config.arm64_v8a.apk, split_config.armeabi_v7a.apk, split_config.xxhdpi.apk і split_config.en.apk, розташовані поруч із base.apk, це саме ця система в дії, просто експортована як набір файлів, а не доставлена ​​мовчки Play Store. Розділення за щільністю та мовою зазвичай безпечно встановлювати без розбору, оскільки телефон просто ігноруватиме ресурси, які йому не потрібні. Розподіл архітектури інший: установіть неправильну або не встановіть відповідну, і ви зіткнетеся зі справжніми проблемами.

Коли ви використовуєте конвертер для об’єднання розділеного пакета назад в єдиний інстальований APK, процес злиття має вибрати, які розділи архітектури згорнути. Хороший конвертер зберігає кожне розділення архітектури, яке є справді корисним, або дозволяє вам вибрати, а не мовчки зберігати лише один і сподіватися, що він підходить для вашого пристрою.

Що відбувається, коли архітектура не збігається

Варто розрізняти два різних режими збою, оскільки вони виглядають і відчуваються по-різному для звичайного користувача.

По-перше, повна помилка встановлення. Якщо програму майже повністю побудовано на нативному коді без значущої резервної копії, менеджер пакунків Android взагалі відмовиться встановлювати її, зазвичай виявляючи помилку на зразок INSTALL_FAILED_NO_MATCHING_ABIS. Ви ніколи не зможете навіть відкрити програму; монтажник зупиняє вас біля дверей.

Другий, більш неприємний результат – це мовчазний частковий успіх. Якщо програма має точку входу Java або Kotlin, яка нормально завантажується самостійно, але потім намагається викликати рідну бібліотеку, якої просто немає для вашої архітектури, встановлення завершується нормально. Усе виглядає добре, доки ви не торкнетеся значка, після чого програма майже миттєво аварійно завершує роботу, часто з UnsatisfiedLinkError, похованим у журналах. Це класична історія «Я конвертував його, він встановив, потім він просто миттєво закривається», і це майже завжди проблема архітектури, а не пошкоджений файл.

Як перевірити архітектуру власного телефону

Для переважної більшості людей це просто: якщо ваш телефон випущений у 2019 році чи пізніший, припустіть arm64-v8a та рухайтеся далі. Якщо ви хочете бути впевненими або маєте справу зі старим або незвичайним пристроєм, кілька практичних варіантів:

• Знайдіть точну модель чіпсета свого телефону (вказана на коробці, у посібнику чи на сайті, як-от GSMArena) і знайдіть, чи є цей чіпсет 32-розрядним чи 64-розрядним ARM.
• Встановіть легку програму для системної інформації, яка безпосередньо повідомляє про архітектуру ЦП; для цього існує кілька безкоштовних програм.
• Перевірте, чи телефон постачався з Android 9 або пізнішою версією оригінальної ОС; Вимоги Google до 64-розрядності приблизно тієї епохи роблять arm64-v8a фактично гарантованим для всього, що відповідає вимогам.

Як перевірити, які архітектури підтримує APK

Перш ніж установлювати файл із-за меж Play Store, варто перевірити, що в ньому міститься, а не гадати. Власні бібліотеки APK знаходяться в папках, названих за їхньою архітектурою в каталозі lib/, наприклад lib/arm64-v8a/ або lib/armeabi-v7a/. Будь-який інструмент, який може перевірити внутрішню структуру APK, може точно сказати вам, які з цих папок присутні, що точно скаже вам, на яких пристроях запускатиметься файл.

Універсальний APK проти Single-ABI APK: який краще використовувати?

Поширені помилки, які люди роблять із розділеними пакетами

• Припускаючи, що кожне розділення є необов’язковим. Розділення щільності та мови зазвичай є, але розбиття архітектури – ні; ніколи не пропускайте його під час злиття.
• Захоплення лише однієї архітектури, розділеної з дзеркального сайту. Якщо стороннє завантаження пропонує лише, скажімо, фрагмент armeabi-v7a, воно може просто не працювати на пристрої, якому натомість потрібен arm64-v8a, навіть якщо сама програма є законною.
• Забуваючи, що планшети та Chromebook не завжди є ARM. Багато комп’ютерів Chromebook із програмами Android і деякі старіші планшети працюють на x86 або x86_64, а не на ARM.
• Тестування APK лише для ARM в емуляторі x86. Деякі старіші збірки емулятора працюють на x86, і APK, який постачає лише власні бібліотеки ARM, просто не запускається в них, незалежно від того, як було запаковано APK.
• Плутання "універсального" з "єдиним ABI". Універсальний APK навмисно більший, оскільки він включає все; APK з одним ABI невеликий і навмисно обмежений одним сімейством мікросхем.

Часті запитання (FAQ)

Вам не потрібно запам'ятовувати нічого з цього. Коротка версія: сучасні телефони майже завжди arm64-v8a, програми поділяються за архітектурою для економії місця, і якщо щось відмовляється встановлюватися або виходить з ладу відразу після відкриття, невідповідність архітектури є однією з перших речей, які варто виключити, перш ніж припускати, що сам файл зламаний.