Android заменить ресурс приложения
Альтернативные ресурсы — это ресурсы, предназначенные для определенного устройства или настройки времени выполнения, такие как текущий язык, определенный размер экрана или плотность пикселей. Если Android может сопоставить ресурс, который более специфичен для конкретного устройства или конфигурации, чем ресурс по умолчанию, то вместо него будет использоваться этот ресурс. Если другой ресурс, совпадающий с текущей конфигурацией, не найден, будут загружены ресурсы по умолчанию. Как Android решает, какие ресурсы будут использоваться приложением, будет более подробно рассмотрено ниже в разделе расположение ресурса.
Альтернативные ресурсы организованы в виде вложенного каталога в папке resources в соответствии с типом ресурса, как и ресурсы по умолчанию. Имя подкаталога альтернативных ресурсов имеет вид: - квалификатор типа ресурса.
Квалификатор — это имя, идентифицирующее определенную конфигурацию устройства. В имени может быть несколько квалификаторов, каждое из которых отделяется дефисом. Например, на следующем снимке экрана показан простой проект с дополнительными ресурсами для различных конфигураций, таких как языковой стандарт, плотность экрана, размер экрана и ориентация:
При добавлении квалификаторов к типу ресурса применяются следующие правила.
Может существовать несколько квалификаторов, каждый из которых отделяется дефисом.
Квалификаторы могут быть указаны только один раз.
Квалификаторы должны находиться в порядке, указанном в таблице ниже.
Ниже приведены возможные квалификаторы для справки.
Языковая – 2-буквенный код языка iso 639-1 и, при необходимости, следующий код региона ISO-3166-Alpha-2. Если указаны оба квалификатора, они разделяются на -r . Например, чтобы выбрать национальные настройки для французского языка, fr используется квалификатор. Для назначения French-Canadian языкам fr-rCA используется. Полный список кодов языков и регионов см. в разделе Коды для представления имен языков и названий стран и элементов кода.
Наименьшая ширина – Задает наименьшую ширину экрана, на которой должно выполняться приложение. Более подробно рассматривается Создание ресурсов для различных экранов. Доступно на уровне API 13 (Android 3,2) и более поздних версий. Например, квалификатор sw320dp используется для целевых устройств, высота и ширина которых не меньше 320dp.
Доступная ширина – Минимальная ширина экрана в формате w N DP, где N — ширина в независимых пикселях. Это значение может измениться при повороте устройства пользователем. Более подробно рассматривается Создание ресурсов для различных экранов. Доступно на уровне API 13 (Android 3,2) и более поздних версий. Пример. квалификатор w720dp используется для целевых устройств, ширина которых не меньше 720dp.
Доступная высота – Минимальная высота экрана в формате h N DP, где N — высота в DP. Это значение может измениться при повороте устройства пользователем. Более подробно рассматривается Создание ресурсов для различных экранов. Доступно на уровне API 13 (Android 3,2) и более поздних версий. Например, квалификатор h720dp используется для целевых устройств, имеющих высоту не меньше 720dp
Размер экрана – Этот квалификатор является обобщением размера экрана, для которого предназначены эти ресурсы. Он более подробно рассматривается в разделе Создание ресурсов для различных экранов. Допустимые значения: small , normal , large и xlarge . Добавлено на уровне API 9 (Android 2.3/Android 2.3.1/Android 2.3.2)
Экранный аспект – Это зависит от пропорций, а не от ориентации экрана. Длинный экран шире. Добавлено в API уровня 4 (Android 1,6). Допустимые значения: long и нотлонг.
Ориентация экрана – Ориентация экрана книжной или альбомной ориентации. Это может измениться в течение времени существования приложения. Возможные значения: port и land .
Режим – закрепления Для устройств в закреплениях автомобиля или на стационарных устройствах. Добавлено в API уровня 8 (Android 2.2. x). Возможные значения: car и desk .
Ночной режим – Выполняется ли приложение в ночное время или в день. Это может измениться в течение всего времени существования приложения, и оно должно дать разработчикам возможность использовать более темные версии интерфейса в ночное время. Добавлено в API уровня 8 (Android 2.2. x). Возможные значения: night и notnight .
Плотность точек экрана (DPI) – Число пикселей в заданной области на физическом экране. Обычно выражается в точках на дюйм (DPI). Возможны следующие значения:
ldpi –Экраны с низкой плотностью.
mdpi –Экраны средней плотности
hdpi –Экраны с высокой плотностью
xhdpi –Дополнительные экраны с высокой плотностью
nodpi –Ресурсы, которые не должны масштабироваться
tvdpi –Появилось в API уровня 13 (Android 3,2) для экранов между мдпи и HDPI.
Тип сенсорного экрана – Указывает тип сенсорного экрана, который может иметь устройство. Возможными значениями являются notouch (без сенсорного экрана), stylus (Резисторный сенсорный экран, подходящий для пера) и finger (сенсорный экран).
Доступность клавиатуры – Указывает, какой вид клавиатуры доступен. Это может измениться в течение времени существования приложения, – например, когда пользователь открывает аппаратную клавиатуру. Возможны следующие значения:
keysexposed –Устройство имеет доступную клавиатуру. Если программная клавиатура не включена, она используется только при открытии аппаратной клавиатуры.
keyshidden –На устройстве имеется аппаратная клавиатура, но она скрыта, и программная клавиатура не включена.
keyssoft –на устройстве включена программная клавиатура.
Основной метод – ввода текста Используйте для указания типов аппаратных ключей, доступных для ввода. Возможны следующие значения:
nokeys –Для входных данных не существует аппаратных ключей.
qwerty –Доступна клавиатура QWERTY.
12key –Имеется 12-клавишная аппаратная клавиатура
Доступность – ключа навигации При наличии 5-дневной или d-дневной навигации (направленной панели). Это может измениться в течение времени существования приложения. Возможны следующие значения:
navexposed –для пользователя доступны ключи навигации.
navhidden –ключи навигации недоступны.
Основной метод – навигации без касания Тип навигации, доступный на устройстве. Возможны следующие значения:
nonav –единственным доступным средством навигации является сенсорный экран
dpad –для навигации доступен элемент d-Pad (направленная клавиатура)
trackball –устройство имеет трекбол для навигации
wheel –нетипичный сценарий, в котором доступны один или несколько направлений направления
Версия платформы (уровень API) – Уровень API, поддерживаемый устройством в формате v N, где N — это целевой уровень API. Например, версии 11 будет ориентироваться на устройство API 11 (Android 3,0).
Более полные сведения об квалификаторах ресурсов см. в разделе предоставление ресурсов на веб-сайте разработчиков Android.
Как Android определяет, какие ресурсы использовать
Очень вероятно, что приложение Android будет содержать много ресурсов. Важно понимать, как Android будет выбирать ресурсы для приложения при запуске на устройстве.
Android определяет базу ресурсов путем итерации по следующему тесту правил.
Исключение непротиворечивых квалификаторов – Например, если ориентация устройства книжная, то все альбомные каталоги ресурсов будут отклонены.
Игнорировать квалификаторы не поддерживаются – Не все квалификаторы доступны для всех уровней API. Если каталог ресурсов содержит квалификатор, который не поддерживается устройством, этот каталог ресурсов будет проигнорирован.
Обозначить следующий квалификатор – с наивысшим приоритетом При ссылке на приведенную выше таблицу выберите следующий квалификатор с наивысшим приоритетом (сверху вниз).
Сохраняет каталоги ресурсов для квалификатора – Если в приведенной выше таблице есть каталоги ресурсов, соответствующие квалификатору, выберите следующий квалификатор с наивысшим приоритетом (сверху вниз).
Эти правила также иллюстрируются в следующей блок-схеме:
Если система ищет ресурсы, зависящие от плотности, и не может их найти, она попытается найти другие ресурсы, связанные с плотностью, и масштабировать их. Android может не обязательно использовать ресурсы по умолчанию. Например, если найти ресурс с низкой плотностью и он недоступен, Android может выбрать высокоплотную версию ресурса для ресурсов по умолчанию или средней плотности. Это достигается благодаря тому, что ресурс высокой плотности может масштабироваться в меньшую степень до 0,5, что приведет к меньшему количеству проблем с видимостью, чем уменьшение ресурсов средней плотности, требующих от 0,75.
В качестве примера рассмотрим приложение со следующими нарисованными каталогами ресурсов:
Теперь приложение выполняется на устройстве со следующей конфигурацией:
- Языковой стандарт – EN-GB
- Ориентация страницы – порту
- Плотность экрана – HDPI
- Тип сенсорного экрана – без касания
- Основной метод ввода – 12key
Чтобы начать с, ресурсы на французском языке исключаются, так как они конфликтуют с языковым стандартом, в результате en-GB чего мы получаем:
Затем первый квалификатор выбирается из приведенной выше таблицы квалификаторов: MCC и МНК. Нет каталогов ресурсов, содержащих этот квалификатор, поэтому код MCC/МНК игнорируется.
Выбран следующий квалификатор, который является языком. Существуют ресурсы, соответствующие коду языка. Все каталоги ресурсов, которые не соответствуют коду языка, en отклоняются, чтобы список ресурсов стал следующим:
Следующий квалификатор предназначен для ориентации экрана, поэтому все каталоги ресурсов, не соответствующие ориентации экрана, port устраняются:
Далее следует квалификатор для плотности экрана, ldpi который приводит к исключению еще одного каталога ресурсов:
В результате этого процесса Android будет использовать нарисованные ресурсы в каталоге ресурсов drawable-en-port-ldpi для устройства.
Квалификаторы размера экрана предоставляют одно исключение для этого процесса выбора. В Android можно выбрать ресурсы, предназначенные для меньшего экрана, чем доступно для текущего устройства. Например, большие экранные устройства могут использовать ресурсы для экрана обычного размера. Однако обратная часть этого не имеет значения. на одном и том же большом устройстве не будут использоваться ресурсы, предоставляемые для ксларже экрана. Если Android не удается найти набор ресурсов, соответствующий заданному размеру экрана, произойдет сбой приложения.
Иногда некоторые приложения на 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. Однако, имея базовые знания, разобраться во всем этом — лишь вопрос времени.
Всякая всячина, которую дядюшка Раджа находит в интернете и хочет поделиться с читателями.
Об авторе
Архив блога
Мой блог смотрят
13 февраля 2012
Как заменять системные APK-файлы на Android?
Это опять я и мои инструкции для чайников и кофейников с картинками.
Android - это маленький Linux. В нём надо соблюдать ряд правил при замене файлов, чтобы телефон не превратился в кирпич, оживить который поможет только полная перепрошивка с потерей всех данных из внутренней памяти устройства. Внутренние разделы отформатированы в файловую систему отличную от FAT32 на флешках. В свойствах файла кроме всего прочего хранятся разрешения для разных групп пользователей (хозяин файла, группа хозяина файла, остальные пользователи). При операции с системными файлами их надо сохранять, потому что при загрузке система просто может не суметь получить к ним доступ и не загрузиться нормально.
Начнем с инструментария.
- Менеджер файлов, который умеет работать с root-правами и разрешениями файлов. Лучше всего подойдет Root Explorer (Вы же его купили, да?)
- Сам модифицированный файл, который мы хотим положить наместо системного (ссылка в конце статьи).
Для начала нужно найти и сохранить резервную копию заменяемого файла.
Для этого запускаем Root Explorer и переходим в каталог " /system/app " и в списке находим нужный файл.
Теперь используем одну из удобных функций Root Explorer. Сделаем долгий тап по нужному файлу, чтобы вызвать контекстное меню
Нажимаем кнопкй "Stay", чтобы остаться в папке и сделать еще кое-что.
Теперь всё готово для замены файла.
Я уже говорил про права доступа у каждого файла. Чтобы их воссоздать на новом файле, надо сначала посмотреть их у старого. Они представлены рядом символов " rwxrwxrwx ". 1-я триада - права владельца, 2-я - группы владельца, 3-я - всех остальных пользователей. У нашего файла права "rw-r--r--".
Теперь переходим на SD-карту, находим там модифицированный файл и из его контекстного меню выбираем пункт "Copy", но не торопимся выбирать сразу папку " /system/app ", потому что мы тут же повредим систему. Вместо этого копируем файл в специальную папку для временных файлов " /data/local/tmp ", чтобы привести файл в вид, который примет система.
Для начала вызовем контекстное меню файла и выберем пункт "Rename" и введем имя файла " SystemUI.apk ". Именно так, потому что в Linux регистр букв в имени имеет значение, т.е. " systemui.apk " и " SystemUI.apk " - это разные файлы.
Далее надо изменить права на файл, потому что сейчас они почти наверняка выставлены неправильно. Для этого опять вызываем контекстное меню файла долгим тапом и выбираем пункт "Permissions". Для нашего значени "rw-r--r--" флажки надо расставить так:
Нажимаем "OK" и снова вызываем контекстное меню. Теперь надо изменить владельца и группу для этого приложения. Для этого выбираем пункт "Изменить владельца". Появится окно с информацией о текущем владельце файла.
Тут надо сделать маленькое отступление.
В папке " /system/app " всеми файлами владеет пользователь "root" (uid=0) и группа "root" (gid=0), а в папке " /system/framework " властвует пользователь "system" (gid=1000) и группа "system" (gid=1000).
Исходя из вышесказанного, выставляем нужные значения и нажимаем "OK".
И в третий раз вызываем контекстное меню для файла и в нем выбираем пункт "Copy" и в диалоге копирования переходим в папку " /system/app ". Теперь смело нажимаем "Paste" и читаем дальше внимательно.
Практически сразу система сообщит, что процесс строки состояния внезапно завершился, и предложит его запустить. Всё попытки будут неудачными. Между появлениями окон надо успеть сделать ряд действий. Перед нажатием кнопки надо вызвать меню выключения аппарата, оно окажется под предупреждением. Теперь надо расположить палец примерно в левой стороне кнопки. Теперь надо очень быстро щелкнуть три раза пальцем, что успеть закрыть предупреждение, выбрать пункт выключения и подтвердить свои намерения.
Теперь ждем выключения телефона, заново его запускаем и наслаждаемся результатом или не наслаждаемся и ищем ошибки.
В этом уроке мы с вами узнаем, зачем в 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-интерфейса и взаимодействовать с другими приложениями.
Подробнее ознакомиться с функциями манифеста можно в официальной документации или в данном видеоуроке.
Читайте также: