Android что такое debug test

Factory Mode — как сбросить настройки?

Иногда во время работы смартфона может появиться непонятное меню на английском или китайском языке. Оно называется Factory Mode. Эта статья расскажет о том, что это такое, зачем оно нужно и как из него выйти.

Что такое и зачем нужен Factory Mode

Второе название – Factorykit test. На русский язык эту функцию можно перевести как «заводской режим». Это часть прошивки смартфона на «Андроид», позволяющая вручную проверить работоспособность компонентов устройства перед загрузкой системы.

Вход в Factory Mode

Рассматриваемых режим запускается в 2 случаях: самостоятельно при невозможности загрузки системы из-за повреждения необходимых файлов и системного раздела целиком (обычно после неудачной перепрошивки) и по требованию пользователя.

Во втором случае запустить заводской режим можно, в зависимости от модели смартфона одним из 2 способов:

• Зажать на 10-15 секунд клавиши питания и увеличения/ уменьшения громкости.
• Зажать на 10-15 секунд кнопки питания, «Домой» и увеличения/ уменьшения громкости.

Для каждого телефона предусмотрена своя комбинация и поэтому следует попробовать оба варианта.

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

Функции Factory Mode

После входа в factory mode на экране отобразится главное меню, состоящее из 5-12 пунктов. Для навигации используются кнопки громкости (вверх-вниз) и питания («Выбрать»).

Расшифровка наиболее часто встречающихся пунктов меню:

• Clear eMMC – откат устройства к заводским настройкам. Идентичен функции Wipe data или Facory reset в рекавери.
• Debug Test – режим отладки.
• Essential Test: базовая проверка устройства.
• Full test или Auto test: проверка всех систем и подсистем.
• GPS: проверка модуля GPS.
• Item Test: проверка отдельного модуля.
• Reboot: перезагрузка в операционную систему.
• Signaling Test: проверка модуля связи GSM.
• Test Report – напоминание о проверке.

Результаты тестов выводятся посредством 2 сообщений: pass (удачно) и fail (провал).

Выход из Factory Mode

Чтобы выйти из factory mode нужно:

1. Выбрать строчку «Reboot».
2. Дождаться загрузки в систему.

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

Подводя итог, можно сказать, что заводской режим – полезная функция, позволяющая проверить состояние устройства. Пугаться появления ее меню не нужно, обычно это происходит случайно. Чтобы выйти из этого режима достаточно в меню выбрать пункт «Reboot».

Источник

Factory Mode на андроиде — что делать, если случайно зашел

Операционная система андроид предоставляет гораздо большие возможности и функции, чем кажется. Простой пользователь видит лишь верхушку айсберга, те настройки, которые скрыты далеко, ему неподвластны. Большинство людей не пользуется даже третьей частью от всех тех возможностей, которые предоставляет их телефон. В этом материале будет рассмотрен Factory Mode на андроиде, что это и какие тесты аппаратной части устройства он предполагает.

Что такое Factory Mode на андроиде

Factory Mode в переводе с английского дословно означает «фабричный режим». Также его называют «заводским режимом». Он имеет ряд кардинальных отличий от всеми известного Recovery Mode, который предназначен для восстановления телефона, его перепрошивки и очитки кэша или всех данных.

Внешний вид обычного фактори моде

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

К сведению! Заводской режим, как и рекавери, состоит из пунктов меню, перемещаться по которым необходимо с помощью клавиш увеличения и уменьшения громкости. Выбор происходит путем нажатия кнопки «Питание». Количество пунктов меню зависит от модели и производителя.

Заводское меню тестирования на разных телефонах выглядит по-разному

Как войти в Factory Mode на андроиде

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

Если в телефоне человека есть фактори мод, то наиболее вероятно, что он запускается:

• путем нажатия на кнопки «Питание» и «Увеличение громкости звучания»;
• нажатием на кнопку «Питание» и клавишу «Уменьшение громкости звучания»;
• одновременным нажатием клавиш «Питание», «Увеличение громкости» и «Уменьшение громкости».

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

Распространенная комбинация входа в режим

Что делать, если случайно вошел в режим тестирования на андроиде: как выйти

Иногда можно непроизвольно войти в Factory Mode на андроиде, что делать в такой ситуации? На самом деле все очень просто, пугаться не стоит, но и нажимать на все подряд не следует. Так можно изменить какие-нибудь важные настройки или попросту испугаться громкого писка, включив тестирование звукового модуля.

Обычно внизу списка есть пункт Reboot. Он есть везде и не зависит от версии операционной системы, производителя устройства или его модели. Переводится он как «Перезагрузка». Необходимо просто выбрать его, пройдя все пункты с помощью кнопки «Уменьшение громкости» и нажать на «Питание». Телефон автоматически перезагрузится и запустится в обычном режиме.

Обратите внимание! Часто люди случайно переходят в Factory Mode, когда нажимают не только кнопку включения, но и панель громкости при подаче питания одной рукой.

Выход из фактори мода путем выбора пункта «Reboot»

Виды тестов в Factory Mode на андроиде

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

Не все знакомы с Factory Test Android, что это и для чего нужно. Заводские режимы для тестов могут существенно отличаться друг от друга не только на основе различий в релизе и версии операционной системы, но и в связи с требованиями к программным и аппаратным средствам конкретного производителя. Основными тестами в Factory Mode являются:

• Auto Test;
• Manual Test;
• Debug Test;
• Clear eMMC Android;
• PCBA Test Android;
• Check if Root or Not.

Необходимо более подробно рассмотреть каждый вид.

Для чего нужен Auto Test

Авто тест — это самый главный и общий тест, при котором будут протестированы основные функции телефона. Он по максимуму пройдется по всей аппаратной части смартфона или планшета и проверит на работоспособность все доступные модули.

Важно! Именно этот тест необходимо делать, если производится простая и общая диагностика устройства. Просто так в фабричный режим не заходят, а полное сканирование позволит проверить все доступные модули на работоспособность.

Manual Test

Аналог Full Test или Auto Test, который выполняет такую же проверку тех или иных средств и модулей гаджета, выясняя, какие из них работают корректно, а какие подлежат замене или вообще не откликаются на запрос.

Clear eMMC Android — что это

Не все знакомы и с параметром Clear Emmc Android, что это и как работает. На самом деле все очень просто. Это сброс данных (кэша и прочих настроек). Он работает аналогично стандартным функциям «Очистка кэша» и «Сброс настроек до заводских параметров», которые доступны в соответствующем разделе приложения «Настройки».

Аналог этого пункта можно найти в рекавери под названием «wipe data/factory reset». Также он может называться «Clear Flash».

Важно! Следует внимательно относиться к этой функции и не нажимать на нее. В противном случае все данные с телефона будут удалены.

Процесс загрузи Factory Mode

Что такое Debug Test

Debug Test представляет собой процесс входа в режим отладки и начало проверки на наличие ошибок с их дальнейшим исправлением. В нем можно пройтись по всем проблемам операционной системы андроид и решить их по возможности.

PCBA Test Android — что это

Еще один пункт в фабричном меню, предназначение которого заключается в калибровке датчика движения и приближения, встроенного в переднюю панель корпуса гаджета. Также он может называться «Device PCBA Calibration», но от изменения наименования суть работы не меняется. Процессор и ряд других модулей проверят датчик на работоспособность и откалибруют его в соответствии со стандартными настройками.

Check if Root or Not

Некоторые производители также добавляют в свой фактори моде специальный раздел под названием «Check if Root or Not». Из этого остановится понятно, что весь его функционал направлен на определение, есть ли на данном мобильном устройстве права и привилегии суперпользователя или нет.

Большинство платных и бесплатных программ для проверки наличия рут-прав, которые можно найти или купить в официальном магазине Google Play Market или на сторонних ресурсах, чаще всего используют уже встроенный в систему функционал и преподносят его в более приемлемом для большинства пользователей интерфейсе.

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

Очитка данных через специальный пункт «Wipe data»

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

Источник

Отладка native-кода под Android: ручное и автоматизированное тестирование

С развитием и ростом популярности ОС Android количество и разнообразие устройств под её управлением неуклонно растёт. Из-за различий в архитектуре, предназначении и оптимизации скорость и стабильность работы исполняемого кода может значительно изменяться. Поэтому, для обеспечения стабильности и оптимизации работы приложений и ОС, особенно использующих особенности конкретной архитектуры, платформы, или кода, портированного с других платформ, стоит особо внимание уделить процессу отладки кода под Андроид. В этой статье пойдёт речь о ключевых моментах и особенностях работы с native-кодом под Android. Всем, кому интересен этот мануал, прошу под кат.

В далёком 2007 году корпорация Google выпустила операционную систему нового поколения – Android.

Её появление совершило настоящую революцию на рынке мобильных устройств, подавив гегемонию Microsoft Widows Mobile, Apple iOS и Symbian OS, в последствие став самой популярной и массовой операционной системой для мобильных систем в мире. До сих пор рост популярности системы продолжается. За прошедшие шесть лет Android очень сильно разросся и развился, и спектр поддерживаемых устройств продолжает увеличиваться. Теперь это операционная система используется не только в мобильных телефонах, но также и в планшетах, телевизорах, плеерах, фотоаппаратах, ноутбуках, неттопах и прочих экзотических вещах, вплоть до военной техники. Начинки этих устройств могут весьма заметно отличаться друг от друга: за прошедшие годы перечень поддерживаемых архитектур расширился с ARM до MIPS и х86, появилась поддержка различной периферии, не говоря о непременно развивающемся Android API.

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

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

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

Тем не менее, одним из самых удобных инструментов для разработчика Android до сих пор является пакет Android NDK – Android Native Development Kit, включающий в себя почти всё необходимое для разработки и отладки приложений, библиотек и самой системы.

В данной статье я рассмотрю его использование для тестирования и отладки native-кода Android и автоматизацию тестирования на примере такого фреймворка, как DejaGnu.
Android развивается очень динамично, и теперь в поставку DejaGnu входит почти что всё необходимое для быстрого старта тестирования – как с Android NDK, так и без него. Главной задачей данной статьи будет рассказ о нюансах и особенностях тестирования под Android и некоторых подводных камнях, с которыми могут столкнуться инженеры.

Для начала небольшая ремарка: Android, как известно, является Unix-like операционной системой, очень схожей с обычным Linux или BSD, и большинство исходного кода Android следует лицензии, ASL2.0. Кто работал с Android, знает, что немалое количество модулей Android перешли из BSD в большей степени, чем из Linux. Тем не менее, всё, что касается native-кода и архитектуры, если не вдаваться в подробности, очень близко и известно всем тем, кто использовал Linux. Поэтому для разработки и отладки кода вполне возможно использовать точно такие же или схожие инструменты, что и для Unix-like систем. В случае компиляторов – это gcc, clang (llvm), icc и прочие. То же самое можно сказать и насчёт всего GCC toolchain и некоторых других утилит, которые либо уже портированы, либо портировать не так сложно.

Главной причиной включения в приложение native-кода или использования native-библиотек, native-исполнимых файлов является стремление увеличить производительность или переиспользовать ранее написанный код C/C++/ASM с Linux/Unix-like систем.

Преимущества использования native-кода:
• Высокая производительность
• Прямое использование CPU/HW особенностей
• Возможность переиспользования существующего Linux кода

Недостатки использования native-кода:
• Индивидуальная настройка под CPU/HW
• Недостаточная поддержка системных библиотек

Плюсы и минусы требуют тщательного тестирования, как по качеству кода, стабильности, так и по его производительности на разных платформах. Несмотря на то, что одним из постулатов Android является независимость от железа, для обеспечения работы на различных конфигурациях, в действительно приложения с native-кодом поставляются в так называемых fat binary (apk, включающие в себя native-код/библиотеки для всех возможных конфигураций оборудования, под которым будет работать приложение). Несмотря на то, что в идеале NDK компилятор должен создавать функционально равнозначный код для различных конфигураций и, следовательно, библиотеки для fat binary (или системные – для образа) должны быть равнозначными — это, к сожалению, не всегда соответствует действительности и требует проверки, особенно когда дело касается оптимизации (Neon и SSE например) и использования сторонних библиотек.

Кроме того, с развитием ОС Android и устройств под её управлением, закономерно меняются различные версии ОС, поставка этой ОС, а так же специфика устройств. В некоторых случаях для разработчика оправдано использование каких-то оптимизаций или иного компилятора для сборки native-кода. Оценка производительности, правильности и стабильности этого кода на различных конфигурациях – задача тестировщика, занимающегося Android Native тестированием.
Процесс сборки, отладки и тестирования native приложений под Android не сильно отличается от того же процесса на Linux, с единственной разницей, что мы собираем бинарные файлы (исполнимые и библиотеки) не в Android, а на хосте (Linux, MacOS, Windows) и исполняем на устройстве Android (физическом или эмуляторе). Поэтому универсальным средством коммуникации хоста с устройством под управлением Android является adb – Android Debug Bridge, входящий в состав Android SDK. Для сборки и отладки приложений целесообразно использовать тот toolchain и API, который нам нужен, а так же, при необходимости (для c++), интересующую нас версию библиотеки stdc++.

Native-сборка Android может различаться по:

версиям используемого API:

Впрочем, с точки зрения разработчика и тестировщика, различий между получаемым кодом в зависимости от билд-хоста быть не должно, и использовать для проверки и тестирования различные конфигурации билд-хостов вовсе не обязательно.
Количество вариантов для тестирования угрожающе разрастается, и это не беря в расчёт оптимизации по CPU инструкциям: neon, core-avx2, core-i7, atom, slm; по размеру\скорости и прочие. Все это декартово произведение вариантов полученного кода (исходного и бинарного) является отправной точкой для тестирования. В случае же, когда целью тестирования является само устройство или какой-то кастомная сборка Android, то, вполне вероятно, главным весомым различием будет библиотека bionic – аналог библиотеки libc для Android.

Закончив вводную теорию, самое время перейти к практике.

Инструменты для ручной сборки и тестирования

Все необходимые инструменты входят в поставку Android NDK, которая есть для 32 и 64 бит под Linux, MacOS, Windows.

Создание и запуск приложения

В случае совпадения архитектуры host и target (обычно речь идёт о x86) и наличия root привилегий, вполне возможно использовать при желании хитрый трюк с запуском Android x86 бинарников на хосте. Для этого нужно явным образом использовать dynamic linker для Android на системе (/system/bin/linker), а так же использовать non-stripped версию bionic в путях (LD_LIBRARY_PATH). См пример Makefile: (https://android.googlesource.com/platform/bionic/+/master/tests/Android.mk: bionic-unit-tests-run-on-host).

Такой трюк, например, актуален для исполнения бинарных файлов без эмулятора (в случае отсутствия 64-битного образа или использования -mx32).

GCOV и профили

Дебаг\отладка: GDB/logcat

Автоматизация тестирования

Для автоматизации тестирования можно использовать такой фреймворк, как dejagnu. Начиная с февраля 2013 в состав DejaGnu входит борд androideabi, позволяющий производить тестирование native-кода на Android через adb.

В целом всё аналогично тому, что было описано выше, за исключением некоторых нюансов.

Для многих тестов dejagnu критичны проверки host/target триплетов. Например, как минимум для того, чтобы понять, возможен ли запуск бинарного файла на устройстве, зачастую выполняется проверка host=target=build (native). Однако, в нашем случае, вообще говоря, build_triplet не равен target_triplet, но при этом мы вполне способны и выполнять, и получать результаты на Android. Кроме того, следует учесть тот факт, что по умолчанию NDK использует флажок –fpic, что так же влияет на возможность запуска тестов и их результаты (проверка effective-target pic/nonpic). В случае же статической (static) линковки следует иметь в виду, что, возможно, так же не всё будет соответствовать ожиданиям (библиотеки static, dynamic могут разниться между собой и порождать разный код (-fpic/-fpie). Также некоторые тесты критичны к директории запуска или указанию директории для результатов; и прежде чем запускать бинарный файл, следует сменить директорию на нужную. Кроме того, во время переноса бинарного файла на устройство, права на запуск могут быть сброшены (из-за прав на папку или прав на файловую систему), поэтому так же стоит убедиться, что для исполнимого файла установлен executable bit. Кроме того, лучшим решением для организации тестирования является использование не sd-карты, а ram-диска с правильными правами, чтобы избежать быстрого износа первой.

Чтобы запустить тестирование на Android достаточно выполнить при установленной dejagnu на хосте:

Следует убедиться, что у вас явным образом указана переменная ADB_SERIAL, соответствующая серийному номеру вашего устройства.
Однако гораздо удобнее и приятнее запускать тестирование через локальный конфигурационный файл — site.exp

Например, конфигурационный файл для запуска gcc testsuite:

и для запуска того же самого gcc:

Замечание: обратите внимание, что следует убедиться, что во время запуска проверки gcc кем-то не будет перетёрта переменная GCC_EXEC_PREFIX, и то, что она unset.

Стоит отметить то, что следует указать не только путь к компилятору, но и следует иметь в виду всё то, что мы делали выше вручную, а именно указать:

• sysroot
• пути к библиотекам и заголовочным файлам
• флаги и подключаемые библиотеки (как минимум для линовки libstdc++)

Исходя из этого, лучшим решением является использование обёртки исполнимого файла из toolchain (wrapper-binaryname), примерно следующего вида:

wrapper-gcc

wrapper-g++

При необходимости, если надо получить какие-то данные из Android, то мы можем использовать функцию remote_upload (adb_upload %target_board% %source% %dest%). Эта функциональность должна предоставляться со стороны testsuite.

Профилирование, тестирование производительности

В рамках данной статьи не будут рассматриваться подробно нюансы сбора и использования профилей, но для Android наиболее распространёнными утилитами для профилирования являются:

• perf
• oprofile
• sep

Например, имея статичную сборку perf, достаточно выполнить:

Тестирование производительности на Android возможно производить не только с помощью бенчмарков, работающих через Dalvik, но так же и на native-уровне, т.е. используя бенчмарки, собранные тем же самым Android NDK. В качестве примера: SPEC, EEMBC, CoreMark.

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

• режим работы процессора
• приложения, запущенные в фоне
• чистота запуска, и ошибки (которые можно и нужно отслеживать через logcat/dmesg)

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

• Отключены все второстепенные службы и приложения
• Устройство используется монопольно
• На устройстве жёстко выставлен режим работы

Например, для тестирования CPU типичная практика – это установка всех процессорных ядер и частот в равное значение и их фиксация. При необходимости отключение всех ядер, кроме того, на котором происходит тестирование.

Следует убедиться, что значение
/sys/devices/system/cpu/cpuX/cpufreq/online так же установлено правильно в зависимости от бенчмарки\профиля и\или потребностей тестирования.
Только убедившись, что всё работает в нужном режиме (cat /proc/cpuinfo) можно начинать тестирование и анализ.

Для упрощения работы и отладки native-кода, для Android существует набор утилит busybox, который не входит в поставку Android по умолчанию (т.к. поставляется по лицензии GPL 2.0).
[, [[, ar, arp, awk, base64, basename, bbconfig, beep, blkid, blockdev, bootchartd, bunzip2, bzcat, bzip2, cal, cat, catv, chat, chattr, chgrp, chmod, chown, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab, cttyhack, cut, dc, dd, deallocvt, depmod, devmem, diff, dirname, dmesg, dnsd, dos2unix, dpkg, dpkg-deb, du, dumpkmap, echo, ed, egrep, env, envdir, envuidgid, expand, expr, fakeidentd, false, fbset, fbsplash, fdflush, fdformat, fdisk, fgconsole, fgrep, find, findfs, flash_lock, flash_unlock, flashcp, flock, fold, free, freeramdisk, fsync, ftpd, ftpget, ftpput, fuser, getopt, grep, gunzip, gzip, halt, hd, hdparm, head, hexdump, httpd, hwclock, ifconfig, ifdown, ifup, init, inotifyd, insmod, install, iostat, ip, ipaddr, ipcalc, iplink, iproute, iprule, iptunnel, klogd, less, linuxrc, ln, loadkmap, losetup, lpd, lpq, lpr, ls, lsattr, lsmod, lsof, lspci, lsusb, lzcat, lzma, lzop, lzopcat, makedevs, makemime, man, md5sum, mdev, mesg, mkdir, mkfifo, mknod, mkswap, mktemp, modinfo, modprobe, more, mpstat, mv, nbd-client, nc, netstat, nice, nmeter, nohup, od, openvt, patch, pidof, ping, pipe_progress, pmap, popmaildir, poweroff, powertop, printenv, printf, ps, pscan, pstree, pwd, pwdx, raidautorun, rdev, readlink, readprofile, realpath, reboot, reformime, renice, reset, resize, rev, rm, rmdir, rmmod, route, rpm, rpm2cpio, rtcwake, run-parts, runsv, runsvdir, rx, script, scriptreplay, sed, sendmail, seq, setconsole, setkeycodes, setlogcons, setserial, setsid, setuidgid, sha1sum, sha256sum, sha3sum, sha512sum, showkey, sleep, smemcap, softlimit, sort, split, start-stop-daemon, strings, stty, sum, sv, svlogd, switch_root, sync, sysctl, tac, tail, tar, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd, time, timeout, top, touch, tr, traceroute, true, ttysize, tunctl, tune2fs, udpsvd, uname, uncompress, unexpand, uniq, unix2dos, unlzma, unlzop, unxz, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, volname, watch, wc, wget, which, whoami, whois, xargs, xz, xzcat, yes, zcat

Использование подхода, описанного в статье, позволяет быстро и легко портировать тестирование из Linux на Android, создавать с нуля и производить отладку для различных конфигураций оборудования и эмуляторов с наименьшими затратами времени.

Источник