Android all auto test

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 на работоспособность тех или иных аппаратных и программных модулей. Также можно по аналогии с рекавери сбросить данные и настройки или проверить наличие рут-прав.

Источник

Android Auto tests a new UI with a media player and notification overlay

Google is testing a new UI in the Android Auto projected car interface that appears when you connect your device to a compatible head unit. This new UI, code-named “Coolwalk”, is seemingly designed to reduce the number of times the user leaves the navigation screen, potentially saving drivers from missing their next turn.

An APK teardown can often predict features that may arrive in a future update of an application, but it is possible that any of the features we mention here may not make it in a future release. This is because these features are currently unimplemented in the live build and may be pulled at any time by the developers in a future build.

Screenshots of the new “Coolwalk” design were first published by Italian blogВ AndroidWorld, but we at XDAВ have also managed to enable the new interface in Android Auto. The biggest change in the new “Coolwalk” UI is the introduction of a new button that launches a semi-transparent overlay on top of the navigation screen. This overlay slides in from the left and displays a card showing the most recent notification and another card containing the media player widget. The cards for the notification and media player are opaque, making it hard to see the part of the map behind them, though the opacity could change as the feature is still in development. You’re still able to see a good 2/3 of the map view anyway, which should be enough to see where you need to go.

The icon for the app launcher has been changed, and the app launcher is now no longer the leftmost button in this new design. However, the notification icon has been moved from the right side to the left in this new design. Other than that, the rest of the Android Auto interface remains the same, including the app launcher, the Settings, the Assistant icon/overlay, the notifications screen, and the media player in the navigation bar.

The new “Coolwalk” design hasn’t rolled out to anyone yet with the latest Android Auto 6.9 update available in the beta channel. AsВ AndroidWorld notes, the new design is pretty unfinished, and many things still don’t work. The music card, for instance, doesn’t do anything except play/pause your music, while the notification card doesn’t let you dismiss the notification. Thus, we’ll probably have to wait a while for the new design to go live, if it ever does. If it rolls out, users without a head unit wide enough to take advantage of Android Auto’s split-screen mode won’t have to constantly switch between screens to read their last notification or choose their next track.

AndroidWorld also reports — and we can confirm — that Android Auto is testing 3В new wallpapers. AA added a handful of wallpapers earlier this year that you can pick from to change the background of the app launcher, and it seems Google is preparing to add more. These wallpapers appear to be pulled from Google’s servers rather than the APK’s assets, which hints Google may add new wallpaper customization options in the future (perhaps a rotating wallpaper?)

Lastly, we have also enabled a new setting that lets you pick when Android Auto should start. You can let the car choose when to launch AA, launch AA if it was used during the last drive, or start AA with every drive. This could be useful if your car supports wireless AA and you don’t want to start it on every drive.

Источник

Автотесты на Android. Картина целиком

Автотесты под Android — это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.

Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.

Зачем нужны автотесты?

Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.

Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.

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

Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У «Авито» есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project — стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.

Картина целиком

Итак, обещанная картина целиком.

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

Процесс написания тестов

На первом шаге давайте попробуем написать тесты у себя на машине и запустить их локально.

Выбор инструментов для написания автотестов

Стоит сразу определиться со стеком технологий, который мы будем использовать для написания тестов.

Первая развилка — это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.

Спойлер — мы за нативные решения. По нашему опыту, они:

• стабильнее;
• быстрее;
• лучше интегрированы в IDE;
• не содержат слоев, которые вносят нестабильность и заставляют иметь суперширокие экспертные знания.

Кроме того, Google поддерживает Espresso и UI Automator.

Больше почитать про сравнение вы можете в статьях:

На чистом Espresso и UIAutomator нынче редко кто пишет. Разработчики сделали различные удобные обертки, которые решают их проблемы. Сейчас у нас готовится статья об этих инструментах с классификацией и сравнением. Если кратко, то фреймворк, на который мы делаем ставку, это Kaspresso.

Kaspresso

Kaspresso — это фреймворк, который:

• предоставляет DSL, значительно облегчающий написание автотестов;
• дает встроенную многоуровневую защиту от флекающих тестов;
• ускоряет работу UI Automator;
• предоставляет полные логи о том, что происходит в тесте;
• дает возможность запуска любых ADB-команд внутри тестов;
• предоставляет механизм интерцепторов для перехвата всех действий и проверок. На данном механизме построено логирование и защита от нестабильных тестов;
• описывает лучшие практики (исходя из нашего опыта) по написанию автотестов.

Вы можете прочитать о Kaspresso на GitHub и Habr.

Test runner

Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.

Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим — Orchestrator. AndroidJUnitRunner делает то, что от него и требуется — просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.

Но со временем требований к раннеру становится все больше. Вот некоторые из них:

• запускать отдельные группы тестов;
• запускать тесты только на определенных девайсах;
• перезапускать упавшие тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
• эффективно распределять тесты по девайсам с учетом истории прогонов и успешности предыдущих запусков;
• подготавливать отчеты о прогоне в разных форматах;
• отображать результаты прогона (желательно Allure based);
• поддержать истории прогонов для дальнейшего анализа;
• просто интегрироваться с вашей инфраструктурой.

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

Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:

• Простой и нативной интеграции раннера с инфраструктурой, которая выдает эмуляторы. А еще лучше возможности сразу же запустить ваши тесты в облаке. Впрочем, это проблема не только Marathon — к сожалению, ни один известный нам раннер не берет на себя ответственность за получение эмуляторов, это всегда ложится на плечи разработчиков.
• Плотной интеграции с фреймворками типа Kaspresso для получения максимальной, точной и корректной информации о тесте.

Кроме того, мы считаем, что раннер должен быть платформенным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.

Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!

На чем запускать тесты

Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:

1. Настоящий девайс.
   Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя — как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
   Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них — необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
2. Чистый эмулятор.
   Под «чистым» мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
   Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
   Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус — это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
3. Docker-образ Android-эмулятора.
   Docker решает недостатки чистых эмуляторов.
   Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора — это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
   Минусы. Более высокий входной порог.

Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:

Как уже было упомянуто выше, подготовка образа требует некоторой сноровки. Плюс зачастую есть желание эмулятор преднастроить: выключить анимацию, залогиниться в аккаунт Google, выключить Google Play Protect и многое другое. Все эти вещи непросто организовать. Поэтому в скором времени мы хотим выкатить подробную документацию о том, как готовить и использовать образы быстро.

Инфраструктура

Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.

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

Итак, что вам примерно предстоит:

• Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
• Самое трудоемкое — это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
  Дальнейшая накатка необходимого ПО, встраивание в сети и прочее — это все за DevOps-инженерами.
• На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
  В его настройке опять-таки помогают DevOps-инженеры.
• Связка полученного сервиса с Test Runner.
  Одна из задач Avito Runner — сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.

В ближайшее время мы планируем выпустить Avito Runner и статьи, которые помогут настроить инфраструктуру.

Остальное

Не забывайте про такие немаловажные моменты, как:

• вывод отчета по прогону тестов (Allure);
• внедрение/синхронизация с TMS;
• интеграция в CI/CD;
• обучение разработчиков и тестировщиков;
• процессы — кто, когда, сколько и какие автотесты пишет.

Про все это мы еще обязательно поговорим.

Заключение

Мы постарались описать основные части становления автотестирования под Android. Надеемся, что теперь у вас в головах сложится тот самый пазл, который позволит видеть картину целиком.

Источник