Инструменты тестирования Android приложений. Часть 2
ADB (или Android debug bridge) — самый сильный и многофункциональный инструмент, используемый для работы с android приложениями. ADB — это инструмент командной строки, который позволяет общаться с подключенным к компьютеру девайсом. С помощью него можно делать следующее:
- Получать и менять все настройки системы устройства
- Делать скриншоты экрана девайса и записывать видео
- Симулировать касания экрана и нажатие кнопок девайса
- Работать с файловой системой
- Удалять, устанавливать и запускать приложения с определенными входными параметрами
- Забыть про USB и подключаться к девайсам через Wi-fi
ADB идет в комплекте с Android Studio, путь к нему можно найти в (Preferences → Android SDK → Android SDK location:) в папке из этого пути нужно выбрать папку platform-tools — там и будет лежать искомый “adb” файл. Также ADB можно скачать отдельно и использовать без Android Studio.
Однако на начальных этапах легче все-таки работать с Android studio, потому что она использует некоторые возможности ADB.
Android девайс под капотом — Unix система, получив доступ к девайсу через adb shell вы получаете все те же возможности, которые у вас были бы при работе с Unix, поэтому знания в этой области необходимы, чтобы чуствовать себя комфортнее.
Давайте все же немного поговорим о работе с adb напрямую. Вот самый простой пример запуска приложения с помощью adb из консоли: adb shell am start -n com.example.demo/com.example.test.MainActivity , где
“shell” — это обращение к девайсу (если их несколько, придется явно указать название; его можно получить, запустив “adb devices”)
“am” — это вызов activity manager — инструмента, который занимается менеджментом компонентов activity.
“start -n /package/activity_name/” — запуск активити (в этом случае это должна быть та же уникальная активити, которая запускается при клике на иконку, т.е. иметь настройки action = .MAIN category = .LAUNCHER
На самом деле, любая активити, у которой в манифесте заданы какие-то значения для “action” и “category” (и эти значения не равны .MAIN и.LAUNCHER), может быть запущена из консоли. Подобные активити являются дополнительными точками входа в приложения. Они дают возможность сторонним приложениям открывать ваше на каком-то конкретном экране и использовать его функционал. По такому принципу работает, например, GMail: когда вы хотите поделиться какой-нибудь информацией из социальных сетей, вы попадаете сразу на активити экрана с написанием письма, где уже сформирован весь контент и остается добавить только получателя письма.
Или еще один пример: если активити может открывать изображения для редактирования и на вход принимает путь до файла, то любое другое приложение может воспользоваться им для редактирования своих изображений.
А в рамках тестирования QA специалист может подложить изображение в файловую систему и напрямую вызвать этот триггер без использования других приложений:
adb shell am start -a android.intent.action.VIEW -c android.intent.category.DEFAULT -e pathToImage your/image/path -n com.example.test
“-e” — это команда, которая передает аргумент по ключу “-e key value”
Плюс ко всему, через adb также легко тестировать deeplink’и. С этим поможет команда:
где “myAppScheme” и “test” — это значения, которые умеет обрабатывать активити (их обычно указывают в Манифесте в блоке <activity>),
а “com.example.test” — это имя пакета вашего приложения (тоже хранится в манифесте).
Команда выше симулирует переход по ссылке myAppScheme://test, а система Android проходит по манифесту и ищет активити, которые знают, как такие ссылки обрабатывать.
Например, активити в манифесте для этого примера будет выглядеть следующим образом:
Если в манифесте есть несколько активити, которые могут обработать входящий запрос, то Android предложит пользователю выбрать, какую именно активити он хочет запустить.
На самом деле, использование активити другим приложением или открытие активити через deeplinks — это довольно частый кейс. И ADB помогает быстро и без сторонних приложений эмулировать все эти запуски и, в перспективе, автоматизировать весь процесс тестирования. Таким образом, ADB экономит время QA инженера — все вещи, которые можно сделать мануально, adb выполнит с помощью одной команды.
Есть уже много готовых Cheat sheet’ов, которые помогут быстрее понять, что можно делать с помощью adb, а также официальная документация.
В следующей части мы поговорим о “зеркале” приложения, которое позволит нам не погружаясь в код понять, что происходит внутри.
Useful ADB Commands For Android Testing
Suppose you need to test a feature of your app while the device battery is running low. If the battery is full, you’ll need to wait several hours before it is discharged. The worst scenario would be if you are testing it using an Android Virtual Device (AVD), how would you discharge the battery of an emulator?
Another required setup with a certain frequency is clearing the application data before launching it. This takes less time than fully discharging a battery. But if you must manually navigate to the app info screen and press the clear data button before each test, you will reach the end of the day with several valuable minutes, maybe hours, spent doing this repetitive action.
This article will show you how you may perform these kinds of actions by a command in a terminal. This saves you time and improves your productivity.
Table of Contents – Useful ADB Commands For Android Testing
What is ADB
Android Debug Bridge , or simply ADB, is a tool included in Android SDK that allows us to send commands from a computer host to an Android device. Using ADB makes it possible to copy files to/from the device, and is among the most useful of its features, run shell commands in the Android device ��
Before using ADB, we must enable USB debugging in Developer options in the Android device. To do that, launch the Settings application and navigate to About Phone, or About emulated device if you’re using an AVD. Perform several touches on the Build number until the message “You are now a developer!” appears. This enables developer options.
Return to the main screen of the Settings application and go to System -> Advanced -> Developer options. Find the option USB debugging and enable it. Now connect the device to your computer using a USB cable and you are ready to run ADB commands!
List connected devices
The first command you should learn is the one to list the connected devices, so you can check if your device was correctly recognized by the ADB server. To do that run the command:
Having found our device in the command output, we are good to proceed to more interesting commands.
Simulate battery parameters
Do you have any idea about how to discharge the AVD battery yet? �� Probably not if it is a virtual device with no real battery. But fortunately we can use the following command to simulate any scenario we want, like setting the level to 1% only:
You could also try to connect/disconnect an AC charger:
Or if you prefer, try with a USB cable instead:
After running each of those commands you can reset the battery options using:
Take screenshots and recordings
ADB commands are way more powerful than just faking battery parameters- we can also do more things like taking screenshots and recording videos of the device screen. Let’s start recording a video of our device screen by running the following command:
This will record the device screen and save the video file to the path / SDcard / Movies / video.mp4. To stop recording press Ctrl + C to finish the command. In order to take a screenshot of some screen of our app we just need to navigate to the desired screen, and then run the command:
The command above will take a screenshot of the current screen and save it at the path / SDcard / Pictures / screenshot.png. If you tried running the command, you may have noticed that no output text is displayed, so how can we check if the screenshot was really captured? Fortunately, we can use ADB to several commands that are well known by users who are familiar with Unix commands, like the ls which we will use to list the files from the Pictures folder:
As you can see in the command output, the screenshot was correctly saved in this folder �� But you may have noticed that the screenshot was saved in the Android device storage. How can we access it using our computer? By simply copy the file using the ADB pull command:
The screenshot file was now copied from the device storage to the computer desktop. Now let’s suppose that you opened it on the computer, made some changes in the image file, and want to copy it back from the computer to the Android device. What you need to do is run the ADB push command instead:
As mentioned before, we are able to execute Unix-like commands using ADB shell, and we already used the ls to list the files in a directory. Now let’s use some other commands that may help a lot when we are dealing with files. We may want to have a specific folder to save our screenshots, separating them from the other pictures. For this, run the following command to create a new directory, after that run the ls in order to check if it was created correctly:
As we can see in the command output, the directory was created but the screenshot that we have taken before is still placed inside the Pictures folder. We can use this command to move it to the new location:
If instead of moving the file you wanted to copy, then you could have used the cp command instead:
And after copying and moving the files, you can just delete them by using the rm command:
Obtain log files
As you may imagine, we can do much more with ADB. The next commands are even more important to testers once they allow us to obtain data about the android device such as logs, application, and Android versions, which are very important when reporting issues or tracking bugs.
Probably the most important one of them is the log, which is how the developer will use it to understand what went wrong with the application ❌ The log can be obtained using logcat:
The command above will print the log to the console output. In order to stop the process, press ctrl + C to stop it. Using the logcat command without any additional option will print the whole text available in the main logcat buffer, which probably is not so useful for your tests. You then may want to use some filters. We can filter the logs according to their priorities:
- V: Verbose (lowest priority)
- D: Debug
- I: Info
- W: Warning
- E: Error
- F: Fatal
- S: Silent (highest priority. Nothing is printed)
If we want only the messages with error priority or higher, for example, we just need to use the command:
To filter by other log priorities, just change the end of the command with the respective letter. We can also filter the output by the tag used by the application logger �� The command below prints to the output log messages with the tag MyTag and priority level Info or higher. The *:S at the end will exclude the log from other tags with any priority:
Besides logs, there are several other important data, such as device build, current language, or Android version, that can be obtained by using ADB commands:
The command above will output all the data that can be obtained using this command, but we can also pass the key displayed inside the brackets in order to get only a specific value. Some examples are displayed below:
Perform touch or swipe
Another interesting feature of ADB is the possibility to interact with the Android device by performing touches and swipes on the screen, entering text, and pressing buttons. To execute these interactions, we will use the input command followed by the name of the interactions to be performed and their arguments.
So to enter a string in a text field, use the command below (make sure the field has focus and remember to escape the whitespaces):
The touches can be performed by coordinates. Just use the input tap command followed by the x and y points to be clicked:
Similarly, the swipe command can be executed by sending the coordinates, but we need to send two different points, the initial and the final ones. Optionally we can define the duration of the swipe movement in milliseconds:
We can also use the input command to press device buttons, like home, back, menu, or even other less common ones like camera or headset buttons. This is possible because each of these buttons has a key code associated with them and the input command uses those codes to perform the actions.
You can find the list of all key codes in the official documentation �� See some examples below:
Launch activities
Another scenario where ADB is really useful is when the testing applications are launching activities directly, which can be done by using the Activity Manager (am). Besides launching the main activity of an app you can also lunch other ones, reducing the steps required to reach a screen ��
Let’s start using the Activity Manager to launch an application by its package name. We’ll use the Settings app as an example. Its package name is com.android.settings:
After running this command the Settings application will be launched on the Android device. This command will just launch the application’s main activity. If we want to launch another one, we just need to inform the activity name with the flag -n. The command below launches the Wifi Settings screen directly:
But how can we discover the activity name that we want to launch? Fortunately, there is also an ADB command to do that. We just need to use the dumpsys to extract the information about the activity that is being displayed on the screen.
Once the command will output a lot of data that is not relevant for us, let’s filter the output with the grep and cut shell commands in order to print just the activity name:
After launching the application and performing your validations, surely you will want to close the app. To do that is just as simple as launching it, just use the force-stop command with the package name:
Clear application data
The last type of command presented in this article will be the one that uses the Packager Manager (pm). Using the Package Manager, press clear application data, grant and revoke permissions, and also list all the installed applications.
As mentioned at the beginning of this article, despite the fact that cleaning the application data is a quick task, it may consume a lot of time from the tester if it needs to be repeated before each test. To solve that, we may run a pm command to clear the application data by using ADB.
To test that, try launching the Clock application and making some changes like creating an alarm ⏰ After that, run the command below and verify that all changes have been reset:
After clearing the application data, you may want to grant the application permissions. This can be done manually when the app asks for them, but you could also enable them beforehand by using the pm command. The command below will grant the permission android.permission.READ_EXTERNAL_STORAGE to the Clock application:
If you want to revoke this permission, use the following command:
In order to discover what is the name of the permissions to be used, you can use the pm command to list all known permissions:
We can also use the pm command to see if an application is installed. We just need to run the pm command to list all installed applications and then check if some package name is included in the output.
Alternatively, we can add a substring of the package name to the end of the command, then only the package names that match this substring will be printed at the command output. See the examples below:
FAQs
- What are ADB commands inAndroid?
Conclusion
I hope the commands presented in this article have been helpful to you and saved some effort when running your tests. It is also nice to point out that the ADB shell commands can be executed from UI Automator scripts, so they can also be useful for your automation scripts. You can also use TestProject’s ADB Wrapper Community Addon to execute any ADB shell command.
Please have in mind that those are just some of several available commands. There are a lot of possibilities that can help you and your team when working with Android devices. You can learn more by running the adb help command ����
The ADB tool is a must for anyone working with Android devices, whether it’s a developer or a tester. Hope you enjoyed my tutorial ��
About the author
I am a Software Engineer based in Recife, Brazil. My education is Master of Science in Computer Science at CIn/UFPE (2016), Specialist in Test Analysis at CIn (UFPE)/Motorola (2013) and Graduated in Technology of System Analysis and Development at IFPE (2013). I Was a Undergraduate Researcher (PIBIC) in the project Virtual Reality Environments Applied to Teaching Algorithms and Data Structures (2011-2012). I am currently working as Software Engineer at CIn/Motorola partnership, where I am responsible for development of tools that run on both Web, Desktop and Mobile (Android) environments. I also have more than 8 years working with test automation for Android devices. Most of my experience is working mainly with Java, Kotlin and Javascript.
Автоматизация тестирования Android приложений
Задача — с наибольшей точностью автоматизировать действия, которые выполняет тестировщик. Давайте их рассмотрим. В наличии есть несколько приложений и несколько Android устройств. Для каждого приложения и каждого устройства выполняются следующие шаги:
- Установка приложения на устройство
- Запуск приложения
- Тестирование приложения выбранным способом
- Удаление приложения
- Сброс состояния устройства
Далее рассматриваются средства, позволяющие автоматизировать перечисленные шаги.
Управление Android устройствами
Для начала нужно выделить компьютер на котором будет запускаться автоматическое тестирование и настроить на нем Android SDK. Примеры приводятся для компьютера с установленной ОС Linux.
На всех тестируемых устройствах нужно отключить экран блокировки и максимально увеличить время ожидания. Для некоторых методов тестирования нужно отключить смену ориентации экрана.
В Android SDK имеются две утилиты для управления устройствами: adb и MonkeyRunner.
Я постараюсь подробно описать автоматизацию действий, использующихся при тестировании. Тем, кто знаком с ADB и MonkeyRunner имеет смысл сразу переходить к разделу «Способы автоматизированного тестирования».
Управление с помощью утилиты ADB
ADB (Android Debug Bridge) – утилита для управления Android устройствами из командной строки. Официальная документация по ADB: developer.android.com/tools/help/adb.html
Утилита adb находится в директории <android_sdk>/platform-tools/ . Путь к данной директории рекомендуется прописать в переменной окружения PATH .
Проверка работы ADB
Устанавливаем и настраиваем Android SDK, подключаем к компьютеру Android устройства и выполняем команду:
Команда выдаст список всех подключенных устройств. Если список устройств не пуст, значит ADB настроен и работает.
Работа с несколькими устройствами
Чтобы указать ADB с каким устройством нужно работать, следует прописать серийный номер устройства после ключа -s :
Серийный номер устройства можно посмотреть командой adb devices . Ключ -s позволяет работать одновременно с несколькими подключенными устройствами. В дальнейшем ключ -s в командах я указывать не буду.
Основные команды ADB
Открыть консоль на устройстве:
Запустить команду на устройстве:
В Android присутствуют многие стандартные утилиты Linux: ls, cat, dmesg,…
Установить приложение из apk файла:
Название package можно получить из apk файла командой:
Загрузить файл с устройства на компьютер:
Загрузить файл с компьютера на устройство:
Примечание:
В большинство директорий на устройстве разрешен доступ только на чтение. Доступ на запись разрешен в директорию /sdcard (из нее нельзя запускать программы) и /data/local/tmp/ .
Запускает указанную activity. Название activity, которая запускается при выборе приложения в меню можно получить из apk файла командой:
Чтение логов
Чтение логов в Android производится утилитой logcat.
Домашняя страница утилиты logcat: developer.android.com/tools/help/logcat.html
Считать логи с устройства (блокируется до нажатия Ctrl-C):
Очистить буфер логов на устройстве:
Считать буфер логов на устройстве (выдает текущее содержимое буфера, не блокируется):
Снятие скриншотов с помощью утилиты screencap
Утилита screencap сохраняет текущее содержимое экрана в графический файл:
Утилита screencap имеется на телефонах с Android 4.x и выше. На предыдущих версиях Android снятие скриншотов можно производить с помощью MonkeyRunner.
Пример BASH скрипта для тестирования приложения c помощью ADB
Управление с помощью MonkeyRunner
Утилита MonkeyRunner предоставляет API для написания скриптов, которые управляют Android устройстами. С помощью MonkeyRunner можно написать скрипт на языке Python, который устанавливает Android приложение, запускает его, имитирует действия пользователя, снимает скриншоты и сохраняет их на компьютер. Утилита MonkeyRunner использует Jython для выполнения скриптов.
Чтение логов с помощью MonkeyRunner
Скрипт запишет логи в файл example.log в текущей директории.
Снятие скриншотов
Скрипт снимает скриншот и сохраняет его в файл screenshot.png в текущей директории.
Пример управления устройством с помощью MonkeyRunner
Средства автоматизированного тестирования
Тестирование с помощью monkey
Представьте, что устройство попало в цепкие лапы очень активной и творческой обезьяны – утилита monkey призвана имитировать подобную ситуацию.
Утилита monkey входит в состав Android SDK. Утилита отправляет на устройство поток псевдо-случайных действий пользователя. Параметры командной строки задают количество действий пользователя, соотношение их типов и имя тестируемого пакета, чтобы, например, обезьяна не вышла за пределы тестируемого приложения и не начала рассылать SMS по всем контактам из адресной книги.
Примеры использования и перечень параметров приведены на домашней странице: developer.android.com/tools/help/monkey.html
Главное достоинство monkey – отсутствие затрат на поддержку. Кроме того, стресс-тестирование приложения потоком произвольных событий может обнаружить нетривиальные ошибки.
- Неэффективно для тестирования функционала, вызываемого сложной последовательностью действий. Например, monkey не сможет пройти аутентификацию и основной функционал приложения останется без внимания.
- Игры со сложным управлением, требующим быстрой реакции и сложных жестов, будут завершатся в самом начале, либо вообще не начнутся.
- Ошибки, найденные с помощью monkey, очень сложно воспроизвести.
- Нет проверки состояния приложения.
Тестирование с помощью MonkeyRunner
При помощи скриптов использующих MonkeyRunner API можно не только разработать основу для тестирующей системы, но и написать скрипты для тестирования конкретного приложения на конкретном устройстве.
- Гибкость – реализовать можно практически все, что угодно.
- Сложность написания скриптов даже в простых случаях.
Тестирование с помощью getevent/sendevent
- Последовательности действий могут быть записаны без дополнительных затрат в ходе ручного тестирования, если оно уже проводится.
- Для записи сценариев не требуются навыки программирования.
- Последовательности действий необходимо записывать отдельно для каждого приложения и для каждого устройства. При изменении интерфейса приложения все записанные действия необходимо проделать заново.
- Отсутствует проверка состояния приложения. Например, при тестировании браузера открывается страница. Если она открывается дольше, чем в момент записи, то дальнейшие действия будут выполнены до полной загрузки страницы и результат будет некорректный. Иногда возможно записать скрипт таким образом, что во всех подобных случаях ожидание превышает максимально возможное.
- Быстрая и сложная последовательность действий будет воспроизводиться дольше, чем записывалась – поэтому способ не всегда подойдет для тестирования динамичных игр, где критично время реакции и своевременность действия.
На устройстве должны воспроизвестись записанные действия.
Тестирование с помощью Robotium
В отличии от рассмотренных ранее способов Robotium не входит в состав Android SDK, а распространяется под Open Source лицензией.
Главное отличие Robotium в том, что тестовые действия описываются на уровне интерфейса приложения. В рассмотренных ранее способах тестовые действия явно или неявно описывались на уровне устройств ввода.
Например, в приложении нужно нажать кнопку «OK». С помощью скрипта MonkeyRunner нажатие на кнопку реализуется как: «Коснуться точки экрана с координатами (x0, y0)». С помощью Robotium это реализуется как: «Нажать кнопку с текстом «OK»».
Когда действия описываются на уровне интерфейса приложения их можно сделать независимыми от расположения элементов интерфейса, разрешения экрана и положения устройства.
Кроме того, Robotium позволяет проверять реакцию приложения на действие.
Например, после нажатия на кнопку «OK» в приложении должен появиться список с элементом «Item 1». С помощью Robotium можно проверить, появился ли список с таким элементом.
Если выполнять проверки после каждого действия, то легко обнаружить, на каком шаге произошла ошибка.
- Для каждого приложения необходимо разработать сценарий тестирования на языке Java. Это требует навыков программирования и временных затрат.
- При изменении интерфейса приложения сценарий тестирования придется модифицировать.
- Написать сценарий Robotium сложнее, чем записать действия с помощью getevent/sendevent.
Сравнение способов тестирования
| Способ тестирования | Достоинства | Недостатки |
|---|---|---|
| Monkey – поток случайных действий пользователя. | Отсутствуют затраты на сопровождение. Не зависит от устройства. Стресс-тестирование позволяет обнаружить нетривиальные ошибки. |
Качество тестирования варьируется от приложения к приложению. Найденные ошибки сложно воспроизвести. Нет проверки состояния приложения. |
| MonkeyRunner – скрипт управления устройством. | Гибкость. | Сложность написания и поддержки скриптов даже для простых приложений. |
| getevent/sendevent – запись/воспроизведение действий пользователя. | Для записи последовательности действий не требуются навыки программирования. | Записанная последовательность действий подходит только к одному устройству при фиксированной ориентации. При изменении интерфейса приложения необходимо заново записать последовательность действий. Нет проверки состояния приложения. |
| Robotium – сценарий тестирования интерфейса приложения с проверкой состояния. | Действия описываются на уровне интерфейса приложения. Сценарий может быть независимым от разрешения экрана и ориентации устройства. После совершения действия можно проверять состояние приложения. |
Сложность написания сценариев на языке Java. При изменении интерфейса приложения сценарий придется модифицировать. |
Анализ результатов
В результате тестирования приложения перечисленными выше способами мы получили логи и скриншоты. Теперь их нужно проанализировать на наличие ошибок.
Анализ логов
- I/DEBUG
- FATAL EXCEPTION
- WIN DEATH
Анализ скриншотов
В процессе тестирования вручную можно подготовить серию скриншотов в ключевых моментах тестирования, а затем сравнивать их с содержимым экрана в процессе автоматизированного тестирования. Это позволит определить, правильно ли идет процесс автоматизированного тестирования и выявлять ошибки.
Также полезно сравнивать скриншот до и после запуска приложения – это позволяет определять случаи, когда приложение аварийно завершается без сообщений на экране и в логах.
MonkeyRunner позволяет сравнить два скриншота с заданным допуском в процентах:
К сожалению, в API MonkeyImage не предусмотрена функция загрузки из файла. Поэтому для сравнения сохраненных скриншотов придется писать свою функцию, например с помощью Python Imaging Library.
Сброс состояния устройства после тестирования
После тестирования приложения устройство нужно вернуть в первоначальное состояние.
- Многократное нажатие кнопки «Назад».
- Перезагрузка устройства.
- Перезапуск процесса zygote.
Многократное нажатие кнопки «Назад»
Нажимаем кнопку «Назад» используя MonkeyRunner:
На практике этот вариант оптимален, так как имитирует поведение реального пользователя.
Заключение
В заметке были рассмотрены некоторые способы автоматического тестирования Android приложений, их достоинства и недостатки. Кроме того, рассмотрены инструменты, входящие в Android SDK или распространяющиеся под Open Source лицензией.
Хочется отметить, что автоматическое тестирование не является панацеей и не заменяет другие виды тестирования. Качественный продукт получается при грамотно построенном процессе тестирования, сочетающем различные способы.
Тестирование на реальном устройстве
Целью данной главы является написание минимального приложение под Android. Но мы никогда не будем точно знать, смогли ли мы написать нечто работоспособное, не попробовав запустить его на реальном устройстве. Этим мы и займёмся в этой статье.
Возможность тестирования на смартфоне предоставляется ADB (Android Debug Bridge). В этой статье мы настроим его и запустим наше приложение на настоящем смартфоне.
Что такое ADB
Android Debug Bridge (ADB) является универсальным инструментом командной строки, который способствует взаимодействию между средой разработки, в нашем случае Android Studio, и AVD-эмуляторами или физическими Android-устройствами для возможности запуска и отладки приложений.
ADB состоит из клиента, из сервера, который работает в качестве фонового процесса, на компьютере разработчика и из демона, который работает в качестве фонового процесса на каждом экземпляре эмулятора или реального устройства.
Настройка Android-устройства для работы с ADB
Для того, чтобы использовать ADB с устройством, подключенным по USB, необходимо разрешить USB-отладку в системных настройках телефона или планшета в разделе «Параметры разработчика» (название может отличаться). На некоторых устройствах этот раздел по умолчанию скрыт. Рассмотрим шаги в случае, когда нет нужного раздела настроек.
- Зайдите в настройки, раздел «Об устройстве»
- Найдите пункт «Номер сборки» и щёлкните по нему 7 раз. Должно появиться окно, оповещающее о том, что активирован режим разработчика. Теперь в настройках должен появиться раздел параметров разработчика.
- Включите в нём опцию «Отладка USB».
Теперь, когда вы подключаете устройство к компьютеру, в зависимости от модели у вас может появиться новый вариант подключения.
Настройка ADB на Windows
При настройке Windows, во-первых, убедитесь, что у вас установлен Google USB Driver. Зайдите в SDK Manager в раздел Extras и найдите Google USB Driver, установите его в случае необходимости.
Теперь следует обновить драйвер. Подключите девайс к компьютеру, перейдите в Панель управления -> Оборудование и звук -> Диспетчер устройств найдите своё устройство. Щёлкните правой клавишей по своему устройству, чтобы открыть контекстное меню и выберите «Обновить драйверы. «. Драйвер можно найти в директории sdk в подпапке \<директория sdk>\extras\google\usb_driver.
Как проверить правильность настроек ADB?
Для проверки работоспособности ADB подключите устройство к компьютеру, запустите в папке \<директория sdk>\platform-tools командную строку и введите в ней команду:
Должен появится список наподобие этого:
Запуск приложения на реальном устройстве
Всё тоже самое, что и в случае запуска на эмуляторе. Откройте в Android Studio наш проект, нажмите на зелёный треугольник, но в появившемся окне выбора устройства выберите ваш девайс.
Если написано, что девайс offline, перевоткните USB и разрешите USB-отладку компьютеру:
В результате на экране телефона или планшета покажется наше приложение.
Заключение
На этом заканчивается глава. Мы добились успеха: смогли настроить нашу систему под разработку Android-приложений и даже запустить одно из них на настоящем устройстве.
Если у вас что-то активно не получается или вы запутались, отпишитесь, пожалуйста, в комментариях и я помогу вам разобраться с вашей проблемой.