androidmanifest xml чем редактировать
Файл манифеста AndroidManifest.xml
Файл манифеста AndroidManifest.xml предоставляет основную информацию о программе системе. Каждое приложение должно иметь свой файл AndroidManifest.xml. Редактировать файл манифеста можно вручную, изменяя XML-код или через визуальный редактор Manifest Editor (Редактор файла манифеста), который позволяет осуществлять визуальное и текстовое редактирование файла манифеста приложения.
Назначение файла
Общая структура манифеста
Файл манифеста инкапсулирует всю архитектуру Android-приложения, его функциональные возможности и конфигурацию. В процессе разработки приложения вам придется постоянно редактировать данный файл, изменяя его структуру и дополняя новыми элементами и атрибутами.
Описание
Элемент является корневым элементом манифеста. По умолчанию Eclipse создает элемент с четырьмя атрибутами:
Атрибуты
объявляет разрешение, которое используется для ограничения доступа к определенным компонентам или функциональности данного приложения. В этой секции описываются права, которые должны запросить другие приложения для получения доступа к вашему приложению. Приложение может также защитить свои собственные компоненты (деятельности, службы, приемники широковещательных намерений и контент-провайдеры) разрешениями. Оно может использовать любое из системных разрешений, определенных Android или объявленных другими приложениями, а также может определить свои собственные разрешения.
android:name название разрешения android:label имя разрешения, отображаемое пользователю android:description описание разрешения android:icon значок разрешения android:permissionGroup определяет принадлежность к группе разрешений android:protectionLevel уровень защиты
Элемент запрашивает разрешение, которые приложению должны быть предоставлены системой для его нормального функционирования. Разрешения предоставляются во время установки приложения, а не во время его работы.
android:name имеет единственный атрибут с именем разрешения android:name. Это может быть разрешение, определенное в элементе
данного приложения, разрешение, определенное в другом приложении или одно из стандартных системных разрешений, например: android:name=»android.permission.CAMERA» или android:name=»»android.permission.READ_CONTACTS»
Наиболее распространенные разрешения
объявляет базовое имя для дерева разрешений. Этот элемент объявляет не само разрешение, а только пространство имен, в которое могут быть помещены дальнейшие разрешения.
определяет имя для набора логически связанных разрешений. Это могут быть как объявленные в этом же манифесте с элементом
разрешения, так и объявленные в другом месте. Этот элемент не объявляет разрешение непосредственно, только категорию, в которую могут быть помещены разрешения. Разрешение можно поместить в группу, назначив имя группы в атрибуте permissionGroup элемента
Программирование за 24 часа (Android) — структура проекта Android (Часть 1.3)
После создания нашего проекта в среде Eclipse.
На панели File Explorer (Проводник файлов) среды разработки Eclipse, у нас появился новый проект Android — Droid 1. В дополнение к обычному JAR-файлу Android SDK, были созданы другие необходимые файлы и папки для приложения:
/src — папка, с исходным кодом, /src/com.androidbook.droidl/DroidActivity.java — у нашего приложения точкой входа будет — деятельность DroidActivity, /res — папка, необходимая для управления всеми ресурсами нашего приложения.
Ресурсы нашего приложения это анимация, файлы макетов, графические объекты, данные числового и строкового типа, а также другие файлы, /res/drawable — графические ресурсы приложения (иконки, значки), /res/layout/main.xml — файл макета, необходимый для деятельности DroidActivity, которая в свою очередь отвечает за прорисовку экрана, /res/values/strings.xml — строковые ресурсы. /gen/com.androidbook.droid1/R.java — созданный автоматически-исходный файл управления ресурсами.
Редактировать его не желательно, /assets — папка для хранения скомпилированных файлов ресурсов нашего проекта, AndroidManifest.xml — главный файл конфигурации приложения ( файл манифеста ), default.properties — созданный автоматически файл сборки, необходимы в среде Eclipse и плагину ADT. Редактировать его не желательно.
Редактирование ресурсов проекта
Рис. 1.3. Редактирование ресурсов Android в Eclipse
РЕДАКТИРОВАНИЕ ФАЙЛА AndroidManifest.xml.
Файл AndroidManifest.xml— это основной файл конфигурации любого приложения Android. Редактор распределяет всю информацию файла по полочкам в виде древовидного меню.
Manifest (Манифест) — на вкладке (рис. 1.3), определяются все общие параметры нашего приложения, такие как имя пакета, информация о версии нашего приложения (для установки и обновления в будущем).
Application (Приложение) — в этой вкладке определяются данные о приложении, название и пиктограмма нашего приложения, и другие компоненты нашего приложения.
Permissions (Разрешения) — определяет права доступа приложения, к определённым функциям телефона.
Instrumentation (Инструментарий) — дополнительные инструменты Android SDK.
AndroidManifest.xml — содержит обычный XML редактор файла манифеста.
2. Переходим в Application (Приложение).
3. Раскрываем список атрибута debuggable и выбираем пункт true.
4. Сохраним файл манифеста.
Теперь, если мы переключимся на вкладку AndroidManifest.xml, то увидим
android:debuggable»true» режим отладки включен.
РЕДАКТИРОВАНИЕ ФАЙЛОВ РЕСУРСОВ
/layout — папка хранит файлы макета интерфейса пользователя. Здесь находится макет экрана main.xml, который содержит описание интерфейса пользователя, для деятельности по умолчанию.
Почти все ресурсы нашего приложения находятся в папке /res. Папка /res — имеет подпапки;
Эти папки хранят графические файлы ресурсов для разрешений экрана.
/values – в этой папке разные типы ресурсов собраны по типам, значения цвета, строковые значения, и другие типы. Здесь находится файл ресурса strings.xml, который хранит строковые ресурсы, для использования в приложении. Кликнув два раза мышкой по любому из файлов ресурсов, файл откроется в редакторе. Любые XML-данные вы можете редактировать в текстовом редакторе.
Редактирование строковых ресурсов.
Откроем в редакторе main.xml, мы видим, что он содержит один элемент интерфейса пользователя — TextView, который выводит на экран строку с текстом, который находится в строковом ресурсе 0string/hello.
Чтобы отредактировать строковой ресурс 0string/hello
1.Открываем в редакторе файл strings.xml.
2.Сразу же видим строковый ресурс hello и текст Hello World, DroidActivity.
3.Меняем Value (Значение) на Hello, Android.
Переключимся на strings.xml и посмотрим на отредактированный код XML, видим что контейнерный тег содержит два элемента:
Первая строка это @string/hello.
Вторая — это @ string/app_name, с названием приложения.
Если посмотреть сейчас файл, вы увидите что @string/ app_name используется в конфигурации приложения.
Замена манифеста при сборке в Marmalade под Android
В связи с вопросом, заданным Nonameface, я хочу опубликовать небольшое руководство, которое, возможно, окажется для кого-то полезным. Многим, рассматриваемый вопрос может показаться элементарным. Я прошу не судить меня строго, поскольку этот материал адресован начинающим разработчикам.
Суть описываемой проблемы в том, что при сборке под Android, в манифест включаются все права которые только могут понадобиться приложению, разработанному в Marmalade. При этом, не выполняется никаких проверок, используются ли эти права приложением на самом деле. В результате, у пользователя, устанавливающего приложение, возникают законные вопросы: «Для чего приложение требует права на чтение и отправку SMS, если оно, совершенно очевидно, не работает с этим функционалом?».
Пользователь, совершенно резонно, может посчитать приложение небезопасным и отказаться от его установки. Давайте посмотрим, как с этим можно бороться.
Очевидно, что нам необходимо выполнить сборку, каким-то образом подменив файл AndroidManifest.xml. Для начала, нам нужно получить оригинальный AndroidManifest.xml, формируемый инструментальными средствами Maramalade. Хотя apk-файл, по сути представляет собой zip-архив и извлечь из него требуемый файл не составляет труда, задача несколько осложняется тем, что файл храниться не в текстовом, а в двоичном виде. Извлечь файл манифеста в текстовом представлении нам поможет apktool.
Выкачиваем apktool1.5.1.tar.bz2 и apktool-install-windows-r05-ibot.tar.bz2 (в случае, если используется Windows) к себе на компьютер, и распаковываем в какой-нибудь локальный каталог. Также потребуется установленная на компьютер Java (у меня установлена jdk1.6.0_23). Распаковать apk-файл можно следующей командой:
Затем, находим в созданном каталоге AndroidManifest.xml преобразованный в текстовую форму и открываем его:
Далее, мы можем отредактировать этот файл, на свой вкус, например убрав не используемые permission-ы. Для того, чтобы при последующих сборках использовалась отредактированная версия манифеста, в mkb-файл необходимо добавить следующий раздел:
Вот, в принципе, и все. После описанной замены манифеста, тестирование сборки на Android-устройстве необходимо. Вполне возможно, что какая-то часть функционала перестанет работать, либо приложение просто перестанет запускаться.
Работа с манифестом Android
AndroidManifest.xml на платформе Android — это мощный файл, который позволяет описать функциональные возможности и требования приложения для Android. Но работать с ним непросто. Xamarin.Android помогает упростить работу, позволяя добавлять в классы настраиваемые атрибуты, которые будут использоваться для автоматического создания манифеста. Наша цель заключается в том, чтобы 99 % наших пользователей никогда не испытывали потребности вручную изменять AndroidManifest.xml.
AndroidManifest.xml создается в процессе сборки, а найденный в Properties/AndroidManifest.xml XML-код объединяется с XML, созданным на основе настраиваемых атрибутов. Итоговый файл AndroidManifest.xml помещается в подкаталог obj, например для отладочных сборок. Например, он может находиться в папке obj/Debug/android/AndroidManifest.xml. Используется стандартный процесс слияния. Настраиваемые атрибуты в коде используются для создания XML-элементов, и эти элементы вставляются в AndroidManifest.xml.
Основы
Этот пример приводит к добавлению следующего фрагмента XML в файл AndroidManifest.xml:
Имя действия
Начиная с Xamarin.Android 5.1, имена типов для действий основаны на MD5SUM от имени экспортируемого типа с указанием сборки. Это позволяет предоставить одно и то же полное имя из двух разных сборок и не получить ошибку упаковки (до версии Xamarin.Android 5.1 имя типа действия по умолчанию составлялось из имени пространства имен и имени класса в нижнем регистре).
Если вы хотите переопределить это поведение по умолчанию и указать имя действия явным образом, используйте свойство Name :
В этом примере создается следующий фрагмент XML:
Свойство Name следует использовать только для поддержки обратной совместимости, так как такое переименование может замедлить поиск типов во время выполнения. Если у вас есть старый код, который ожидает, что в качестве имени типа для действия по умолчанию используется имя пространства имен и имя класса в нижнем регистре, воспользуйтесь рекомендациями по сохранению совместимости, касающимися имени вызываемой программы-оболочки.
Заголовок действия
В этом примере создается следующий фрагмент XML:
Возможность запуска из средства выбора приложений
В этом примере создается следующий фрагмент XML:
Значок действия
По умолчанию действию присваивается значок запуска, предоставляемый системой. Чтобы использовать пользовательский значок, добавьте нужный файл .png в папку Resources/drawable, задайте для него действие сборки AndroidResource и с помощью свойства Icon укажите этот файл в качестве значка. Пример:
В этом примере создается следующий фрагмент XML:
Разрешения
Отладочные сборки автоматически устанавливают некоторые разрешения, чтобы упростить отладку (например INTERNET и READ_EXTERNAL_STORAGE ) – эти параметры задаются только в созданном obj/Debug/android/AndroidManifest.xml и не отображаются как включенные в параметрах необходимых разрешений.
Например, если вы изучите созданный файл манифеста в obj/Debug/android/AndroidManifest.xml, то увидите следующие добавленные элементы разрешений:
В версии сборки выпуска эти разрешения не включаются в манифест автоматически (obj/Debug/android/AndroidManifest.xml). Если обнаружится, что при переключении на сборку выпуска приложение теряет разрешение, которое было доступно в сборке отладки, убедитесь, что это разрешение явным образом включено в параметрах необходимых разрешений для этого приложения (в разделе Сборка > Приложение Android в Visual Studio для Mac или Свойства > Манифест Android в Visual Studio).
Дополнительные функции
Действия и функции намерения
В этом примере создается следующий фрагмент XML:
Элемент Application
Кроме того, в манифесте Android можно объявлять свойства для всего приложения. Это делается с помощью элемента и его аналога, настраиваемого атрибута Application. Обратите внимание, что это параметры уровня приложения (сборки), а не отдельные параметры для каждого действия. Как правило, свойства объявляются для всего приложения, а затем переопределяются (по мере необходимости) для каждого действия.
Вскрываем, модифицируем и запаковываем 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. Но это что касается обертки. А что внутри? Внутри же у нас в общем случае такая структура:
Перечисленные файлы и каталоги есть если не во всех, то, пожалуй, в абсолютном большинстве APK. Однако стоит упомянуть еще несколько не столь распространенных файлов/каталогов:
Этот каталог используют производители игр, помещая туда движок игры, написанный на C/C++, а также создатели высокопроизводительных приложений (например, Google Chrome). С устройством разобрались. Но как же получить сам файл пакета интересующего приложения? Поскольку без рута с устройства забрать файлы APK не представляется возможным (они лежат в каталоге /data/app), а рутить не всегда целесообразно, имеется как минимум три способа получить файл приложения на компьютер:
Какой из них использовать — дело вкуса; мы предпочитаем использовать отдельные приложения, поэтому опишем использование Real APK Leecher, тем более что написан он на Java и, соответственно, работать будет хоть в винде, хоть в никсах.
После запуска программы необходимо заполнить три поля: Email, Password и Device ID — и выбрать язык. Первые два — e-mail и пароль твоего гуглоаккаунта, который ты используешь на устройстве. Третий же является идентификатором устройства, и его можно получить, набрав на номеронабирателе код ##8255## и затем найдя строку Device ID. При заполнении надо ввести только ID без префикса android-.
Настройка Real APK Leecher
Хакер #170. Малварь для OS X
После заполнения и сохранения нередко выскакивает сообщение «Error while connecting to server». Оно не имеет отношения к Google Play, поэтому смело его игнорируй и ищи интересующие тебя пакеты.
Просмотр и модификация
Допустим, ты нашел интересующий тебя пакет, скачал, распаковал… и при попытке просмотра какого-нибудь XML-файла с удивлением обнаружил, что файл не текстовый. Чем же его декомпилировать и как вообще работать с пакетами? Неужели необходимо ставить SDK? Нет, SDK ставить вовсе не обязательно. На самом деле для всех шагов по распаковке, модификации и упаковке пакетов APK нужны следующие инструменты:
Использовать все эти инструменты можно и по отдельности, но это неудобно, поэтому лучше воспользоваться более высокоуровневым софтом, построенным на их основе. Если ты работаешь в Linux или Mac OS X, то тут есть инструмент под названием apktool. Он позволяет распаковывать ресурсы в оригинальный вид (в том числе бинарные XML- и arsc-файлы), пересобирать пакет с измененными ресурсами, но не умеет подписывать пакеты, так что запускать утилиту signer придется вручную. Несмотря на то что утилита написана на Java, ее установка достаточно нестандартна. Сначала следует получить сам jar-файл:
Далее нам понадобится скрипт-обвязка для запуска apktool (он, кстати, доступен и для Windows), включающий в себя еще и утилиту aapt, которая понадобится для запаковки пакета:
Далее просто сваливаем содержимое обоих архивов в каталог
Если же ты работаешь в Windows, то для нее есть превосходный инструмент под названиемVirtuous Ten Studio, который также аккумулирует в себе все эти инструменты (включая сам apktool), но вместо CLI-интерфейса предоставляет пользователю интуитивно понятный графический интерфейс, с помощью которого можно выполнять операции по распаковке, дизассемблированию и декомпиляции в несколько кликов. Инструмент этот Donation-ware, то есть иногда появляются окошки с предложением получить лицензию, но это, в конце концов, можно и потерпеть. Описывать его не имеет никакого смысла, потому что разобраться в интерфейсе можно за несколько минут. А вот apktool, вследствие его консольной природы, следует обсудить подробнее.
Импорт APK в Virtuous Ten Studio
Рассмотрим опции apktool. Если вкратце, то имеются три основные команды: d (decode), b (build) и if (install framework). Если с первыми двумя командами все понятно, то что делает третья, условный оператор? Она распаковывает указанный UI-фреймворк, который необходим в тех случаях, когда ты препарируешь какой-либо системный пакет.
Рассмотрим наиболее интересные опции первой команды:
Пользоваться apktool очень просто, для этого достаточно указать одну из команд и путь до APK, например:
После этого в каталоге mail появятся все извлеченные и дизассемблированные файлы пакета.
Препарирование. Отключаем рекламу
Теория — это, конечно, хорошо, но зачем она нужна, если мы не знаем, что делать с распакованным пакетом? Попробуем применить теорию с пользой для себя, а именно модифицируем какую-нибудь софтину так, чтобы она не показывала нам рекламу. Для примера пусть это будет Virtual Torch — виртуальный факел. Для нас эта софтина подойдет идеально, потому что она под завязку набита раздражающей рекламой и к тому же достаточно проста, чтобы не потеряться в дебрях кода.
Поиск кода рекламы в jd-gui
После этого в каталоге 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) подписываем. Чтобы создать наш приватный ключ, заполняем следующие поля:
Остальные поля, в общем-то, необязательны — но необходимо заполнить хотя бы одно.
Создание ключа в 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:
Здесь создается поле ad для хранения объекта класса Ad. Комментируем с помощью установки знака ### перед строкой. Продолжаем поиск. Строка 423:
Здесь происходит создание объекта. Комментируем. Продолжаем поиск и находим в строках 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 NDK. Однако, имея базовые знания, разобраться во всем этом — лишь вопрос времени.