Дмитрий Мячин
Здесь находятся инструменты для сборки горстей текста, картинок, музыки, кода, библиотек и волшебной пыльцы в единый apk-файл и около того. Но для тестировщика тут есть полезный инструмент, который пригодится для быстрого получения некоторых данных из .apk.
Прежде чем о нём рассказать, я скажу в общих чертах о структуре apk-файла. Хотя бы для того, чтобы вы не растерялись, когда заглянете в него сами. Как уже было сказано ранее, .apk — это просто zip-архив. Внутри него нам чаще всего интересны следующие папки:
Аssets. Здесь обычно лежат различные ресурсы, которые используются не для правильного отображения интерфейса на правильных языках, а просто вспомогательные, нужные для нормальной работы. Например, ini-файлы, собственные шрифты, открытые криптографические ключи и всякое такое
Lib. Здесь у людей, которые ещё не лишились остатков разума, хранятся библиотеки функций.
META-INF. Место хранения подписи. Все apk-файлы подписаны электронной цифровой подписью, подтверждающей целостность файла и принадлежность приложения владельцу. Любое изменение внутри apk-файла делает подпись невалидной. Android откажется установить такое приложение, выбросив соответствующее исключение. Также Android откажется установить одно приложение поверх другого, если у них одинаковое внутреннее имя, но разные подписи. Если же внутренние имена пакетов (их, кстати, можно найти в AndroidManifest.xml) и подписи совпадают, то только тогда возможен апгрейд. Это позволяет избежать ситуации, когда поддельное приложение пытается подменить собою настоящее. Так как модифицировать приложение в тестовых целях приходится десятки раз в день, то приходится постоянно переподписывать итоговые .apk. В тестовых целях «боевые» подписи использовать строго не рекомендуется!
Res. Здесь хранятся все ресурсы приложения — картинки, звуки, тексты, оффлайн-справки. Текстовые ресурсы сгруппированы по языкам, графические — по видам экранов.
AndroidManifest.xml. Об этом файле рассказывалось раньше. Сейчас нам нужно узнать другое. Этот файл представляет собой бинарный XML. То есть его нельзя просто взять и открыть в Notepad++ и почитать на ночь.
Сlasses*.dex. Здесь находится весь программный код продукта. Под декомпиляцией apk-файла подразумевается декомпиляция именно этого файла. Обычно файл classes.dex всего один. Но в Android есть некоторые ограничения на количество используемых методов — максимум шестьдесят пять тысяч пятьсот… Кто догадается про последние две цифры? В общем, максимум 65536 методов на один dex-файл.
Что важно. Речь не об определённых вами методах, а о тех, на которые вы можете сослаться. То есть вы можете подключить библиотеку ради одного метода «сделать хорошо», а она с собой тянет ещё 50 тысяч, которые вы никогда не используете и вообще вам не нужны. Однако счётчик они накрутят! Best practics говорит, что нечего подключать библиотеки почём зря. Но кто же их слушает, правда? Кто такие Google с их best practics? Вместо этого можно использовать больше файлов classes.dex, нумеруя их. Android обрабатывает эту ситуацию и не спотыкается. Ещё есть обфускаторы, которые для своих целей дробят classes.dex на кучу файлов по своим причинам. Dex, кстати, это привет из прошлого и означает «Dalvik executable», то есть формат, исполняемый виртуальной машиной Dalvik. С переходом на ART никто ничего не переименовывал во имя обратной совместимости
Resources.arsc. Здесь можно найти ссылки на все ресурсы приложения, которые живут в res. Здесь же можно найти все текстовые строки, надписи с кнопок и подобное. Не особо-то это нужно в повседневности, но пусть будет. Этот файл также нельзя прочесть как текст, но получить из него и из AndroidManifest.xml данные можно похожим образом, одним и тем же инструментом — AAPT.
AAPT
Aapt.exe — утилита, которая используется для выковыривания некоторых данных из приложения. То есть это тестировщики используют её для разбора, а вообще это Android Asset Packing Tool и с её помощью код и ресурсы собираются в единый apk-файл. Но у этой утилиты есть параметры запуска, которыми можно модифицировать apk-файлы без привлечения внешних архиваторов и, что важно, получать некоторую информацию. Узнать, какие разрешения использует приложение, убедиться, что строка «Папа у Васи силён в математике» была удалена, узнать минимальную версию API, посмотреть внутреннее имя пакета и его версию и всё такое прочее можно одной командой, прочитав нужный файл AndroidManifest.xml или resources.arsc (и не только их можно читать, понятное дело). На выходе вы получите незашифрованный текст, с которым реально работать.
Как выглядят реальные примеры использования этой утилиты?
Вам нужно убедиться, что новая версия приложения не может быть затёрта более старой версией. Этим занимается сам Android, отслеживая внутренний номер версии, который вообще никакого отношения к версии продукта, к его «билду», не имеет. Значение параметра «version code»отслеживается инсталлятором приложений Android. Если между файлами A.apk и B.apk этот параметр имеет одно и тоже значение, то версии могут быть установлены друг поверх друга в любом порядке. Если у B.apk значение числа в этом параметре будет больше, то B можно будет установить поверх A, а наоборот — нет. Если параметра вообще не будет, то в Market приложение залить будет нельзя. Впрочем, Market вообще хорошо следит за этим параметром и не даст залить ту же самую версию или версию ниже.
Вы получили на тестирование чёрный ящик. Так как это Android, то довольно много всего полезного вы всё равно можете добыть, сделав из чёрного ящика такой, мутно-серый. Много чего полезного с приложением можно сделать из командной строки через adb. Но почти всегда для этого нужно знать внутреннее имя приложения, оно же package name (это имя уникально для Play Store и самого устройства) и названия операций (активити) этого приложения. Например, зная имя пакета и названия операций, вы можете сделать прямой вызов любого из них (ну, не любого, а тех, у которых установлен флаг exported, который по умолчанию обычно установлен) и посмотреть, что же получится. Если это, скажем, приложение программы лояльности KFC, то его падение не является какой-то проблемой. Если это защитное приложение (антивирус, антивор, родительский контроль и всё в таком духе), то ни о каких падениях говорить недопустимо, потому что стороннее приложение точно также сможет обратиться к «больному» месту (использовать эту точку входа) и уронить продукт.
Вам нужно убедиться, что некая строка заменена на другую. Безусловно, нужно её вызвать в продукте по сценарию. Но если весь продукт не менялся и изменение было строго в ресурсах и заключалось в исправлении опечатки, можно отфильтровать вывод этой утилиты, запущенной с нужными параметрами, и посмотреть, что вернёт фильтрация.
Zipalign
Есть такая утилита. Для тестирования она не нужна, получить с её помощью ничего нельзя. Однако она востребована, если вы что-то меняли в apk-файле. Cуть в том, что она располагает все ресурсы так, чтобы, при распаковывании приложений в память, они располагались наиболее удачным образом, не отжирая память попусту. Без неё приложение после ваших модификаций может заваливать тесты производительности и виноваты будете вы сами.
Platform Tools
Это случилось. Мы дошли до тестирования, наконец! Здесь я расскажу, что такое и для чего используется ADB — лучший друг Android-тестировщика.
Что такое ADB
ADB — Android Debug Bridge — это консольная многофункциональная утилита, которая позволяет подключаться к запущенному эмулятору или подключенному в режиме отладки устройству и взаимодействовать с ним. Состоит ADB из трёх компонентов:
Клиент. Это сам exe-файл, который мы запускаем с нужными командами и ключами команд, получая в ответ некоторый результат.
Сервер. Сервер также работает на вашей машине. Клиент взаимодействует с устройством или эмулятором через сервер. Чтобы каждый раз не поднимать сервер, первый запуск клиента автоматически его запускает, и он будет работать, пока вы вручную его не остановите. Остановить можно как штатной командой adb kill-server, так и просто отстрелив его системным диспетчером задач или командой taskkill. Если сервер остановлен, и вы хотите, чтобы команды исполнялись сразу в вашем тестовом сценарии, то сделайте предварительный запуск сервиса командой adb start-server. Запуск monitor также поднимает сервер.
Демон. Он работает на устройстве или эмуляторе. Вы сами не имеете к нему никакого отношения, он является частью прошивки
Одна из прелестей сервера в том, что он может одновременно работать с несколькими устройствами. Вообще, сервер ожидает устройства в диапазоне портов 5555-5585. Запоминать эти цифры бессмысленно, во-первых, потому, что всё несколько сложнее (например, сервер сканирует только нечётные номера из диапазона), во-вторых, вы всё равно не будете использовать больше десяти устройств одновременно даже в худшие из времён. Мой максимум — тестирование на восьми устройствах одновременно.
Это не значит, что больше десятка устройств одновременно у вас никогда не будет. Это я про тестирование из консоли сказал. А вообще, одновременная проверка какой-то проблемы на нескольких десятках устройств — это не что-то невероятное, такое случается.
К слову, если у вас подключено одновременно более одного устройства, то выполнение «adb command» вернёт ожидаемую ошибку о том, что непонятно, к какому из устройств обращаются. Потому, кроме прочего, у ADB есть команда devices, которая возвращает список устройств по их серийникам (что берётся в качестве Serial Id нам не важно, пусть они хоть от солнечных солнечных вспышек генерируются), указывая для каждого из них, доступно ли оно, реальное ли это устройство или эмулятор. Но о командах ниже.
Включение отладки через ADB
Возможности управления устройством через ADB очень широки и многие из них опасны. К примеру, ни одно приложение в AOSP и в тех кастомах, которые не сильно испорчены производителями, не имеет привилегии взять и перезагрузить устройство из своей песочницы. А команда adb reboot мгновенно отправит устройство на перезагрузку, не запрашивая никаких подтверждений. Через ADB можно останавливать приложения, а не только прибивать их. В AOSP и несломанных кастомах остановка приложений дозволена только пользователю через графический интерфейс. Возможностей, которые даёт ADB, очень много. И так как с точки зрения безопасности это большая дырка, то Google сознательно некоторые вещи усложняет.
Android 2.1-2.3
Эти версии Android уже практически никто не поддерживает, так что просто историческая справка. Нужно было зайти в настройки, пункт «Приложения» и там поставить галку «Разрешить отладку через USB». Что это такое — нигде особо не пояснялось.
Android 3.0-4.1
Включение режима отладки по USB вынесли в отдельный пункт в настройках, который называется «Developer options» или «Инструменты разработчика». Именно во множественном числе, так как появилась возможность не только разрешать отладку через USB (и, кстати, по Wi-Fi), но и включать специальные режимы работы Android, которые по умолчанию выключены, а сюда были вынесены для тех разработчиков, которые понимают, что пункты эти возникли не просто так, что в будущем они станут настройками по умолчанию, а сейчас просто есть возможность протестировать поведение продукта. К примеру, появилась возможность использовать графический ускоритель для отрисовки интерфейса. А в Android 4.4 здесь добавился пункт, позволяющий перейти на конкретном устройстве с Dalvik на ART, причем за несколько месяцев до появления Android 5.
Android 4.2-4.2.1
Первое из двух серьёзных улучшений с точки зрения безопасности. Если ранее Developer options был виден любому человеку и любой мог его включить, открыв таким образом дырку в безопасности (шутка про «хоть что-то у нас в безопасности»), то в 4.2 пункт «Инструменты разработчика» исчез. Его не было в интерфейсе. Чтобы он появился, нужно зайти в настройки системы, выбрать пункт «Об устройстве», найти там строку «Версия сборки» и несколько раз тапнуть по ней. На тапы будут появляться сообщения, что осталось столько-то раз, а потом «Вы уже разработчик». Только после этого пункт «Инструменты разработчика» появлялся на старом месте, и можно было разрешить отладку по USB. Прямого метода скрытия пункта нет. Предполагается, что раз уж человек проделал такой путь, то он понимает, что делает.
Android 4.2.2
Второе и самое важное изменение в системе безопасности. Теперь, кроме прочего, нужно разрешить конкретному компьютеру подключаться именно к этому устройству. Как только ADB-сервер попытается установить подключение к демону на устройстве, система выдаст запрос, можно ли внешнему устройству подключаться для отладки.
Если устройство заблокировано под паролем, то этот запрос системы возникнет под экраном блокировки. То есть если в Android 4.2.1 и ниже пользователь включил режим отладки, то любой злоумышленник, получив физический доступ к устройству, мог работать с ним через ADB, минуя блокировку. Начиная с Android 4.2.2 это стало невозможно.
Android 6
Если устройство заблокировано, то по умолчанию к нему нельзя подключиться, так как демон просто не будет отвечать на запросы, потому что все подключения по USB считаются зарядкой и ADB-сервер снаружи никто не ждёт, для начала Нужно перевести устройство в режим MTP.
Продолжение следует
