Какая папка содержит файлы ресурсов приложения

Обновлено: 05.07.2024

Иногда некоторые приложения на Android чем-то не устраивают пользователя. В качестве примера можно привести назойливую рекламу. А то бывает и так — всем хороша программа, да только перевод в ней или кривой, или вовсе отсутствует. Или, например, программа триальная, а получить полную версию возможности нет. Как же изменить ситуацию?

Введение

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

Чтобы сделать все это самостоятельно, потребуются хотя бы начальные знания языка Java, на котором пишутся приложения для Android, и языка XML, который используется в Android повсеместно — от описания самого приложения и его прав доступа до хранения строк, которые будут выведены на экран. Также понадобится умение обращаться со специализированным консольным софтом.

Итак, что же представляет собой пакет APK, в котором распространяется абсолютно весь софт для Android?

Декомпиляция приложений

В статье мы работали только с дизассемблированным кодом приложения, однако если в большие приложения вносить более серьезные изменения, разобраться в коде smali будет гораздо сложнее. К счастью, мы можем декомпилировать код dex в Java-код, который будет хоть и не оригинальным и не компилируемым обратно, но гораздо более легким для чтения и понимания логики работы приложения. Чтобы сделать это, нам понадобятся два инструмента:

Использовать их следует так. Сначала запускаем dex2jar, указывая в качестве аргумента путь до apk-пакета:

В результате в текущем каталоге появится Java-пакет mail.jar, который уже можно открыть в jd-gui для просмотра Java-кода.

Устройство APK-пакетов и их получение

Пакет приложения Android, по сути, является обычным ZIP-файлом, для просмотра содержимого и распаковки которого никаких специальных инструментов не требуется. Достаточно иметь архиватор — 7zip для Windows или консольный unzip в Linux. Но это что касается обертки. А что внутри? Внутри же у нас в общем случае такая структура:

META-INF/ — содержит цифровой сертификат приложения, удостоверяющий его создателя, и контрольные суммы файлов пакета;
res/ — различные ресурсы, которые приложение использует в своей работе, например изображения, декларативное описание интерфейса, а также другие данные;
AndroidManifest.xml — описание приложения. Сюда входит, например, список требуемых разрешений, требуемая версия Android и необходимое разрешение экрана;
classes.dex — компилированный байт-код приложения для виртуальной машины Dalvik;
resources.arsc — тоже ресурсы, но другого рода — в частности, строки (да-да, этот файл можно использовать для русификации!).

Перечисленные файлы и каталоги есть если не во всех, то, пожалуй, в абсолютном большинстве APK. Однако стоит упомянуть еще несколько не столь распространенных файлов/каталогов:

assets — аналог ресурсов. Основное отличие — для доступа к ресурсу необходимо знать его идентификатор, список asset’ов же можно получать динамически, используя метод AssetManager.list() в коде приложения;
lib — нативные Linux-библиотеки, написанные с помощью NDK (Native Development Kit).

Этот каталог используют производители игр, помещая туда движок игры, написанный на C/C++, а также создатели высокопроизводительных приложений (например, Google Chrome). С устройством разобрались. Но как же получить сам файл пакета интересующего приложения? Поскольку без рута с устройства забрать файлы APK не представляется возможным (они лежат в каталоге /data/app), а рутить не всегда целесообразно, имеется как минимум три способа получить файл приложения на компьютер:

расширение APK Downloader для Chrome;
приложение Real APK Leecher;
различные файлообменники и варезники.

Какой из них использовать — дело вкуса; мы предпочитаем использовать отдельные приложения, поэтому опишем использование Real APK Leecher, тем более что написан он на Java и, соответственно, работать будет хоть в винде, хоть в никсах.

Настройка Real APK Leecher

Просмотр и модификация

Допустим, ты нашел интересующий тебя пакет, скачал, распаковал… и при попытке просмотра какого-нибудь XML-файла с удивлением обнаружил, что файл не текстовый. Чем же его декомпилировать и как вообще работать с пакетами? Неужели необходимо ставить SDK? Нет, SDK ставить вовсе не обязательно. На самом деле для всех шагов по распаковке, модификации и упаковке пакетов APK нужны следующие инструменты:

Использовать все эти инструменты можно и по отдельности, но это неудобно, поэтому лучше воспользоваться более высокоуровневым софтом, построенным на их основе. Если ты работаешь в Linux или Mac OS X, то тут есть инструмент под названием apktool. Он позволяет распаковывать ресурсы в оригинальный вид (в том числе бинарные XML- и arsc-файлы), пересобирать пакет с измененными ресурсами, но не умеет подписывать пакеты, так что запускать утилиту signer придется вручную. Несмотря на то что утилита написана на Java, ее установка достаточно нестандартна. Сначала следует получить сам jar-файл:

Далее нам понадобится скрипт-обвязка для запуска apktool (он, кстати, доступен и для Windows), включающий в себя еще и утилиту aapt, которая понадобится для запаковки пакета:

Далее просто сваливаем содержимое обоих архивов в каталог

/bin и добавляем его в $PATH:

Если же ты работаешь в Windows, то для нее есть превосходный инструмент под названиемVirtuous Ten Studio, который также аккумулирует в себе все эти инструменты (включая сам apktool), но вместо CLI-интерфейса предоставляет пользователю интуитивно понятный графический интерфейс, с помощью которого можно выполнять операции по распаковке, дизассемблированию и декомпиляции в несколько кликов. Инструмент этот Donation-ware, то есть иногда появляются окошки с предложением получить лицензию, но это, в конце концов, можно и потерпеть. Описывать его не имеет никакого смысла, потому что разобраться в интерфейсе можно за несколько минут. А вот apktool, вследствие его консольной природы, следует обсудить подробнее.

Импорт APK в Virtuous Ten Studio

Рассмотрим опции apktool. Если вкратце, то имеются три основные команды: d (decode), b (build) и if (install framework). Если с первыми двумя командами все понятно, то что делает третья, условный оператор? Она распаковывает указанный UI-фреймворк, который необходим в тех случаях, когда ты препарируешь какой-либо системный пакет.

Рассмотрим наиболее интересные опции первой команды:

-s — не дизассемблировать файлы dex;
-r — не распаковывать ресурсы;
-b — не вставлять отладочную информацию в результаты дизассемблирования файла dex;
--frame-path — использовать указанный UI-фреймворк вместо встроенного в apktool. Теперь рассмотрим пару опций для команды b:
-f — форсированная сборка без проверки изменений;
-a — указываем путь к aapt (средство для сборки APK-архива), если ты по какой-то причине хочешь использовать его из другого источника.

Пользоваться apktool очень просто, для этого достаточно указать одну из команд и путь до APK, например:

После этого в каталоге mail появятся все извлеченные и дизассемблированные файлы пакета.

Препарирование. Отключаем рекламу

Теория — это, конечно, хорошо, но зачем она нужна, если мы не знаем, что делать с распакованным пакетом? Попробуем применить теорию с пользой для себя, а именно модифицируем какую-нибудь софтину так, чтобы она не показывала нам рекламу. Для примера пусть это будет Virtual Torch — виртуальный факел. Для нас эта софтина подойдет идеально, потому что она под завязку набита раздражающей рекламой и к тому же достаточно проста, чтобы не потеряться в дебрях кода.

Поиск кода рекламы в jd-gui

Итак, с помощью одного из приведенных способов скачай приложение из маркета. Если ты решил использовать Virtuous Ten Studio, просто открой APK-файл в приложении и распакуй его, для чего создай проект (File -> New project), затем в контекстном меню проекта выбери Import File. Если же твой выбор пал на apktool, то достаточно выполнить одну команду:

После этого в каталоге com.kauf.particle.virtualtorch появится файловое дерево, похожее на описанное в предыдущем разделе, но с дополнительным каталогом smali вместо dex-файлов и файлом apktool.yml. Первый содержит дизассемблированный код исполняемого dex-файла приложения, второй — служебную информацию, необходимую apktool для сборки пакета обратно.

Первое место, куда мы должны заглянуть, — это, конечно же, AndroidManifest.xml. И здесь мы сразу встречаем следующую строку:

Нетрудно догадаться, что она отвечает за предоставление приложению полномочий на использование интернет-соединения. По сути, если мы хотим просто избавиться от рекламы, нам, скорее всего, достаточно будет запретить приложению интернет. Попытаемся это сделать. Удаляем указанную строку и пробуем собрать софтину с помощью apktool:

В каталоге com.kauf.particle.virtualtorch/build/ появится результирующий APK-файл. Однако установить его не получится, так как он не имеет цифровой подписи и контрольных сумм файлов (в нем просто нет каталога META-INF/). Мы должны подписать пакет с помощью утилиты apk-signer. Запустили. Интерфейс состоит из двух вкладок — на первой (Key Generator) создаем ключи, на второй (APK Signer) подписываем. Чтобы создать наш приватный ключ, заполняем следующие поля:

Target File — выходной файл хранилища ключей; в нем обычно хранится одна пара ключей;
Password и Confirm — пароль для хранилища;
Alias — имя ключа в хранилище;
Alias password и Confirm — пароль секретного ключа;
Validity — срок действия (в годах). Значение по умолчанию оптимально.

Остальные поля, в общем-то, необязательны — но необходимо заполнить хотя бы одно.

Создание ключа в apk-signer

WARNING

Чтобы подписать приложение с помощью apk-signer, ты должен установить Android SDK и указать полный путь до него в настройках приложения.

Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

Теперь этим ключом можно подписать APK. На вкладке APK Signer выбираем только что сгенерированный файл, вводим пароль, алиас ключа и пароль к нему, затем находим файл APK и смело жмем кнопку «Sign». Если все пройдет нормально, пакет будет подписан.

Так как мы подписали пакет нашим собственным ключом, он будет конфликтовать с оригинальным приложением, а это значит, что при попытке обновить софтину через маркет мы получим ошибку.

Цифровая подпись необходима только стороннему софту, поэтому если ты занимаешься модификацией системных приложений, которые устанавливаются копированием в каталог /system/app/, то подписывать их не нужно.

Обычно авторы приложений создают специальные классы для вывода рекламы и вызывают методы этих классов во время запуска приложения или одной из его «активностей» (упрощенно говоря, экранов приложения). Попробуем найти эти классы. Идем в каталог smali, далее com (в org лежит только открытая графическая библиотека cocos2d), далее kauf (именно туда, потому что это имя разработчика и там лежит весь его код) — и вот он, каталог marketing. Внутри находим кучу файлов с расширением smali. Это классы, и наиболее примечателен из них класс Ad.smali, по названию которого нетрудно догадаться, что именно он выводит рекламу.

Мы могли бы изменить логику его работы, но гораздо проще будет тупо убрать вызовы любых его методов из самого приложения. Поэтому выходим из каталога marketing и идем в соседний каталог particle, а затем в virtualtorch. Особого внимания здесь заслуживает файл MainActivity.smali. Это стандартный для Android класс, который создается Android SDK и устанавливается в качестве точки входа в приложение (аналог функции main в Си). Открываем файл на редактирование.

Внутри находится код smali (местный ассемблер). Он довольно запутанный и трудный для чтения в силу своей низкоуровневой природы, поэтому мы не будем его изучать, а просто найдем все упоминания класса Ad в коде и закомментируем их. Вбиваем строку «Ad» в поиске и попадаем на строку 25:

Здесь происходит создание объекта. Комментируем. Продолжаем поиск и находим в строках 433, 435, 466, 468, 738, 740, 800 и 802 обращения к методам класса Ad. Комментируем. Вроде все. Сохраняем. Теперь пакет необходимо собрать обратно и проверить его работоспособность и наличие рекламы. Для чистоты эксперимента возвращаем удаленную из AndroidManifest.xml строку, собираем пакет, подписываем и устанавливаем.

Наш подопытный кролик. Видна реклама Он же, но уже без рекламы

Оп-па! Реклама пропала только во время работы приложения, но осталась в главном меню, которое мы видим, когда запускаем софтину. Так, подождите, но ведь точка входа — это класс MainActivity, а реклама пропала во время работы приложения, но осталась в главном меню, значит, точка входа другая? Чтобы выявить истинную точку входа, вновь открываем файл AndroidManifest.xml. И да, в нем есть следующие строки:

Они говорят нам (и, что важнее, андроиду) о том, что активность с именем Start должна быть запущена в ответ на генерацию интента (события) android.intent.action.MAIN из категории android.intent.category.LAUNCHER. Это событие генерируется при тапе на иконку приложения в ланчере, поэтому оно и определяет точку входа, а именно класс Start. Скорее всего, программист сначала написал приложение без главного меню, точкой входа в которое был стандартный класс MainActivity, а затем добавил новое окно (активность), содержащее меню и описанное в классе Start, и вручную сделал его точкой входа.

Открываем файл Start.smali и вновь ищем строку «Ad», находим в строках 153 и 155 упоминание класса FirstAd. Он тоже есть в исходниках и, судя по названию, как раз и отвечает за показ объявлений на главном экране. Смотрим дальше, идет создание экземпляра класса FirstAd и интента, по контексту имеющего отношение к этому экземпляру, а дальше метка cond_10, условный переход на которую осуществляется аккурат перед созданием экземпляра класса:

Скорее всего, программа каким-то случайном образом вычисляет, нужно ли показывать рекламу на главном экране, и, если нет, перескакивает сразу на cond_10. Ок, упростим ей задачу и заменим условный переход на безусловный:

Больше упоминаний FirstAd в коде нет, поэтому закрываем файл и вновь собираем наш виртуальный факел с помощью apktool. Копируем на смартфон, устанавливаем, запускаем. Вуаля, вся реклама исчезла, с чем нас всех и поздравляем.

Перевод приложений Android;
пример снятия триала с приложения.

Итоги

Эта статья лишь краткое введение в методы вскрытия и модификации Android-приложений. За кадром остались многие вопросы, такие как снятие защиты, разбор обфусцированного кода, перевод и замена ресурсов приложения, а также модификация приложений, написанных с использованием Android NDK. Однако, имея базовые знания, разобраться во всем этом — лишь вопрос времени.

Ресурс в приложении Android представляет собой файл, например, файл разметки интерфейса или некоторое значение, например, простую строку. То есть ресурсы представляют собой и файлы разметки, и отдельные строки, и звуковые файлы, файлы изображений и т.д. Все ресурсы находятся в проекте в каталоге res . Для различных типов ресурсов, определенных в проекте, в каталоге res создаются подкаталоги. Поддерживаемые подкаталоги:

animator/ : xml-файлы, определяющие анимацию свойств

anim/ : xml-файлы, определяющие tween-анимацию

color/ : xml-файлы, определяющие список цветов

drawable/ : Графические файлы ( .jpg , .jpg , .jpg )

mipmap/ : Графические файлы, используемые для иконок приложения под различные разрешения экранов

layout/ : xml-файлы, определяющие пользовательский интерфейс приложения

menu/ : xml-файлы, определяющие меню приложения

raw/ : различные файлы, которые сохраняются в исходном виде

values/ : xml-файлы, которые содержат различные используемые в приложении значения, например, ресурсы строк

xml/ : Произвольные xml-файлы

font/ : файлы с определениями шрифтом и расширениями .ttf, .otf или .ttc, либо файлы XML, который содержат элемент <font-family>

В общей сложности мы можем определить следующие типы ресурсов:

элемент в файле

strings.xml или arrays.xml

Логические значения Boolean

Массив целых чисел

Файлы с расширением jpg и png

Файл xml с произвольным названием

Файл xml с произвольным названием

Бинарные и текстовые ресурсы

Файлы мультимедиа (mp3, mp4), текстовые и другие файлы

Разметка графического интерфейса

Файл xml с произвольным названием

К примеру, если мы возьмем стандартный проект Android Studio, который создается по умолчанию, то там можем заметить наличие уже нескольких папок для различных ресурсов в каталоге res :

По умолчанию здесь есть каталоги не для всех типов ресурсов, которые использоваться в Android, однако при необходимости мы можем добавить в папку res нужный каталог, а в него затем поместить ресурс.

Когда происходит компиляция проекта сведения обо всех ресурсах добавляются в специальный файл R.jar , который затем используется при работе с ресурсами

Применение ресурсов

Существует два способа доступа к ресурсам: в файле исходного кода и в файле xml.

Ссылка на ресурсы в коде

Тип ресурса в данной записи ссылается на одно из пространств (вложенных классов), определенных в файле R.java, которые имеют соответствующие им типы в xml:

R.drawable (ему соответствует тип в xml drawable )

Например, для установки ресурса activity_main.xml в качестве графического интерфейса в коде MainActivity в методе onCreate() есть такая строка:

Через выражение R.layout.activity_main мы и ссылаемся на ресурс activity_main.xml, где layout - тип ресурса, а activity_main - имя ресурса.

Подобным образом мы можем получать другие ресурсы. Например, в файле res/values/strings.xml определен ресурс app_name:

Этот ресурс ссылается на строку. Чтобы получить ссылку на данный ресурс в коде java, мы можем использовать выражение R.string.app_name .

Доступ в файле xml

Нередко возникает необходимость ссылаться на ресурс в файле xml, например, в файле, который определяет визуальный интерфейс, к примеру, в activity_main.xml. Ссылки на ресурсы в файлах xml имеют следующую формализованную форму: @[имя_пакета:]тип_ресурса/имя_ресурса

имя_пакета представляет имя пакета, в котором ресурс находится (указывать необязательно, если ресурс находится в том же пакете)

тип_ресурса представляет подкласс, определенный в классе R для типа ресурса

имя_ресурса имя файла ресурса без расширения или значение атрибута android:name в XML-элементе (для простых значений).

Например, мы хотим вывести в элемент TextView строку, которая определена в виде ресурса в файле strings.xml:

В данном случае свойство text в качестве значения будет получать значение строкового ресурса app_name.

Метод getResources

Для получения ресурсов в классе Activity мы можем использовать метод getResources() , который возвращает объект android.content.res.Resources . Но чтобы получить сам ресурс, нам надо у полученного объекта Resources вызвать один из методов. Некоторые из его методов:

getString() : возвращает строку из файла strings.xml по числовому идентификатору

getDimension() : возвращает числовое значение - ресурс dimen

getDrawable() : возвращает графический файл в виде объекта Drawable

getBoolean() : возвращает значение boolean

getColor() : возвращает определение цвета

getColorStateList() : возвращает объект ColorStateList - набор цветов

getFont() : возвращает определение шрифта в виде объекта Typeface

getFloat() : возвращает значение float

getLayout() : возвращает объект XmlResourceParser, связанный с файлом layout

Это только некоторые методы. Но все они в качестве параметра принимают идентификатор ресурса, который надо получить. Вкратце рассмотрим их применение. Возьмем тот же файл res/values/strings.xml в качестве источника ресурсов, который в моем случае выглядит так:

И изменим код MainActivity:

Здесь, используя метод getResources() получаем все ресурсы и затем используем их для устаноки значений свойств графических элементов. При запуске приложения мы увидим применение полученных ресурсов:

Подобным образом мы можем программно получать и другие ресурсы и использоват их в приложении. Однако следует отметить, что в данном случае нам не нужно использовать метод getResources() и вообще производить какие-то определенные действия по получению ресурса, поскольку метод setText() класса TextView поддерживает прямую установку текста по идентификатору ресурса:

В этом уроке мы с вами узнаем, зачем в Android системе используются ресурсы и какими они бывают.

Ресурсы из папки res/values

В данном уроке мы познакомимся только с ресурсами, которые находятся в папке res : строки, цвета, стили, размеры. Полную информацию о ресурсах мы будем проходить в следующем модуле, но если вы хотите ознакомиться сейчас, то вы можете посмотреть на сайте официальной документации.

Для начала откроем наш проект и в верхнем левом углу поменяем отображение проекта с Android на Project . Это позволит нам увидеть все папки, которые реально созданы в нашем проекте:

Вот как выглядит наш проект. Нажмём на папку values и посмотрим, что в ней находится:

Видим три файла:

Хранение таких данных в отдельных ресурсах дает нам гибкость и удобство при работе с проектом. Мы рассмотрим преимущества на примере локализации строковых ресурсов.

Локализация

Мы будем поддерживать два языка в нашем приложении: английский и русский. Для локализации приложения используют файл strings.xml . Туда помещается весь текст вашего приложения, который должен быть подвержен локализации. Чтобы добавить поддержку ещё одного языка, надо создать папку с именем values-language . Т.к. мы поддерживаем русский язык, то создадим папку values-ru .

Для этого нажмём правой кнопкой на папку res и выберем пункт New -> Android resource directory :

При создании директории у нас появится окно, в котором надо заполнить поля следующими значениями:

Вот как это должно выглядеть:

После этого видим, что у нас создалась папка values-ru . Отлично, создадим новый файл strings.xml . Для этого нажимаем правой кнопкой по папке values-ru , выбираем New -> Values resource file :

Затем появится окно, в котором необходимо ввести имя файла. Вводим strings . И у нас создался файл, иконка которого выглядит в виде флага России.

Для начала давайте посмотрим как выглядит обычный строковый ресурс:

У каждого строкового ресурса есть имя, по которому в дальнейшем будет идти обращение к нему, а также его значение. На самом деле так выглядят не только строковые ресурсы, а все ресурсы приложения:

Просто вместо типа ресурса string используются другие необходимые значения ( color , dimen и т.д.).

Теперь проверим, что это всё действительно работает. Добавим строку в файл values/strings.xml :

Теперь добавим строку в файл values-ru/strings.xml :

Видим, что название ресурсов followers_hint , following_hint совпадает в двух папках. А вот значения мы можем указывать для каждого языка свои.

Стоит отметить, что помимо ручного заполнения файлов с ресурсами, существует возможность делать это через специальный редактор. Чтобы в него попасть необходимо, открыв файл со строковыми ресурсами (любого языка), в правом верхнем углу нажать кнопку «Open editor» (рус. открыть редактор):

Теперь, когда мы научились добавлять ресурсы, давайте в файле activity_user_info.xml с нашей разметкой у элемента followers_text_view заменим напрямую написанный текст на только что созданный строковый ресурс android:text="@string/followers_hint" , а у элемента following_text_view укажем атрибут android:text="@string/following_hint" .

Так выглядит синтаксис при ссылке на файл ресурса. Необходимо вначале добавить @ , потом название файла, потом имя ресурса. Наши элементы followers_text_view , following_text_view теперь выглядят таким образом.

Запустим наше приложение и убедимся, что наша локализация действительно работает.

После запуска приложения на нашем эмуляторе Nexus 5X API 27 , видим, что вывелись строки Following , Followers , т.к. на эмуляторе стоит английский язык.

Давайте добавим русский язык и сделаем его основным.

Можем открыть наше приложение на эмуляторе или запустить его заново. Результат выглядит так:

В этом уроке мы добавим ресурсы, которые понадобятся нам в дальнейшем, чтобы потом не тратить на это время. В обычном проекте ресурсы добавляются динамически в процессе написания кода, но для учебной цели мы сейчас добавим большую часть ресурсов, которые нам понадобятся в дальнейших уроках.

Наш файл res/values/strings.xml должен выглядеть так:

Также добавим все цвета, которые нам понадобятся для нашего приложения. Наш файл res/values/colors.xml должен выглядеть так:

AndroidManifest

Сердцем любого Android приложения является файл AndroidManifest . Он находится в корневой папке каждого приложения и содержит важную информацию о приложении, которая требуется системе Android . Только получив эту информацию, система может выполнить какой-либо код приложения. Также манифест содержит:

Описание компонентов приложения, из которых состоит приложение. Он содержит имена классов, которые реализуют каждый компонент, и публикует их возможности На основании этих деклараций система Android может определить, из каких компонентов состоит приложение и при каких условиях их можно запускать.
Разрешения, которые должны быть выданы приложению, чтобы оно могло получить доступ к защищенным частям API-интерфейса и взаимодействовать с другими приложениями.

Подробнее ознакомиться с функциями манифеста можно в официальной документации или в данном видеоуроке.

Корневой каталог каждого приложения под Android должен содержать файл AndroidManifest. xml (в точности с таким названием). Манифест приложения содержит всю необходимую информацию, используемую системой для запуска и выполнения приложения. Основная информация , содержащаяся в манифесте:

В файле манифеста только два элемента: <manifest> и <application> являются обязательными и при этом встречаются ровно по одному разу. Остальные элементы могут встречаться несколько раз или не появляться совсем, в этом случае манифест определяет пустое приложение .

Следующий листинг демонстрирует общую структуру файла манифеста.

В манифесте элементы одного уровня, такие как <activity> , <service> , <receiver> , <provider> , могут следовать друг за другом в любой последовательности. Элемент <activity-alias> является исключением из этого правила, он должен следовать за соответствующей активностью.

Более предметно разговор о файле манифеста и его основных элементах пойдет в лабораторных работах.

3.6 Ресурсы

При разработке мобильных приложений необходимо выработать привычку отделять ресурсы приложения от кода. К ресурсам приложения могут относиться: изображения, строки, цвета, компоновки элементов пользовательского интерфейса ( layout ) и т. д. Отделение ресурсов от кода позволяет использовать альтернативные ресурсы для различных конфигураций устройств: язык, разрешение экрана и т. д. Для обеспечения совместимости с различными конфигурациями, ресурсы необходимо сгруппировать в директории по типу ресурсов и конфигурации устройства, полученные директории поместить в папку res/.

Для любого типа ресурсов можно определить две группы. Первая определяет ресурсы, которые будут использоваться независимо от конфигурации устройства или в том случае, когда под конфигурацию нет подходящих альтернативных ресурсов. Эта группа называется ресурсы по умолчанию ( default ). Вторая группа определяет ресурсы, подходящие для определенной конфигурации устройства, размещается в директории с названием, обозначающим данную конфигурацию. Такие ресурсы называются альтернативными.


а) используется компоновка по умолчанию (приложение не содержит альтернативы)	б) каждое устройство использует соответствующую компоновку
Рис. 3.6. Использование ресурсов

Каждый тип ресурсов необходимо размещать в специальной поддиректории папки res/. Рассмотрим основные из этих поддиректорий:

Следует отметить, что файлы ресурсов нельзя размещать в папку res/ напрямую, они обязательно должны размещаться в соответствующем каталоге, иначе будет выдана ошибка компиляции.

Все ресурсы, которые содержатся в рассмотренных поддиректориях являются ресурсами по умолчанию. Понятно, что различные типы устройств могут требовать различных типов ресурсов. Например, для устройств с разными размерами экрана компоновки элементов пользовательского интерфейса должны отличаться. Рис 3.6 показывает варианты внешнего вида приложения с использованием только компоновки по умолчанию (а) и с использованием альтернативных компоновок (б). Даже на схеме понятно, что при правильном подходе приложение , изменяющее свой внешний вид в зависимости от размера экрана привлекательнее, чем остающееся неизменным.

Чтобы определить зависимые от конфигурации альтернативы для множества ресурсов:

Например, если компоновка элементов пользовательского интерфейса сохранена, как ресурс по умолчанию, в папке res/layout/, можно (скорее даже нужно) определить альтернативную компоновку элементов пользовательского интерфейса, соответствующую горизонтальной (альбомной) ориентации экрана смартфона и сохранить ее в папке res/layout-land/. Android автоматически определит подходящую компоновку, сверяя текущее состояние устройства с именами папок в каталоге /res.

Все ресурсы после определения могут быть доступны по ссылке на их ID , которые определены в автоматически генерируемом классе R . Для каждого типа ресурсов в R классе существует подкласс , например, R.drawable для всех графических ресурсов. ID ресурса всегда имеет две составляющие:

тип ресурса - все ресурсы группируются по типам, например, string, drawable, layout;
имя ресурса - либо имя файла без расширения, либо значение атрибута android:name в XML файле для простого значения.

Получить доступ к ресурсу можно двумя способами:

в коде: можно использовать выражения вида R.тип_ресурса.имя_ресурса, например, R.string.hello ;
в XML: используется специальный XML синтаксис, который соответствует ID определенному в R классе, например, @string/hello .

Более предметно разговор об использовании ресурсов в лабораторных работах.

Читайте также: