Случва ли ви се при опит за модифициране на файла AndroidManifest.xml в Android Studio, просто не можете да го направите? Файлът изглежда ли заключен, неорганизиран или ви дава странни грешки при компилиране? Тази ситуация е по-често срещана, отколкото изглежда, и обикновено се дължи на комбинация от липса на знания за това как сливането на манифести работи в проекти на Android и как те взаимодействат с библиотеки на трети страни, варианти на компилация и атрибути, декларирани във файла. build.gradle.
В тази статия ще ви кажем всичко, което трябва да знаете за това как всъщност работи файлът AndroidManifest.xml, защо не можете да го редактирате в определени контексти, как да го поправите и напълно да овладеете управлението му в Android Studio. Ще откриете, че разбирането на тази тема може да ви спести часове на разочарование и да разкрие повтарящи се грешки, които изглеждат безсмислени.
Какво точно представлява файлът AndroidManifest.xml?
Файлът AndroidManifest.xml е основната конфигурация на приложение за Android. Използва се за деклариране на съществена информация за приложението: от неговите компоненти (дейности, услуги, приемници, доставчици на съдържание) до разрешенията, които изисква, хардуерните функции, от които се нуждае, за да работи, неговата минимална версия на SDK, наред с други важни подробности, които влияят върху инсталирането и работата на приложението на различни устройства.
Трябва да се включи във всички проекти за Android и обикновено се намира в основата на модула на приложението или в модулите на библиотеката, ако има такива. Въпреки че изглежда като един файл, по време на компилация той може да се комбинира с други AndroidManifest.xml файлове от импортирани библиотеки или варианти на компилация. Това е известно като сливане на манифести.
Защо не можете да редактирате манифеста на Android?
Едно от най-честите разочарования на разработчиците е отварянето на файла AndroidManifest.xml в Android Studio и намерете, че:
- Промените не се отразяват след компилирането.
- Някои настройки изглежда се презаписват сами.
- Файлът показва грешки, които не са пряко свързани с написаното.
Това се случва главно защото Android Studio не използва нито един AndroidManifest.xml. Когато създава APK или пакет, Gradle комбинира множество манифестни файлове от различни източници: главния манифест на модула, манифестните файлове за използваните библиотеки и манифестните файлове, дефинирани за варианти на компилация. Така че, когато се опитате да редактирате ръчно видимия файл във вашия основен модул, може да имате работа с атрибути, които автоматично се отменят или дефинират с по-висок приоритет в друг манифест. За повече информация относно редактирането на файлове на Android можете да разгледате тази статия на WhatsApp и управление на файлове.
Как да видите и разберете комбинирания манифест?
Android Studio предлага много полезна функция, за която много потребители не знаят: the комбиниран манифестен изглед. Можете да получите достъп до него, като отворите вашия AndroidManifest.xml файл и след това щракнете върху раздела Комбиниран манифест в долната част на редактора.
Тук ще видите крайния резултат от комбинирането на всички манифестни файлове, съставляващи вашето приложение. Освен това се показват цветове, показващи източника на всеки елемент (независимо дали идва от основния модул, библиотека или вариант на компилация), което е от решаващо значение за разбирането на конфликти или защо някои елементи се появяват „от нищото“.
Този изглед също подчертава грешките при сливане и предоставя препоръки как да ги разрешите. използвайки това, което е известно като маркери за комбинирани правила.
Какво представляват конфликтите при сливане и как да ги разрешим?
Често срещан проблем е, когато два манифеста (например този за главния модул и този за библиотека) дефинират един и същ елемент с различни стойности. Gradle ще се опита да ги обедини, но ако не може, защото има съществени разлики, a грешка в конфликт на атрибути.
Например, ако основният манифест има дейност с атрибута android:screenOrientation="portrait" и библиотека декларира същата дейност, но с "landscape", възниква конфликт. За да го разрешите, Трябва да използвате специални атрибути в манифеста с най-висок приоритет (обикновено вашият), като:
tools:replace="android:screenOrientation"tools:node="replace"
Но първо не забравяйте да декларирате пространството от имена tools във вашия манифест:
Поддържани комбинирани маркери
tools:node="merge": поведение по подразбиране, опитва се да комбинира всичко безопасно.tools:node="replace": замества съдържанието на манифеста с по-нисък приоритет.tools:node="remove": Премахва конкретен елемент от комбинирания манифест (чудесно за импортирани библиотеки).tools:remove="android:theme": премахва конкретен атрибут.tools:replace="android:theme": замества атрибут, дефиниран от библиотека.
Как манифестите се комбинират по приоритет
Редът, в който се комбинират манифестите, е от решаващо значение, тъй като определя кои ценности ще преобладават. Редът на приоритет при сливането е:
- Манифест на вариант на компилация (тип компилация или вкус)
- Основен манифест на приложния модул
- Импортирани библиотечни манифести (сортирани според вида им във файла)
build.gradle)
Това означава, че библиотеките имат по-нисък приоритет и ако ръчно дефинирате нещо в манифеста на приложението си, то ще замени каквото и да е библиотека, освен ако има конфликт и не сте дефинирали как да го разрешите. Освен това, за да избегнете изненади при компилиране, препоръчително е да знаете добре как работят разрешенията, нещо, за което можете да прочетете и в тази статия галерии на Android.
Кога трябва да се декларира? <uses-sdk> в манифеста?
Всъщност не трябва. Ако използвате Android Studio, всички свойства като minSdk o targetSdk трябва да се дефинира изключително във файла build.gradle. Причината е, че при сливане на манифести Gradle игнорира всичко, което сте написали <uses-sdk> и дава приоритет на това, което е конфигурирано в скрипта Gradle.
Как да вмъкнете динамични променливи в AndroidManifest.xml
Понякога трябва да зададете променливи стойности в зависимост от варианта на компилация, като например името на пакета, динамичен хост за филтър за намерения или някаква друга стойност. За това можете да използвате заместители като ${applicationId} или променливи, дефинирани като manifestPlaceholders във вашия build.gradle:
defaultConfig { applicationId "com.example.app" manifestPlaceholders = [ hostName: "myapi.com" ] }
И след това ги използвайте във вашия манифест:
Често срещани грешки, свързани с манифеста
В допълнение към конфликтите при сливане, има типични грешки, които възникват при модифициране на AndroidManifest.xml:
- Класовете не са намерени: Уверете се, че класът, който декларирате като дейност, услуга или приемник, съществува и наследява от съответния тип (
Activity,BroadcastReceiverИ др.) - липса на разрешения: Неправилното деклариране на разрешения може да доведе до неуспешен срив на някои функции. Това е особено важно, ако работите с функции като глас към текст.
- Грешка: „Атрибутът е дефиниран няколко пъти“: Това обикновено се дължи на библиотеки, които дефинират същите атрибути като вас. Използвайте
tools:replaceза да го разреши.
Редактирайте AndroidManifest в App Inventor или във вече генерирани APK файлове
Ако не използвате Android Studio, а инструменти като App Inventor, или имате вече генериран APK файл и искате да промените неговия AndroidManifest.xml, можете да го направите с инструменти като APKTool o AppToMarket. Работният процес се състои от декомпилиране на APK, редактиране на манифеста, повторно компилиране, подписване и подравняване на файла.
Обобщени стъпки:
- Декомпилиране:
apktool d -s archivo.apk - Редактирайте
AndroidManifest.xmlс Notepad++ или друг редактор - Прекомпилиране:
apktool b carpeta fuente -o nuevo.apk - Подпишете с
jarsigner - употреба
zipalignза генериране на крайния APK
Важно: За да публикувате в Google Play, ще трябва да подпишете APK със собствен файл за съхранение на ключове или няма да можете да актуализирате приложението по-късно, ако загубите този файл.
Някои допълнителни съвети за работа с AndroidManifest
- Изрично декларирайте всички важни атрибути, не разчитайте на стойности по подразбиране.
- Избягвайте конфликти, като използвате инструменти: замяна и добавете само необходимите разрешения/minSdk.
- Използвайте комбинирания изглед преди компилиране, това ще ви спести ненужни грешки.
- Ако една библиотека е много проблематична, можете да използвате
tools:node="remove"да почистите това, което не ви трябва.
Ръководството на AndroidManifest.xml Много по-сложно е, отколкото изглежда на пръв поглед. Разбирането как работи сливането на манифести, редът на приоритета и как да се разрешават конфликти с помощта на маркери за правила е от ключово значение за професионалната работа с Android. В допълнение, използването на динамични променливи и инструменти за визуализиране на крайния резултат избягва грешки и загуба на време. Овладяването на тази част от вашия проект може да направи разликата между успешна компилация или загуба на часове за отстраняване на безсмислени грешки.
