Виртуальная машина arm на windows
VirtualBox — как альтернатива эмулятору ARM в Android SDK. Установка, настройка, подключение к среде разработки Eclipse и интернету
Наверняка многие из вас имели дело с эмулятором, поставляемым в комплекте Android SDK от компании Google. И, вероятно, очень многих разочаровала крайне медленная работа данного эмулятора, начиная от загрузки и заканчивая медленной работой вашего приложения. Речь идет об эмуляторе системы Android с поддержкой команд ARM-процессоров. Но ведь есть же в SDK образы системы Android для x86 процессоров, скажут многие, и будут правы. Но дело тут в том, что для эмуляции OS Android с поддержкой виртуализации x86-процессоров необходимо приложение HAXM от Intel, которое отказывается устанавливаться на компьютеры с процессорами фирмы AMD. Есть ли выход из данной ситуации для владельцев систем на базе AMD?
Ответ есть! И он заключается в использовании VirtualBox — свободнораспространяемой системы эмуляции с поддержкой виртуализации от фирмы Oracle. И не верьте тем, кто говорит, что настроить интернет на виртуальной машине можно только со специальным образом Андроида с поддержкой Ethernet. Поддержка Ethernet’а есть везде, просто в меню настроек Андроида нет такого пункта.
Что же нам нужно для успешной отладки своих приложений в виртуальной машине VirtualBox и настройки интернета?
Для этого необходимо скачать и установить последнюю версию VirtualBox’а, а так же скачать нужные вам образы ОС Android вот отсюда: http://www.android-x86.org/download
Запускаем VirtualBox и создаем виртуальную машину с такими параметрами:
Выделяем 256 Мб оперативной памяти, 128 Мб для видеоадаптера и создаём виртуальный диск размером 1 Гб (можно большего и меньшего размера под ваши потребности) типа VHD.
В настройках виртуальной машины подключаем скачанный образ системы Android:
Запускаем нашу виртуальную машину и видим:
Выбираем установку ОС «Андроид» на наш виртуальный жесткий диск и жмем Enter.
Далее выбираем первый пункт меню «Create/Modify partitions» и опять жмём Enter.
Теперь нужно создать первичный раздел Linux.
Выбираем пункт New, затем Primary, видим что-то вроде «Size (in MB): 1069,29» и жмём Enter, далее опять нажимаем Ввод на пункте Bootable и затем выбираем пункт Write.
На вопрос записать ли таблицу разделов на жесткий диск, вводим слово «yes».
После жмём на пункт Quit и видим следующее меню:
Выбираем первый пункт меню и далее выбираем пункт меню ext3 и жмём Ввод, далее нас спросят «Do you want to install boot loader GRUB?» — выбираем Yes, нажимаем Ввод. Далее нас спросят, «хотим ли мы, чтобы директория /system была доступна для чтения/записи?» — также выбираем Yes и нажимаем клавишу Ввод.
Если вы сделали все правильно, то вы увидите вот такую картинку с процессом установки ОС «Андроид» на виртуальный диск:
Поздравляю! Вы только что установили ОС «Андроид» для систем на базе x86-процессоров на виртуальный диск вашей виртуальной машины.
Но радоваться пока еще рано.
Теперь вы должны увидеть следующее окно:
Выбирите в этом окне пункт меню Машина, затем пункт Закрыть. нажмите на чекбокс «Выключить» и нажмите кнопку Ok.
После того, как вы выключили виртуальную машину, вы должны убрать из виртуального CD-привода образ с системой Андроид: Изъять диск из привода. Он нам больше не понадобится.
Этим мы устанавливаем доступные для нашей виртуальной системы разрешения экрана, которые нам предпочтительно использовать. Жмём Ввод, и все изменения будут внесены в конфигурационные файлы виртуальной машины. Обратите внимание на имя вашей виртуальной машины, в моём примере это «Android 4.0 RC2».
После этого запускаем нашу виртуальную машину:
На первом пункте меню «Android-x86 4.0-RC2» нажимаем клавишу с латинской буквой «A», появится меню с конфигурационной строкой загрузки ОС в конце которой
будет написано «SRC=/android-4.0-RC2», после букв RC2 ставим пробел и пишем «vga=ask» и жмём Ввод. Потом еще раз Ввод. Появится вот такой экран:
Видим 4 созданные нами ранее видеорежима. Набираем на клавиатуре «361» и давим Ввод:
Далее настраиваете ваш Андроид как вам удобно. Не забывайте в меню виртуальной машины выбрать пункт «Машина» и пункт «Выключить интеграцию мыши». После этого вы можете кликнуть левой кнопкой мыши на окне с Андроидом и управлять им с помощью мышки. Выход из этого режима (по умолчанию) клавиша правый Ctrl.
Если Андроид впал в спячку и не реагирует на мышку, то пробудить его можно клавишей «контекстное меню» (нарисовано меню со стрелкой курсора), которая должна располагаться рядом с клавишей «Windows» (с изображением флага).
А теперь самое время подключить нашу среду разработки к виртуальной машине!
В меню окна нашей виртуальной машины жмем «Машина», «Настроить. », «Сеть», «Проброс портов», давим на иконку «+» и создаем новое правило для проброса портов:
IP адрес хоста 127.0.0.1, а IP гостя в моём случае 10.0.2.15. Узнать IP гостя можно следующим образом: в окне с Андроидом жмём комбинацию «Alt+F1» (выход из консоли «Alt+F7»). Попадаем в консоль, где вводим команду netcfg и давим Ввод:
Теперь после проделанных ранее манипуляций, пишем в консоли Windows «adb connect 127.0.0.1:5556» и вуаля!
А теперь самое вкусное!
Смотрим в настройках вашей сети DNS адреса провайдера,
Нажимаем в окне Андроида «Alt+F1» и вводим (в моем случае это DNS адрес 80.243.64.67):
(Вы должны ввести DNS адрес своего провайдера интернета).
VirtualBox — Запуск Android эмулятора в виртуальной среде для тестирования Android проекта
Введение
В данной статье я постараюсь описать пример инфраструктуры для автотестов Android приложений (mobile automation), а именно, среду для проведения тестранов UI автотестов на эмуляторе Android девайса в виртуальной среде.
Требования:
Для Android эмулятора нужна поддержка Intel Virtualization Technology или AMD Virtualization. Поэтому часто тестировщик сталкивается с необходимостью запуска тестранов только в нативной среде ПК с прямым доступом к центральному процессору.
В этом случае схема получается такая:
Трудности:
Невозможно легко пересоздать среду эмулятора.
Среда не создаётся перед проведением тестирования, и после проведения не удаляется, поэтому среда может влиять на тестируемое приложение.
Починка и настройка среды занимает много времени.
Предлагаемое решение в данной статье:
Создать VM с использованием возможностей nested virtualization VirtualBox (более подробное описание технологии в этой статье).
Пробросить поддержку Intel-VT или KVM внутрь созданной виртуальной машины.
Изнутри VM создать и запустить Android эмулятор девайса.
Провести тестран UI тестов приложения.
После проведения тестирования уничтожить VM.
В этом случае схема получится такая:
Предполагаемые преимущества:
VM можно автоматически создавать перед проведением тестирования, а после окончания уничтожать. В таком случае каждый новый тестран будет проведен в идеально чистых условиях.
Уменьшится время поддержки среды и управляющего ПО, так как не нужно каждый раз руками ничего устанавливать и чинить неисправности инвайронмента.
В настоящей статье будет использоваться оборудование:
процеcсор: Intel i5-1035G1
в BIOS включена поддержка виртуализации процессора
Шаг 1: Установка ПО на нативную OS
Отдельно обращу внимание на управление машиной. Будем использовать протокол VNC для создания удобного удаленного рабочего стола. Протокол универсальный, для Linux, Windows, Mac и т.д.
x11vnc сервер
Запуск с параметрами:
Установка VirtualBox
Вводим в командной строке:
Создание VM
Мы пойдем по самому простому пути и создадим VM из интерфейса VirtualBox с такими характеристиками. В дальнейшем создание VM будет code-first
Nested Virtualization можно также включить из командной строки:
Далее переходим в саму VM.
Шаг 2: Установка ПО на VM
В первый раз мы установим всё руками. В дальнейшем весь установочный сценарий будет помещен в Packer, что позволит нам создавать VM с нужными настройками каждый раз перед началом тестирования.
Устанавливаем последний образ Ubuntu с официального сайта.
Установка KVM
Установка Android command line tools
Проверяем, что sdkmanager работает и Android SDK доступен:
Устанавливаем Android tools
Устанавливаем Git и клонируем проект
В данном примере я использую пустой проект мобильного Android приложения. В нём уже есть дефолтный интеграционный тест. Нам этого будет вполне достаточно.
Шаг 3: Проведение тестирования проекта на созданном Android эмуляторе
ADB видит подключенный к нему эмулятор:
Негативный тест
Чтобы убедится, в том что именно позволило нам сбилдить тесты, мы сделаем один негативный тест и воспроизведем запуск эмулятора в обычной VM.
Переустановка VirtualBox на родительской машине (чтобы избежать ошибочное сохранение конфигов)
VM мы создаём без проброса виртуализации и с одним CPU:
В созданной VM мы не устанавливаем:
Остальные шаги аналогичны шагу №2 с установкой ПО. Попробуем еще раз наш тестран. Обратите внимание, что ADB также видит эмулятор:
Ура! Тест не пройден! Никогда еще так не радовался проваленному тестрану:
Падает PackageManager, как и обычно при запуске из виртуальной среды без аппаратной поддержки процессора:
Заключение
Мы сделали первый этап построения инфраструктуры для проведения автотестов Android приложений. Следующим этапом должно стать упаковка описанного выше сценария в Packer (ссылка на официальный сайт) который умеет работать с образами VirtualBox. Затем весь сценарий мы попробуем запустить из CI Jenkins. Если учесть, что плагин для него уже порядком устарел, то будет очень интересно.
Все результаты опубликую, как пополнения к этой статье.
В идеале, у нас должна получится code-first инфраструктура для тестрана UI и интеграционных автотестов для Android приложений, которую можно поднять на любом современном офисном ПК, которая работает автономно, билдит тесты на родных Android эмуляторах и есть не просит.
Сэмулируй сборку приложения ARM на x86 процессоре на примере Qt
Мощность современных процессоров растёт, как в стационарных компьютерах, так и в различных embedded устройствах, на борту которых процессоры на базе ARM с операционной системой linux. Сегодня в рамках данной статьи мы запустим эмулятор процессора ARM на x86 компьютере и в нём попробуем собрать Qt из исходников и тестовое приложение, т.е. так сказать сиэмулируем сборку ARM приложения.
В первой части статьи будем использовать эмулятор QEMU для aarch64, во второй части запустим эмулятор Raspberry и проверим работоспособность приложения в нём.
От себя хочу отметить, это все делается не быстро, и если Вы попробуете все это выполнить, то полный цикл займет у вас несколько дней!)
Собираем из исходников Qt на CentOS ARM
Для установки на хост системе нам потребуется установить эмулятор QEMU. В Debian based дистрибутивах это пакет qemu-system-arm. Для управления виртуальной машины в графическом режиме можно установить virt-manager.
После запуска создаем виртуальную машину:
Задаём количество процессоров и оперативной памяти:
Задаём размер системного диска:
Финальные настройки, выбор сети:
Для тех, кто хочет загружать или устанавливать оффлайн, есть образ диска:
Дальше необходимо установить систему на жёсткий диск в текстовом режиме, выбирая необходимые варианты ответов, и подтверждая ответами yes:
Сборку будем совершать на втором виртуальном диске, для этого нам достаточно будет диска на 25-30 Gb. Создаем новый жесткий диск, выключив виртуальную машину и подключив его к ней и после этого запускаем снова. Разобьем наш жесткий диск и отформатируем:
После установки, подключаемся в виртуальную машину и устанавливаем необходимые нам пакеты:
Повторяем запуск конфигурирования и получаем:
Установим компилятор и снова конфигурируем:
Ищем и доставляем необходимые пакеты:
Конфигурируем, и получаем уже одну ошибку:
Добавляем еще пакетов и смотрим лог конфигурирования:
Ну что же, всё готово, но нужно проверить опции, которые возможно нам пригодятся:
И всё таки сетевое взаимодействие приложения нам наверное потребуется, не работать же только по http:
Придётся нам собрать OpenSSL и потом уже собирать Qt из исходников:
Сборка приложения падает на:
Устанавливаем допонительные версии пакетов и с попытки 3 у нас это получается:
2. Запускаем в эмуляторе Raspberry
Так как в рамках данной статьи мы эмулируем ARM процессор, значит запускать будем тоже в виртуальной машине ссылка 1 ссылка 2 ссылка 3:
Скачиваем официальный образ с сайта Raspberry, ядро для эмулятора и запускаем (я создал такой запускной файл):
Пробуем запустить наше приложение:
Почему так? Смотрим процессор:
Смотрим файл конфигурации в CentOS:
Ну что же, мы собрали приложение для armv8 64 битное, и пытаемся запустить его в 32 битном эмуляторе с процессором armv6. Надеюсь, что владельцы реальных устройств с новыми 64 битными процессорами смогут отписаться в комментариях, получилось ли у них запустить приложение на реальном устройстве или нет.
В скрипт запуска добавьте еще один жесткий диск:
После запуска отредактируйте этот жесткий дискsudo cfdisk /dev/sdc:
Write и подтверждение yes:
Не забываем проверить, что диск у нас стал нужного нам размера:
Что-то размер диска sdc, подключенного к папке /test не добавился, давайте это исправлять:
Теперь мы можем подключить жесткий диск с исходниками Qt от первой виртуалки.
Совет: лучше всего «зачистить исходники» от временных файлов, т.е. вернуть наше состояние гит, которое было на момент клонирования репозитария перед конфигурированием:
Итак в Debian нам потребуются:
Так же получив ошибки:
Установим еще dev пакеты:
. Done.
Info: creating super cache file /30/qt5/.qmake.super
Info: creating cache file /30/qt5/.qmake.cache
Info: creating stash file /30/qt5/.qmake.stash
This is the Qt Open Source Edition.
You have already accepted the terms of the Open Source license.
Running configuration tests…
…
Note: Option ‘cache_use’ with value ‘none’ was specified twice
Note: Also available for Linux: linux-clang linux-icc
Note: Disabling X11 Accessibility Bridge: D-Bus or AT-SPI is missing.
WARNING: QDoc will not be compiled, probably because libclang could not be located. This means that you cannot build the Qt documentation.
Either ensure that llvm-config is in your PATH environment variable, or set LLVM_INSTALL_DIR to the location of your llvm installation.
On Linux systems, you may be able to install libclang by installing the libclang-dev or libclang-devel package, depending on your distribution.
On macOS, you can use Homebrew’s llvm package.
On Windows, you must set LLVM_INSTALL_DIR to the installation path.
Qt is now configured for building. Just run ‘make’.
Once everything is built, you must run ‘make install’.
Qt will be installed into ‘/Qt/5.15.0’.
Prior to reconfiguration, make sure you remove any leftovers from
the previous build.
real 91m49.471s
user 78m43.608s
sys 7m22.934s
Те, кто дочитал до данного места и у кого остался еще энтузиазм попробовать это, было бы интересно получить Ваш FPS результат скорости выполнения этапа конфигурирования с описанием процессора, на котором Вы запускали. Данный результат, это запуск на Intel Core i5 7th Gen. Для эксперимента перед запуском, выполните совет по «зачистке» исходников из предыдущей графы статьи.
Теперь 1 ядро вашего компьютера будет очень много времени собирать Qt и возможно соберёт, а возможно появится ошибка, что не хватает памяти или ошибка при сборке. Для этого рекомендую создать файл подкачки на 1-1,5 Gb и подключить его:
Собираем и устанавливаем:
Если необходимо дополнительные модули, тогда мы всегда можем их дособрать, например для qtquickcontrols2:
После этого собираем приложение, и запускаем его:
Заключение
Собирать приложения для ARM возможно на x86 устройствах, используя эмулятор QEMU. Я думал, что напишу данную статью за одну неделю, но процесс затянулся практически на три недели, потому что каждый из этапов длится очень долго (установка системы, обновление системы, установки dev пакетов, а так же получение исходных кодов Qt из гитхаб). К примеру сборка static версии Qt в эмуляторе Raspberry занял у меня 1426 минут.
А можно ли быстрее?Да, это называется Cross build. Для этого конфигурируют sysroot, устанавливают компилятор для ARM, конфигурируют и собирают Qt в вашей host системе. Потом настраивают QtCreator на использование данной версии Qt и собирая приложение на своём компьютере/ноутбуке x86, получают версию, которая будет работать в embedded linux. ссылка 1 ссылка 2 Т.к. это уже выходит за рамки данной статьи, возможно я напишу и про это, если у меня появится время или вдохновение, но может быть кто-то и другой напишет, как это сделать для последней версии Qt 5.15.
Ну повторюсь, если кто-то захочет повторить действия из второй главы для эмулятора ARM Raspberry, то можете написать, сколько времени происходит у Вас сборка qmake и этап конфигурирования с указанием вашего процессора в комментариях.
Спасибо за внимание. Удачи Вам в творчестве!
Приручаем ARM. Как тестировать программы для мобильных устройств и embedded в Windows
Содержание статьи
Планшеты и одноплатные микрокомпьютеры используются хакерами для самых разных целей — от создания собственного интернет-телефона или радиостанции до установки скрытого видеонаблюдения и управления электронными замками. Тестировать нужные программы и мобильные приложения можно, не выходя из Windows и даже не имея тестового железа. Делать это помогают две вещи: эмуляция архитектур ARM и MIPS на процессоре x86-64 и запуск Android (Arch Linux, Raspbian. ) в качестве гостевой операционки.
Эмуляторы и средства виртуализации существовали давно. Долгое время они были специфическими инструментами со сложной конфигурацией и работали очень медленно. Их современный период начался в 2006 году, когда французский программист Фабрис Беллар представил свой эмулятор QEMU (Quick EMUlator). В определенных условиях он работал очень быстро из-за использования динамической трансляции кода.
Ставим эмулятор
Устанавливается он простой распаковкой ZIP-архива, а со страницы проекта можно скачать исходные коды или готовые бинарники для Linux, Windows, FreeBSD и OS X. QEMU умеет эмулировать процессоры Intel и AMD с архитектурами x86 и x86-64, а также PPC 440, PPC 970, S/390, ARM (Cortex A15, Arch64) и MIPS32. Полный список насчитывает 56 процессорных архитектур, включая исключительно редкие.
Поддержка 56 процессорных архитектур в QEMU
Xakep #201. Как стать киборгом
Из-за всеядности и легковесности этот эмулятор часто используют при отладке программ, предназначенных для разных микрокомпьютеров и гаджетов. К примеру, можно писать в Windows программы для Raspberry Pi и сразу же проверять их без копирования в память микрокомпьютера. В качестве конкретного примера возьмем эмуляцию ОС Raspbian. Мучений предстоит много, но все они будут однократными.
Нам понадобится ядро Linux, скомпилированное для архитектуры ARM, и последняя версия Raspbian. Поместим ядро Linux ARM в каталог QEMU и распакуем туда же Raspbian.zip. Приступим к конфигурации виртуального диска, чтобы на нем появилось место для нашего кода.
Добавляем пару гигабайтов свободного места к образу диска:
Создадим для удобства в каталоге QEMU батник и запишем в него команды запуска эмулятора с определенными параметрами: имитировать процессор архитектуры ARM, выделить 256 Мбайт в ОЗУ и создать виртуальный дисковый раздел с файловой системой ext4. Это все одна строка, но длинная:
Если задать больше 256 Мбайт, то эмулятор вылетит с ошибкой, но в реальном Raspberry Pi Model A памяти как раз столько.
Загрузив Raspbian в режиме командной строки, откроем с помощью текстового редактора nano список динамических библиотек, которые будут загружены перед программой.
Нам требуется всего лишь задать # в начале строки /usr/lib/. и сохранить изменения. Выходим по нажатию и жмем Y.
Настраиваем эмулятор
Затем продолжим делать более глубокие настройки. Создадим новый файл с правилами для менеджера устройств:
Запишем в него символьные ссылки:
Сохраним изменения, выйдем из режима эмуляции и продолжим настройку в среде Windows. В созданном ранее батнике убираем ненужные больше опции загрузки init=/bin/bash вместе с предшествующим пробелом. Пересохраняем батник и запускаем его снова.
При загрузке может появиться несколько сообщений об ошибке, но все они некритичные и могут быть проигнорированы. Снова создадим правила для менеджера устройств, поскольку конфиг изменился:
И опять запишем в него символьные ссылки:
Эмуляция завершится, и после перезапуска нашего батника начнется нормальная загрузка Raspbian, во время которой надо будет ввести логин и пароль. По умолчанию логин — pi, пароль — raspberry.
Чтобы использовать ранее добавленные два гигабайта, нам требуется попасть в меню конфигурации:
Настройка Raspbian в QEMU
Когда выберем первый пункт открывшегося меню (Expand Filesystem), оно исчезнет на несколько секунд, а виртуальный раздел /root partition увеличится на два гигабайта (размер можно задать произвольный). Нажимаем Finish, соглашаемся на перезагрузку и снова запускаем Raspbian через батник. Можно сразу обновить дистрибутив классической связкой команд update и upgrade в одну строку с автоподтверждением действий:
Если нужен графический интерфейс, то приступаем к опциональному этапу конфигурации. В нем понадобится выбрать третий пункт меню настроек (Enable boot to Desktop), где мы указываем загрузку «иксов» для пользователя pi:
Там же можно выбрать другую раскладку и дополнительные опции. После перезагрузки система автоматически запустит десктоп с чернобыльской малинкой на весь экран.
Запуск Raspbian в графическом режиме
QEMU в качестве конвертера
При необходимости можно конвертировать образы виртуальных машин друг в друга с помощью QEMU:
Поддерживаются форматы RAW, QED, Qcow2, VDI, VMDK и VPC.
Эмулируем Android
QEMU — проект опенсорсный, так что он быстро развивался и обрастал дополнениями. Фактически он стал основой для Oracle VirtualBox и многих других эмуляторов. Одновременно росло и число задач, решаемых с помощью виртуальных машин. Например, прежде чем ставить сомнительное приложение на смартфон или планшет, его удобно проверить в изолированной среде.
Раньше для этого приходилось использовать эмуляцию ядра ARM и мириться с неизбежными тормозами. Сейчас все стало гораздо проще, поскольку в рамках проекта Android-x86 волонтеры портируют исходный код гугловской операционки на платформу x86. Текущая версия Android 4.4 в два счета поднимается с дефолтными настройками как «другая 32-битная ОС Linux». В ней можно экспериментировать с новыми программами и выполнять их детальный анализ (например, с помощью модулей AVL Pro v.2.x). Можно даже получать на халяву платный софт на общую сумму до 10 тысяч долларов (с одного аккаунта с виртуальной пропиской в США), став участником программы лояльности Amazon Undeground. Загруженные APK без проблем переносятся на реальное устройство.
Анализ мобильных приложений в виртуальной среде Android-x86
Если же под видом интересного приложения в Android-x86 установится троян-шифровальщик, биткойн-майнер или скрытая звонилка на платные номера, то их можно будет безнаказанно препарировать в той же виртуалке, перехватывая управление и откатываясь на предыдущее состояние.
Защита от запуска в виртуальных машинах
Иногда исследование программ и особенно разных зловредов в виртуальной машине оказывается сильно затруднено. Дело в том, что у виртуалок есть специфические и общеизвестные идентификаторы устройств (например, BIOS, CPUID или MAC). Все они либо имитируют древние платформы, которые работают на совершенно немыслимых частотах (вроде Pentium II, запущенного на трех гигагерцах), либо прямо указывают виртуальный характер устройства.
Установить такой рекорд разгона можно только в виртуалке
Если в виртуалке запускается любая версия Windows, то ее реестр наполняется прямыми указаниями на поставщика драйверов и эмуляцию физических устройств. Строки с текстом VMware, VirtualBox, Parallels Tools Device будут часто встречаться в секции оборудования \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ и
других ветках реестра, где у запущенной на реальном железе системы их быть не должно.
Маркеры виртуальных устройств
В программу может быть встроена функция определения виртуальной среды и защиты от исследования в ней. Осознав себя в Матрице, хитрый вирус просто впадет в спячку до запуска на реальном железе.