Sh чем открыть на андроид
Скрипты на shell под Android
Тема посвящена созданию, отладке скриптов на шелле, а также освоению и изучению всевозможных утилит командной строки Андроида.
Для полноценной реализации желаемого под Андроидом как правило понадобятся root-права и busybox.
Данная тема выросла из темы Tasker (родительская тема), поэтому не удивляйтесь, если Вас внезапно отправят туда. (Tasker - это шелл в Андроиде.) Из данной темы выросла дочерняя тема Ядро Linux изнутри, все вопросы по ядру следует задавать в ней.
Список литературы по устройству Unix, п.1 списка обязателен для чтения
Программирование на shell (Unix) учебное пособие А. Соловьева (первоисточник - п. 1 из списка выше - конечно предпочтительнее пересказа)
Справка по busybox
Нормативная документация по Андроиду:
- Android Architecture aka Android Interfaces and Architecture - внутреннее устройство системы
- Android Core Technologies (современное название - Configure an Android Device) - что можно хакнуть в системе, и как сделать это правильно
Матчасть: «заморозка» приложений и компонентов
- объяснение на пальцах
- обсуждение нюансов: вопрос, ответ
- из обуждения выше через пару лет возник рассказ Заморозка приложений или многа букф 3
Матчасть: экранирование символов
Shell-скриптинг в среде Android статья в журнале Xakep для тех, кто не способен осилить более-менее серьезный текст, для вменяемых людей - пустая трата времени
команда set -x - встроенный в шелл инструмент отладки, выводит каждую команду скрипта в stderr , подробности.
wShell - эмулятор терминала с веб-интерфейсом на основе Shell In A Box. Если Android-устройство и компьютер находятся в одной локальной сети, можно с компьютера получить доступ к командной строке устройства через веб-браузер.
ShellCheck - статический анализатор (lint) для shell-скриптов (немного подробностей)
Большинство команд и скриптов, размещенных в этой теме, выполняются от имени пользователя root. Это означает, что команда (или скрипт) при неправильном использовании может создать новые проблемы, а не помочь решить старые. Причем проблемы уже большие, перед которыми старые будут казаться сущим пустяком.
Поэтому перед тем, как бросаться скачивать, вбивать команды и выполнять их
1. Сделайте полный бэкап прошивки (nandroid backup).
Если не знаете, что это такое, Вы оказались в этой теме слишком рано. Прочитайте разделы помощи новичкам на форуме, тему про прошивки своего аппарата.
«Игрушечные» бэкапы, типа Titanium Backup не помогут, если вдруг случится страшное. Бэкап менеждер bu, встроенный в Андроид ICS и выше (используется такими программами, как Helium), также поможет не всегда. Не балуйтесь и не ленитесь, сделайте нормальный бэкап из под рекавери.
2. Сделанный в п. 1 бэкап положите в надежное место.
Не надо его удалять сразу после того, как Ваши эксперименты закончились, по Вашему мнению, успешно. У Андроида может быть совершенно иной взгляд на их успешность. Понаблюдайте за системой, поживите некоторое время в ней. Если наблюдаете странные вещи, откатитесь на сохраненное состояние. Опять понаблюдайте.
Кстати, бэкап поможет и проанализировать произошедшее, случись вдруг что-нибудь. Возможно, нам потребуются файлы из него в процессе разбирательства.
3. Если Вы совсем не понимаете, что делает тот или иной скрипт, выложенный в теме, постарайтесь все-таки разобраться перед тем, как им воспользоваться.
Для некоторых скриптов необходимо соблюдать условия их выполнения, иначе они не просто не будут работать, а еще и сделают что-нибудь с системой. Запросто.
Наверняка скрипт в том виде, как он выложен, Вас не устроит. Нужно будет его «допилить» под свои нужды.
Наконец, самое страшное (и самое маловероятное, но все же). Вам могут подсунуть скрипт, который сделает что-нибудь нехорошее. И ладно, если просто файлы в системе поудаляет, Вы же выполнили п.1 Правил. (Правда? Точно уверены? Ладно, поверим.) Хуже, если скрипт отправит чего-нибудь на короткий номер в Зимбабве. Ну, там номер кредитки, например. Что, кредитки нет? Ничего, СМС на короткий номер в Зимбабве не бесплатное, знаете ли. И не думайте, что что-нибудь Вас защитит, скрипт от рута не поймают ни антивирус, ни различные менеджеры безопасности. Конечно, мы быстро вмешаемся, и дальнейшее распространение зловреда остановим. (Но конкретно Ваше СМС-то уйдет. В Зимбабве.)
4. Ваш аппарат (телефон, планшет) не является единственным полигоном для Ваших опытов.
Большинство скриптов можно проверить и отладить на ББ под Linux. Виртуальной машины и Live дистрибутива вполне достаточно. Любого дистрибутива Linux. Понадобится busybox, чтобы приблизить такой полигон к реальному аппарату, но в любом дистрибутиве Linux busybox присутствует.
Еще можно использовать эмулятор Андроида. Да, есть у Гугля в хозяйстве и такое. Лежит рядом с SDK для Андроида, образ с Андроидом можно найти в интернете. Это по-любому лучше, чем курочить реальный аппарат. Напоминаю, он Вам обошелся в определенную сумму. (Конечно, работая в эмуляторе надоевший Вам уже п. 1 Правил выполнять не нужно.)
5. Для отладки скриптов лучше использовать не приложение-эмулятор терминала, а adb (Android Debug Bridge) или ssh-сессию с ББ на аппарат.
Пальцы же сломаете набирать символы на виртуальной клавиатуре. Опять-таки, ошибетесь, натворите бед. Клиентскую часть adb (для ББ) можно найти в интернете, серверная часть в Андроиде уже есть (отладку не забудьте включить в «Настройках»). Приложения с сервером ssh можно найти в Google Play.
Описание примера Работа shell-скрипта для перехвата аппаратных кнопок телефона.
Знатокам команд ОС linux и их специфики -- не смеяться.
Нужен рут и busybox .
Всесторонняя поддержка была оказана уважаемым username11, где я порой только нажимал на кнопки, следуя множеству его мудрых советов.
Данный пример -- оффтоп! :D потому что таскер в нём не участвует. Совсем. Только шелл, только хардкор. Пример кстати рабочий))
Так как это только пример, каждый может растащить его на множество кусочков и использовать нужные части в связке со своими нуждами.
Вообще, текста будет много, потому что я болтун..
Приступим к делу. Вот результирующий пример, и сразу напишу, что он делает, а потом разбор:
(rep=0; script -q -c 'getevent /dev/input/event1' /dev/null | while read code; do torch=`cat /sys/class/leds/torch/brightness`; screen=`cat /sys/class/leds/lcd-backlight/brightness`; (echo "$code" | grep -q '^0004 0004 00000004.$') && [ "$rep" = "0" ] && [ "$screen" = "0" ] && ( torch=$(expr 255 - $torch); echo "$torch" > /sys/class/leds/torch/brightness ); rep=$( expr 1 - $rep ); done ) < /dev/null >/dev/null 2>/dev/null &
Итак, эта строчка (это ОДНА строчка) запущенная в терминале, или через Задачу Таскера "Run script" запускается в память (и висит там! терминал можно закрывать) и делает следующее: Она отслеживает нажатие аппаратной кнопки Громкость Вниз (думаю на большинстве Xperia заработает тоже, официально отлажено под Xperia Ray) при выключенном экране, и включает (и выключает) фонарик.
Начнём, пожалуй, с перехвата кнопок. Как наиболее интересующую общественность возможность. Надо не забывать при этом, что штатные функции телефона, происходящие при нажатии той или иной кнопки, телефоном параллельно ловятся и функции отрабатывают. Так что, повесить исключительно "свои" полезняшки на нажатия не получится. Почему я и упростил в процессе изучения перехвата себе задачу -- реагирую я на кнопки только при выключенном экране. При штатной блокировке телефон не реагирует на кнопки громкости при выключенном экране.
Вообще, получается красиво: нажимаешь качельку громкости и МГНОВЕННО включается фонарь, а экран при этом остаётся выключенным.
Отладка скрипта, это собственно 99.9 процента всего времени, потраченного на, поэтому гораздо удобнее "общение" будет проводить в проводном или беспроводном adb. Вертеть варианты отладки через терминал телефона утомительно. (а отладки будет много).
Часть 1. Перехват. Теория.
/dev/input/event7: 0003 0010 fffffed0
/dev/input/event7: 0003 0011 ffffff5a
/dev/input/event7: 0003 000a 000003ee
/dev/input/event7: 0000 0000 00000000
/dev/input/event7: 0003 0003 00001138
/dev/input/event3: 0003 0000 00000006
/dev/input/event7: 0003 0004 000000d3
/dev/input/event3: 0003 0001 00000007
/dev/input/event7: 0003 0005 000000b3
/dev/input/event3: 0003 0002 00000078
/dev/input/event7: 0003 0000 00000028
/dev/input/event3: 0003 0028 00000043
/dev/input/event7: 0003 0001 ffffffde
/dev/input/event3: 0000 0000 00000000
/dev/input/event7: 0003 0002 fffffd4d
/dev/input/event7: 0003 0010 fffffecf
/dev/input/event7: 0003 0011 ffffff60
/dev/input/event7: 0003 000a 000003f2
Да, вот такие пачки на каждое действие!
0004 0004 00000004
0001 0072 00000001
0000 0000 00000000
0004 0004 0000000c
0000 0000 00000000
0004 0004 00000014
0000 0000 00000000
0004 0004 0000001c
0000 0000 00000000
0004 0004 00000024
0000 0000 00000000
0004 0004 00000024
0000 0000 00000000
0004 0004 00000004
0001 0072 00000000
0000 0000 00000000
0004 0004 0000000c
0000 0000 00000000
0004 0004 00000014
0000 0000 00000000
0004 0004 0000001c
0000 0000 00000000
Так система (а мы подглядываем за реальными кодами, которые обрабатывает и система) различает нажатия, отжатия, а так же -- _долгие_ нажатия, если они есть. То есть, если ловить "Долгую громкость вниз" -- то это всё ручками, самим засекать сначала нажатие, и какая была пауза до отжатия, ну, до удержания, да. А только потом вызывать своё действие. До этого у меня пока руки не дошли, но есть такой ключик '-t' -- показывать временные отметки каждого прилетевшего кода.
Понажимав все свои три кнопки)) я пришёл к выводу о достаточности в моём частном случае ловли кода '0004 0004 00000004', правда он случается и в нажатии и в отжатии, но это мы поймаем и учтём.
username11 пишет, что реальным кодом действия (нажатия, возни по тачу, еще какой датчик) служит первая строка, а остальные это "эхо системы" на первое действие -- какие-то, как я понял, генерации уже "софтовые", дополнительных кодов для других системных ловушек. Что бы в другом нужном процессе тоже возникло срабатывание на действие. В добавок: по моей логике, коды-пачки нулей -- это есть завершение "описания" кода. То есть, каждый ноль ('0000 0000 00000000') это конец логической "строки" event'а. В любом случае это лир.отступление, к делу его не пришьёшь, а коды ловить придётся))
формализованно: "ввод_данных | while read var1; do [наша построчная обработка] ; done"
разбор:
ввод_данных в данном случае это наш поставщик данных, "getevent /dev/input/event1"
вертикальная палка это перенаправление вывода консоли (то, что мы видим как появляющиеся строки после команды getevent) в другую команду на обработку дальше. (да, я пишу для таких валенков, как я)).
while read совокупность команд делающих следующее: while ("пока") обеспечивает нам бесконечный цикл считывания строк "из-под" getevent'а, а read ("читать") каждую строку вида '0004 0004 0000001c' распихивает по переменным шелла, имена которых указаны после слова 'read'.
Например. Команда "ввод_данных | while read dev code" первое "слово" ДО РАЗДЕЛИТЕЛЯ (у нас это пробел) положит в переменную dev, а остальной хвостик (до конца строки) в переменную code. (Обращаться в шелле к значениям переменным мы потом будет $dev и $code). И равны они будут dev='0004', code='0004 0000001c'. А если переменных будет скажем три: "ввод_данных | while read dev code1 code2", то наш пример, поданный на вход команды, она раскидает так: dev='0004', code1='0004', code2='0000001c'. Правда здоровско?
Сам я пришёл к локальному выводу, что мне проще ловить ВСЮ строку ('0004 0004 00000004') в одну переменную, то есть у меня это 'while read code'. И одну переменную $code уже сравнивать на нужное значение.
Всё, что идёт за знаком "точка с запятой" (semicolon, так сказать) после команды read, это есть команды обработки результата "распихивания" _каждой_ строки с кодами, прилетающей от getevent.
Локальный вывод: То есть, заказали мы прерывания от устройства event1, аппаратных кнопок, и всё, всё "висит" и бездействует. Система спит. Нажатие кнопки (любой) пробуждает систему (она отрабатывает сама) и присылает в getevent пачку строк с произошедшими событием. Мы раскидываем полученные строки с помощью while read на составляющие и уходим на дальнейшую обработку каждой строки отдельно, сравнивая, наша ли эта, искомая, строка, или нет. И потом запускаем боевую нагрузку, выполняем какое-то действие (включаем фонарик, как я, или вызываем сразу задачу таскера). (В принципе, вот всё решение). Но, об этом всём в своё время, ниже, а пока меня ждала целая серия засад:
Часть 2. Workarounds. Первое столкновение с практикой.
Часть 3. Фонарик. Долгая дорога в дюнах.
Ну, тут я прилично еще поплутал, Начальник подсказал, как проще сделать "переключалку" на командной строке, из 0 в 1 и обратно, _одной_ командой. (как я спросил: "как сделать xor ax,1" ))) Оказалось: а=$(expr 1 - $a).
Я заранее знал "переменную" включения фонаря, у меня (думаю, и на всех xperias так же) это /sys/class/leds/torch/brightness. Значение 0 не светит, 255 -- светит. (и все промежуточные от 3 до 255 работают, но да про красиво-плавно включаемый фонарик и как я писал бинарь на си для андроида прямо на телефоне, это сказ отдельный)).
Еще мне нужно было найти, включен экран в данный момент или нет, потому что получая управление в точке echo code:$code я решительно (пока) не представлял, что с экраном. А если он включен, это штатное системное изменение громкости, и в ДАННЫЙ момент включать фонарик совершенно не обязательно.
Полазив, я нашёл. Рядом. /sys/class/leds/lcd-backlight/brightness тоже, 0-255, что ли. По крайней мере выключенный экран "0", включенный -- НЕ ноль.
Ииии.. я запилил. Полный скрипт вы видели уже в начале. Ой, нет, это еще не всё)))
Часть 4. Последняя засада
Теперь всё заработало.
Домашнее задание от username11 я так пока и не выполнил((, а оно вот:
1) выяснить, кто хочет ввода-вывода и устранить.
2) убрать лишние круглые скобки. каждые скобки, это лишний шелл запущенный каскадом.
Такскера тут вообще нет, как вы видите. Справившись с половиной этого дела, отсутствие таскера было уже делом принцпа)) зачем? когда всё "шелльно" и легко. А огромная дурильня-таскер испортит всю красоту. Да и для чего? Мигнуть фонариком?
Таскер по идее, как Начальник неоднократно писал, должен вызываться через am broadcast в "теле" боевой части.
Ответственность сторон.
Существует множество инструментов для работы с подключенным с помощью USB-кабеля или Wi-Fi смартфоном. Особо развитые инструменты позволяют перемещать файлы, устанавливать и удалять софт, просматривать контакты, делать скриншоты экрана и даже отправлять СМС, однако ни один графический инструмент не сравнится с мощью, которую может дать консоль Android. В этой статье мы поговорим об ADB (Android Debug Bridge) — стандартном инструменте для отладки и работы с консолью Android с компа.
Описанные в статье команды можно выполнять непосредственно на устройстве, скачав из маркета эмулятор терминала, но удобнее это делать, конечно же, с компа через adb.
Что еще?
С помощью скриптов в Android можно сделать намного больше, чем бэкапы и настройка параметров системы. Вот, например, скрипт, который просыпается каждые десять минут и, если уровень заряда батареи стал меньше 30%, отключает Wi-Fi и Bluetooth:
Чтобы скрипт работал в фоне, достаточно вызвать его следующим образом:
А это скрипт, который позволяет быстро заполнять формы, требующие ввода имэйла и пароля (в приложениях и на веб-сайтах):
Запускать его можно разными способами. Либо перед запуском приложения, установив задержку:
Либо повесить на какое-то событие Tasker, например на взмах смартфоном. Другой вариант — использовать буфер обмена. В Android, чтобы вставить нужный текст в буфер обмена, достаточно выполнить такую команду:
Не ахти как удобно, зато работает. Как мы можем использовать такую функциональность? Например, сделать простенький скрипт clip.sh:
Соль в том, что скрипт можно вызывать через удаленный ADB либо вообще поместить в /system/etc/init.d/, заменив $1 на нужный текст. Так нужные нам данные всегда будут под рукой, а бесполезный на смартфоне механизм копирования/вставки получит хоть какое-то назначение. Консольные команды можно использовать и для более высокоуровневых операций, например позвонить по указанному номеру:
Или просто открыть окно номеронабирателя с нужным номером:
Скрипт принимает два аргумента: номер телефона и содержимое SMS. После запуска он откроет окно SMS-приложения, вставит в него нужный текст, а затем нажмет кнопку Enter для отправки, после чего окно закроется.
Другие полезные при скриптинге команды:
- Перезагрузка в режим recovery:
- Мягкая перезагрузка (без перезапуска ядра):
- Открыть нужное приложение (в данном примере — «Настройки»):
- Открыть веб-страницу:
- Сообщить приложениям о низком уровне заряда батареи (есть софт, который при этом снижает свою активность):
- Изменить MAC-адрес:
- Активировать вибратор:
- Включить фонарик:
- Проиграть файл (может не сработать):
- Отключить указанное приложение (можно организовать цикл для отключения bloatware по списку):
- Получить список приложений, которые имеют уведомления в строке состояния:
- Оптимизировать внутренние базы данных с настройками (можно добавить скрипт в автозагрузку, требуется BusyBox):
- Переключить Wi-Fi-тизеринг на основной интерфейс (нужно для обмана операторов, которые ограничивают скорость соединения при раздаче интернета по Wi-Fi):
Просмотр и модификация
Допустим, ты нашел интересующий тебя пакет, скачал, распаковал… и при попытке просмотра какого-нибудь 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 появятся все извлеченные и дизассемблированные файлы пакета.
Вместо выводов
Для кого-то все описанное в статье может показаться несколько надуманным. Дескать, все это можно сделать с помощью стандартного софта и Tasker. Но зачем использовать тяжелый Java-софт там, где нужное действие можно выполнить с помощью простенького скрипта, который не занимает лишней памяти и может быть легко перенесен на другое устройство? Скрипты удобны, просты, быстро отрабатывают и дают возможность тонкой настройки под себя.
Первый пример
Теперь давайте попробуем написать первый скрипт. Делать это лучше на компе, а еще лучше в Linux или редакторе, который умеет создавать текстовые файлы без символа возврата каретки (который при открытии в Android будет выглядеть как ^M в конце каждой строки). Наш первый скрипт будет состоять всего из двух строк, которые делают бэкап всех установленных приложений на карту памяти. Его код (требует BusyBox):
Сохраняем (пусть он называется apk_backup.sh) и перекидываем на смартфон с помощью ADB:
Теперь его нужно запустить. Проще всего сделать это с помощью все того же ADB:
Примерно таким же образом скрипт можно запустить из консоли на самом смартфоне/планшете:
Само собой, такой способ не очень удобен. Поэтому нам нужен какой-то быстрый способ запуска скрипта. Наиболее удобное из найденных мной решений — это приложение QuickTerminal. Устанавливаем, запускаем, переходим на вкладку Quick Command, нажимаем кнопку «+», вбиваем имя (произвольное) и команду (sh /sdcard/apk_backup.sh), в поле Output Type выбираем либо Dialog Output, либо Nothing. В первом случае во время выполнения скрипта на экране появится окно с результатом, во втором все пройдет в фоне. Кому что удобнее. Далее сохраняем и получаем кнопку, с помощью которой скрипт можно будет запустить быстро и легко.
Теперь напишем скрипт, который восстановит наш бэкап:
В нем мы задействовали команду pm с опцией install и флагами -t и -r, которые заставляют систему устанавливать приложения, даже если они подписаны тестовым ключом или уже установлены. Также можно использовать флаг -s, который принуждает приложения к установке на карту памяти (если такая возможность есть), или -f — установка во внутреннюю память устройства.
Почти все команды Android имеют подробную справку
Имея рут, можно даже сделать бэкап настроек всех приложений с помощью копирования и архивации каталога /data/data/, однако восстановить его будет очень проблематично, так как в Android каждое приложение исполняется от имени созданного специально для него Linux-юзера и хранит настройки внутри каталога, принадлежащего этому пользователю. Проблема здесь в том, что идентификатор Linux-юзера для каждого приложения генерируется динамически, поэтому после восстановления бэкапа в заново установленной системе идентификаторы не будут совпадать и приложения не смогут прочитать свои настройки. Придется вручную выяснять ID юзера для каждого приложения и менять права доступа на каталоги с данными.
С другой стороны, мы можем использовать встроенный в Android Backup Manager, позволяющий сторонним приложениям использовать возможности системы для бэкапа и восстановления приложений и их данных. Управлять им можно из консоли (а значит, и с помощью скриптов), но сам по себе он никакого бэкапа не производит, а возлагает эту работу на сторонние приложения. Helium — одно из таких приложений. Если установить и настроить его, операцию бэкапа и восстановления можно будет заскриптовать. Например, следующий простой скрипт сделает резервную копию всех сторонних приложений:
Конструкция $ здесь нужна, чтобы обрезать слово «packages:», которое pm добавляет в начало имени каждого пакета. Чтобы восстановить бэкап, можно использовать либо тот же Helium, либо команду bmgr:
Системные утилиты
Кратко остановлюсь на нескольких полезных командах (работоспособность некоторых, однако, может зависеть от версии прошивки и модели телефона).
Изменение DPI. Не требует root и работает на Android 5.0+. Стандартное значение для Nexus 5 — 480. При значении 420 на рабочем столе стокового лаунчера помещается пять иконок в ряд вместо четырех:
Подключение /system в режиме записи. Для части команд, которые меняют системные файлы, необходимо сначала перемонтировать раздел /system на запись. Это необходимо в том числе при удалении системных приложений. Перемонтирование выполняется следующей командой:
Мягкая перезагрузка:
Перевод смартфона в режим энергосбережения Doze (Android M+):
. повторяем действия, пока не увидим idle.
Батарейка в процентах (Android 4.4+):
Продвинутый уровень
В одной из своих статей я показывал, как можно доставать информацию из баз данных различных приложений. Ну а теперь посмотрим, как проделать это прямо из консоли, не качая базы на комп и не устанавливая на устройство просмотрщики баз. Для этого используется команда sqlite3. Выведем на экран историю браузера Chrome:
Чтобы база читалась, необходимо выгрузить браузер из работающих приложений. Прервать выполнение скрипта sqlite можно, нажав Ctrl + Z, а выйти — командой .quit. Если в ответ на команду ты получишь ошибку /system/bin/sh: sqlite3: not found, значит, на смартфоне нет sqlite3 и ее придется скачать, закинуть в /system/bin и дать файлу все права. Я использую sqlite3, который вытащил когда-то из Titanium Backup.
История браузера Chrome
Также с помощью sqlite3 можно выдернуть все контакты с телефона. Для этого в консоли на компе должен использоваться шрифт Lucida Console и перед началом выполнения команд необходимо перевести кодировку на UTF-8. Иначе вместо русских букв будут отображаться непонятные символы. Сами команды выглядят так:
Если все сделано правильно, то в консоли ты увидишь таблицу с порядковым номером записи, номером телефона и контактами, отсортированными по имени. Для контактов с более одного номера будет несколько записей подряд.
Вывод контактов из базы contacts2.db
Можно вывести данные не на экран, а сразу в текстовый файл. Для этого команды нужно изменить:
Альтернативный способ вывода контактов в файл — команда, требующая установленного BusyBox:
Запись видео, происходящего на экране устройства
Данная команда начнет записывать видео с разрешением 1280 x 720 (если не указать, то будет использовано нативное разрешение экрана устройства), с битрейтом 6 Мбит/с, длиной 20 с (если не указать, то будет выставлено максимальное значение 180 с), с показом логов в консоли. Записанное видео будет находиться в /sdcard (файл video.mp4).
Все запущенные из консоли и в adb shell процессы, занимающие некоторое время для выполнения, можно прервать с помощью комбинации Ctrl + C. Выйти из шелла и вернуться к выполнению обычных команд adb — Ctrl + D.
Установка программ
ADB можно использовать для установки приложений без необходимости копировать их на смартфон. Достаточно выполнить такую команду:
В команду также можно добавить дополнительные ключи. Полезными будут -е — переустановить приложение с сохранением данных и -d — установить версию меньше текущей.
Программы можно и удалять, но для этого нужно знать название пакета (как узнать, расскажу чуть позже). На примере игры Angry Birds Seasons команда будет выглядеть так:
Консоль в консоли
Наряду с упомянутой консолью, которая является DOS-консолью под Windows, в Android существует и своя. Она вызывается через adb shell и представляет собой по сути стандартную Linux-консоль, но с неполным набором команд, расширить который можно, установив из маркета BusyBox. Использовать эту консоль можно двумя способами. В интерактивном режиме она запускается командой
В консоли появляется знак $ (далее по тексту этот знак будет означать необходимость ввода предварительной команды adb shell), и после этого можно вводить серию команд, получая после каждой отклик. Второй способ — если необходимо ввести только одну команду, можно писать ее подряд за adb shell.
В шелле работают стандартные команды для копирования, перемещения и удаления файлов: cp, mv и rm. Можно менять каталоги (cd) и смотреть их содержимое (ls). Кроме стандартных Linux-команд, о которых можно узнать из любого справочника, в Android есть несколько своих специализированных инструментов, но, чтобы использовать некоторые из них, придется получить на смартфоне права root, а после запуска консоли выполнять команду su:
Вывод свободного пространства на устройстве командой adb shell df
Пример работы команды ls для вывода информации о разделах
Создание скриншота
Выполняется одной строчкой:
После этого картинку нужно выдернуть из устройства командой adb pull:
В recovery скриншот можно сделать следующей командой:
Затем необходимо преобразовать файл fb0 в нормальное изображение с помощью FFmpeg, который нужно скачать и положить в папку с adb. Расширение необходимо ставить своего устройства:
Управление приложениями
Для управления приложениями используются две команды: pm (package manager) — менеджер пакетов и am (activity manager) — менеджер активностей. У данных команд есть немало ключей, которые можно посмотреть на портале разработчиков. Остановимся на некоторых.
Для начала получим список установленных на устройстве приложений в виде названий пакетов, которые пригодятся позже:
Добавив в конец -s, ты увидишь только системные приложения, -3 — только сторонние, -f покажет пути установки пакетов, а -d — отключенные приложения. Далее, зная названия пакетов, можно совершать над ними различные насильственные действия :). Например, отключить ненужный календарь:
Ну а совсем удалить можно так:
Для использования activity manager понадобятся более глубокие знания структуры Android и понимание того, что такое Avtivity и Intent. Это позволит тебе запускать различные приложения, например браузер или настройки:
Завершить работу приложения можно противоположной командой:
Ну а убить все запущенные приложения — такой командой:
Тот же activity manager поможет сделать звонок на нужный номер телефона:
А так можно открыть страницу в браузере:
Запуск браузера из консоли
В данной команде input keyevent эмулирует нажатие кнопок и может использоваться как для хардварных, так и для кнопок внутри приложения. В нашем примере 22 соответствует перевод фокуса вправо (джойстик вправо — dpad right), а 66 — Enter.
С помощью команды input можно, например, разблокировать телефон. Для этого необходимо ввести:
Но данная команда не сработает на последних версиях Android. Для управления питанием и беспроводными коммуникациями там используется утилита svc. Например, включить передачу данных через мобильную сеть или управлять Wi-Fi можно через команды
Также можно заставить смартфон оставаться включенным при подключении к USB-порту/зарядке/Wi-Fi-сети или всегда:
Возвращаясь к команде input, стоит выделить еще одну команду для вставки текста в текущее поле. Кому-то это может показаться более привлекательным способом набора текста с компа, чем нажимать на кнопки небольшой области экрана. Выглядит команда так:
Кроме опции text, у команды input есть и другие. Полная форма команды такова:
В качестве источника можно указывать trackball, joystick, touchnavigation, mouse, keyboard, gamepad, touchpad, dpad, stylus, touchscreen. В качестве команд будут:
- text (Default: touchscreen) [delay]
- keyevent [–longpress] … (Default: keyboard)
- tap (Default: touchscreen)
- swipe [duration(ms)] (Default: touchscreen)
- press (Default: trackball)
- roll (Default: trackball)
Как видно из команд, можно, хотя и с трудом, управлять устройством через команды input touch и input swipe при разбитом экране, если не поддерживается работа мышки через USB-OTG. Например, вытянуть шторку с уведомлениями получится так (отсчет координат идет от левого верхнего угла):
А так можно узнать разрешение экрана:
Для Nexus 5 разрешение выдаст 1080 х 1920. Тогда нажать на кнопку «Меню приложений» стандартного лаунчера от Google, которая находится над кнопкой «Домой», можно так:
Скрипты
Снятие графического ключа, PIN, facelock
Допустим, ты забыл PIN или не совсем трезвым поставил графический ключ, ну или друзья пошутили и поставили распознавание по лицу. Так вот, если устройство по какой-то причине заблокировано, то блокировку можно снять (при условии включенной отладки по USB) через ту же консоль:
Команда удалит все пароли и графические ключи. Сами файлы в зависимости от прошивки и модели устройства могут быть: gesture.key, password.key, cm_gesture.key, personalpattern.key, personalbackuppin.key. Также за блокировку отвечают файлы locksettings.db, locksettings.db-shm, locksettings.db-wal.
После этого достаточно перегрузить устройство и ввести любой ключ, пароль. Если это не помогает, можно попробовать следующее:
Автозапуск
Другой популярный способ автозапуска — это использование средств автоматического исполнения скриптов при загрузке в сторонних прошивках. Сегодня почти все сколько-нибудь известные кастомные прошивки умеют стартовать скрипты из каталога /system/etc/init.d/, а в стоке такую функциональность можно получить с помощью приложения Universal init.d из маркета. С последним, однако, надо быть осторожным, так как оно запускает скрипты не на раннем этапе загрузки, как это происходит в том же CyanogenMod, а уже после полной загрузки системы.
Итак, что мы можем поместить в автозагрузку? Например, скрипт запуска демона ADB в сетевом режиме:
Для подключения к нему с ПК набираем такую команду:
Также мы можем применить некоторые оптимизации подсистемы виртуальной памяти:
Ну или подогнать механизм lowmemorykiller (автоматическое убийство фоновых приложений при нехватке памяти) под наши нужды:
Ну и конечно же, автоматический выбор планировщика процессов:
Все это можно сделать с помощью специализированного софта, но зачем загружать систему дополнительным ПО, которое еще и будет висеть в фоне, когда можно обойтись несколькими простыми скриптами?
Как запустить скрипт с помощью Tasker
Итоги
Эта статья лишь краткое введение в методы вскрытия и модификации Android-приложений. За кадром остались многие вопросы, такие как снятие защиты, разбор обфусцированного кода, перевод и замена ресурсов приложения, а также модификация приложений, написанных с использованием Android NDK. Однако, имея базовые знания, разобраться во всем этом — лишь вопрос времени.
Android основан на ядре Linux, включает в себя набор стандартных UNIX-команд и простой шелл sh. Все это значит, что мы можем не только использовать командную строку для выполнения низкоуровневых операций, но и писать шелл-скрипты, которые будут выполнять функции, недоступные из графического интерфейса. В этой статье мы поговорим о том, что с их помощью можно сделать и зачем все это нужно.
Для прошлого номера журнала я написал статью о Tasker — системе, которая позволяет автоматизировать работу Android и заменить сотни сторонних приложений. К сожалению, Tasker ограничен высокоуровневыми функциями Android и не позволяет выполнять такие низкоуровневые операции, как монтирование файловых систем, изменение параметров ядра, системных переменных или запуск демонов. Зато все это можно сделать с помощью скриптов.
Сразу оговорюсь, что в этой статье речь пойдет о шелл-скриптах в традиционном для Linux понимании, без использования инструментов вроде SL4A, QPython или Roboto. Главное назначение таких скриптов — изменение поведения системы, параметров ядра, работа с демонами (ADB, например) и тому подобное. Скрипты могут стартовать на этапе загрузки ОС, установки новой прошивки, после тапа по кнопке или же по традиции — из терминала.
В статье я расскажу, как писать такие скрипты, как заставить их стартовать автоматически, привязывать к определенному системному событию. В качестве бонуса также объясню, как заставить консоль восстановления (recovery) выполнить необходимые тебе действия перед установкой или сразу после установки новой прошивки. Начинаем.
Основы работы с ADB
Для начала работы с ADB его следует активировать на устройстве и установить утилиту adb и драйверы на комп. Первая задача выполняется с помощью включения «Отладки по USB» в пункте настроек «Для разработчиков» (если этот пункт скрыт, нажми семь раз на номер сборки в меню «О телефоне»).
Для установки ADB на комп качаем Adb Kit и распаковываем в любую папку (рекомендую использовать названия папок без русских символов). Также скачиваем и устанавливаем драйверы ADB.
Работать с adb нужно из командной строки. Нажимаем Win + R и вводим cmd, далее переходим в папку, в которой лежит adb. Для моей папки команда будет следующей:
Чтобы не проделывать все эти манипуляции каждый раз, можно добавить нужную папку в переменную Path. Для этого необходимо зайти в «Панель управления -> Система -> Дополнительные параметры системы -> Переменные среды», найти переменную Path и добавить в конец строки, через точку с запятой, путь до папки с adb. Теперь после запуска консоли можно сразу вводить необходимые команды.
Добавление adb в переменную Path
Проверим наше подключение к телефону с помощью следующей команды (она должна вывести список подключенных устройств):
С ADB можно работать через Wi-Fi. Для этого нужны права root и приложение WiFi ADB. Запускаем приложение, жмем переключатель и подсоединяемся к смартфону с помощью команды connect и показанного приложением IP-адреса:
Далее работа с ADB ничем не отличается.
Скопировать вывод консоли после выделения мышкой, а также вставить скопированную команду или имя файла в консоль можно правой кнопкой мыши. Включается в свойствах консоли.
Введение
В этой статье мы поговорим о том, как разобрать пакет APK с приложением, рассмотрим его внутреннюю структуру, дизассемблируем и декомпилируем байт-код, а также попробуем внести в приложения несколько изменений, которые могут принести нам ту или иную выгоду.
Чтобы сделать все это самостоятельно, потребуются хотя бы начальные знания языка Java, на котором пишутся приложения для Android, и языка XML, который используется в Android повсеместно — от описания самого приложения и его прав доступа до хранения строк, которые будут выведены на экран. Также понадобится умение обращаться со специализированным консольным софтом.
Итак, что же представляет собой пакет APK, в котором распространяется абсолютно весь софт для Android?
Декомпиляция приложений
В статье мы работали только с дизассемблированным кодом приложения, однако если в большие приложения вносить более серьезные изменения, разобраться в коде smali будет гораздо сложнее. К счастью, мы можем декомпилировать код dex в Java-код, который будет хоть и не оригинальным и не компилируемым обратно, но гораздо более легким для чтения и понимания логики работы приложения. Чтобы сделать это, нам понадобятся два инструмента:
Использовать их следует так. Сначала запускаем dex2jar, указывая в качестве аргумента путь до apk-пакета:
В результате в текущем каталоге появится Java-пакет mail.jar, который уже можно открыть в jd-gui для просмотра Java-кода.
Особенности Android-окружения
В самой своей основе, там, где нет Java и Dalvik, Android представляет собой минималистичный Linux-дистрибутив со всеми свойственными ему атрибутами: ядром, системой инициализации, набором библиотек, демонов, консольных команд и, конечно же, шеллом. Последний — это не что иное, как mksh из MirBSD, переименованный в sh; простой командный интерпретатор с поддержкой языковых конструкций классического Bourne shell из UNIX и автодополнением по нажатию Tab.
В качестве комплекта базовых UNIX-команд здесь используется toolbox, своего рода урезанная альтернатива BusyBox, которая позволяет вызывать несколько разных команд из одного бинарника (с помощью симлинков). Toolbox включает в себя очень ограниченный набор команд, в котором нет не только grep или sort, но даже cp. Поэтому для полноценной работы со скриптами настоятельно рекомендуется установка BusyBox, благо в маркете полно бесплатных инсталляторов.
Основное назначение скриптинга в Android — работа с ядром и системными утилитами. Ядро тут стандартное и экспортирует все те же интерфейсы /proc и /sys, через которые можно рулить железом и состоянием системы. Плюс есть набор специфичных для Android утилит, которые будут очень полезны при разработке скриптов:
- pm — менеджер пакетов, позволяет устанавливать, удалять и перемещать софт;
- am — менеджер активностей (Activity), может быть использован для запуска приложений;
- dumpsys — дамп в консоль массы различной информации о состоянии системы;
- screencap — утилита для снятия скриншота;
- screenrecord — утилита для записи скринкастов;
- getprop/setprop — команды для чтения и изменения системных переменных;
- start/stop — запуск и остановка системных служб;
- input — позволяет отправлять в текущее окно кей-коды (эмуляция клавиатуры);
- service — утилита для управления Java-сервисами, имеет очень много возможностей;
- svc — позволяет управлять Wi-Fi, USB-подключением и питанием.
Другие статьи в выпуске:
Запуск скриптов до и после установки прошивки
Почти каждый, кто устанавливает на свой гаджет стороннюю прошивку, также ставит поверх нее пакет с фирменными приложениями Google (gapps), который включает в себя маркет, YouTube, Gmail и другой софт. Каждый раз, когда происходит обновление прошивки, раздел /system, содержащий ее и gapps, полностью стирается, но приложения Google всегда остаются на месте. Это происходит потому, что, кроме всего прочего, gapps содержит в своем составе специальный скрипт, который размещается в каталоге /system/addon.d/ и запускается консолью восстановления до и после установки прошивки. Этот скрипт делает бэкап и восстановление приложений Google.
Мы можем использовать эту возможность для выполнения наших собственных действий до и после установки прошивки. Вот так, например, выглядит мой скрипт восстановления, который ничего не бэкапит, но подчищает прошивку от мусора сразу после ее установки:
Скрипт удаляет рингтоны, уведомления, движок синтеза речи и несколько приложений. Все эти действия запускаются в ответ на передачу скрипту опции командной строки restore (это делает консоль восстановления после установки прошивки), однако также предусмотрены и варианты обработки таких опций, как backup, pre-backup, post-backup, pre-restore и post-restore. Здесь это просто заглушки, но если бы мы захотели сделать бэкап некоторых файлов и приложений перед установкой прошивки, мы могли бы добавить их в блок backup, как это сделано в скрипте /system/addon.d/70-gapps.sh:
Этот кусок скрипта прекрасно иллюстрирует, как сделать бэкап файлов. Ключевые элементы здесь: функция listfiles, которая при запуске выводит листинг файлов, и функция backupfile, которая является частью консоли восстановления (определена в файле /tmp/backuptool.functions). Она делает бэкап файлов в цикле.
Содержимое /system/addon.d/ в CyanogenMod 11 на Motorola Defy
Скрипт бэкапа приложений Google
По словам разработчика mksh, изначально пользовательские версии Android-смартфонов вообще не должны были иметь в своем составе шелл, но после выпуска смартфона для разработчиков HTC (T-Mobile) G1 он фактически стал стандартной частью системы.
Версии Android 2.3 и ниже вместо mksh использовали минималистичный шелл ash, который входит в базовый комплект всех BSD-систем.
Чтобы получить одни и те же скрипты на всех устройствах, можно использовать приложение DropSync или FolderSync (автоматическая синхронизация через Dropbox).
Снятие логов
После этого можно запускать проблемное приложение и смотреть, что именно вызывает ошибку. Также поддерживается вывод информации из альтернативных буферов. Этим способом можно посмотреть, что приложения делают в фоне и, например, какие события происходят после включения экрана:
Вывод команды adb logcat -b events
Устройство 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
Другие статьи в выпуске:
Бэкап приложений
В Android есть встроенные функции бэкапа, которые также можно запустить с помощью командной строки. Для этого используется команда adb backup и набор опций:
- -f указывает имя создаваемого файла и его расположение на компе. При отсутствии ключа будет создан файл backup.ab в текущем каталоге;
- -apk|-noapk указывает, включать ли в бэкап только данные приложения или сам .apk тоже (по умолчанию не включает);
- -obb|-noobb указывает, включать ли в бэкап расширения .obb для приложений (по умолчанию не включает);
- -shared|-noshared указывает, включать ли в бэкап содержимое приложения на SD-карте (по умолчанию не включает);
- -all указывает на необходимость бэкапа всех установленных приложений;
- -system|-nosystem указывает, включать ли в бэкап системные приложения (по умолчанию включает);
Если мы хотим создать бэкап всех несистемных прог, включая сами .apk, в определенное место, то команда будет выглядеть так:
После ввода необходимо подтвердить начало выполнения бэкапа на самом устройстве. Для восстановления полученного бэкапа нужно выполнить соответствующую команду:
Процесс бэкапа
Препарирование. Отключаем рекламу
Теория — это, конечно, хорошо, но зачем она нужна, если мы не знаем, что делать с распакованным пакетом? Попробуем применить теорию с пользой для себя, а именно модифицируем какую-нибудь софтину так, чтобы она не показывала нам рекламу. Для примера пусть это будет 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
Выводы
Как видишь, с помощью ADB можно сделать много интересного. И чем больше пользуешься консолью, тем быстрее можно выполнить некоторые действия без установки дополнительного софта на устройство. Надеюсь, данная статья помогла разобраться с ADB и подтолкнула к чтению документации и поиску новых полезных команд.
Иногда некоторые приложения на Android чем-то не устраивают пользователя. В качестве примера можно привести назойливую рекламу. А то бывает и так — всем хороша программа, да только перевод в ней или кривой, или вовсе отсутствует. Или, например, программа триальная, а получить полную версию возможности нет. Как же изменить ситуацию?
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;
- пример снятия триала с приложения.
Евгений Зобнин
Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.
Читайте также: