Что такое виртуалка на android
Что такое виртуалка на android
Краткое описание:
Запуск виртуальной машины на базе Android.
VMOS is an APP software based on Virtual Machine (VM). VMOS can be installed in the form of a normal APP to Linux or Android system through VM technology. That is to run another complete Android system through an application Moreover, VMOS is not controlled by the host system. (Android on the phone).
VMOS Features:
— Create a Fake Phone Environment: Use VMOS to create a full virtual Android environment with a working Play store and network connectivity. This virtual Android machine will run Android 5.1.1 and appears as a native OS with full touch control just like you would use on your primary Android system. The Android VM is complete with an app drawer, Google services, and some standard apps like a file manager and internet browser. You can sign in with your gmail account and access the full Play store and download new apps as well.
— Root Support: The virtual machine that you create in VMOS can be rooted without affecting the primary system. This is a good solution for anyone looking to run root apps but don’t have the ability to root their actual phone. This is also an essential feature for developers testing apps. Root access is often required for specific functions of different applications. Now developers can run them without risking corrupting the primary system.
— Multiple Accounts and Apps: With the ability to run two Android systems on one phone, you can use the virtual space to run duplicated apps with different accounts. The VM is a good way to keep your personal apps and accounts separate from your work. Sign in with your personal email, snapchat, twitter ect. on your main system, then put all of your work related accounts on the VM. You can run VMOS in a floating window, making it easy to switch between systems quickly, giving you faster access to duplicated apps.
ПЕРЕД ТЕМ, КАК ЗАДАТЬ ВОПРОС — ПРОЧИТАЙТЕ ШАПКУ!
Если установить образ VMOS выше версии вашего Android на устройстве, то образ не запустится по ограничению ядра.
VMOS Pro не запустится, если в вашем устройстве менее 2ГБ ПЗУ-памяти
Приложение позволяет создать «второе пространство» внутри себя (с приложениями которые вы туда установите), работает одновременно и независимо с другими приложениями пользователя (при достаточном количестве оперативной памяти). Это не эмулятор и в Recovery через программу не войти!
Версии:
Версия PRO имеет Android 7 и поддерживает 64bit arm v8a приложения, возможность иметь несколько разных виртуальных машин и многое другое. Является улучшенной версией старого VMOS.
GL — глобальный релиз программы, имеет английский язык, редко обновляется
CN — китайский билд, имеет китайский язык, часто обновляется, в связи с этим имеет больший функционал в отличии от глобальной
Q. На какой телефон можно установить приложение?
A. Телефон должен иметь больше 32 ГБ памяти и 3 ГБ оперативной памяти, также телефон должен работать на версии android 5.1 и выше.
Q. Как дела с быстродействием системы?
A. На самом деле, данное приложение работает быстрее, чем облачные, так как все данные хранятся в локальном хранилище.
Q. Почему VMOS нужен доступ к хранилищу, информации об устройстве, расположению, IMEI и аудио?
A. VMOS требует данные разрешения для лучшего эмулирования системы.
Q. VMOS безопасен для реального устройства?
A. Конечно, реальный телефон и VMOS используют разные операционные системы. Данные из обеих систем не будут мешать друг другу.
Внимание, лайфхак! Если изучить шапку темы, то ты получишь ответ на 99% своих вопросов и проблем!
Android изнутри: сравнение Dalvik и ART
Привет, Хабр! Около полугода назад я публиковал подробный «гайд» по JVM. Пост, в целом, зашел, а в комментариях спросили, не планируется ли “чего-то по андроиду”. Наконец, у меня дошли руки.
В этом посте поговорим о среде выполнения в Android. В частности, я постараюсь кратко, но емко изложить, чем отличается ART и Dalvik, и как со временем улучшились средства разработки в Android. Тема явно не новая, но, надеюсь, придется кстати тем, кто только начинает вникать. Кому интересно — добро пожаловать под кат.
Виртуальная машина
Сначала, давайте разберемся чем отличается JVM от DVM.
Java Virtual Machine — виртуальная машина, способная выполнять байт-код Java независимо от базовой платформы. Она опирается на принцип “Write once, run anywhere”. Байт-код Java может быть запущен на любой машине, способной поддерживать JVM.
Можно сказать, что Dalvik — это среда для выполнения компонентов операционной системы Android и пользовательских приложений. Каждый процесс выполняется в своём, изолированном адресном пространстве. Когда пользователь запускает приложение (либо операционная система запускает один из своих компонентов), ядро виртуальной машины Dalvik (Zygote Dalvik VM) создает отдельный, защищенный процесс в общей памяти, в котором непосредственно разворачивается VM, как среда для запуска приложения. Другими словами, изнутри Android выглядит как набор виртуальных машин Dalvik, в каждой из которых исполняется приложение.
Подробно об архитектуре DVM можно почитать тут.
Android Dexer
Изначально, class-файлы преобразовывались в dex-файлы с помощью встроенного DX-компилятора. Но начиная с Android Studio 3.1 и далее, компилятором по умолчанию стал D8. По сравнению с DX-компилятором, D8 компилирует быстрее и выводит dex-файлы меньшие по размеру, при этом обеспечивая более высокую производительность приложения во время исполнения. Полученный таким образом байт-код dex подвергается минификации с помощью open-source утилиты ProGuard. В итоге, мы получаем тот же dex-файл, но только меньше. Далее этот dex-файл используется для сборки apk и, наконец, для развертывания на устройстве Android.
Но следом за D8 в 2018 году пришел R8, который, по сути, является тем же D8, только с дополнениями.
При работе с Android Studio 3.4 и Android Gradle 3.4.0 plugin или выше, Proguard больше не используется для оптимизации кода во время компиляции. Вместо этого плагин работает по умолчанию с R8, который сам выполняет Code shrinking, Optimisation и Obfuscation. Хотя R8 предлагает только подмножество функций, предоставляемых Proguard, он позволяет совершить процесс преобразования Java байт-кода в dex-байт-код единоразово, что еще больше сокращает время сборки.
R8 и сокращение кода
Как правило, приложения используют сторонние библиотеки, такие как Jetpack, Gson, Google Play Services. Когда мы используем одну из этих библиотек, часто в приложении используется только малая часть каждой отдельной библиотеки. Без Code shrinking, весь код библиотеки сохраняется в вашем приложении.
Бывает так, что для улучшения читаемости и удобства поддержки приложения разработчики используют подробный код. Например, могут быть использованы значимые имена переменных и шаблон проектирования для того, чтобы другим было удобнее разобраться в коде. Но шаблоны, как правило, приводят к бОльшему объему кода, чем это необходимо.
В этом случае R8 приходит на помощь. Он позволяет существенно уменьшить размер приложения, оптимизируя размер даже того кода, который действительно используется приложением.
В качестве примера, ниже преведены цифры из доклада Shrinking Your App with R8, который был представлен на Android Dev Summit ’19:
А вот так выглядело сравнение эффективности R8 на этапе выпуска бета-версии (взято из источника Android Developers Blog):
Детальнее можно ознакомиться в оф документации и докладе.
ART vs DVM в Android
DVM была спроектирована именно для мобильных устройств и использовалась как виртуальная
машина для запуска андроид приложений вплоть до Android 4.4 Kitkat.
Начиная с этой версии, ART был представлен как среда выполнения, а в Android 5.0 (Lollipop) ART полностью заменил Dalvik.
Основное явное отличие ART от DVM состоит в том, что ART использует AOT компиляцию, а DVM — JIT компиляцию. Не так давно ART начал использовать гибрид AOT и JIT. Далее разберем это чуть подробнее.
И небольшая схема Dalvik vs ART:
JIT + AOT в ART
Среда выполнения Android (ART), начиная с Android 7, включает компилятор JIT с профилированием кода. JIT-компилятор дополняет AOT компилятор и повышает производительность во время выполнения, экономит место на диске и ускоряет обновления приложений и системы.
Происходит это по следующей схеме:
Вместо того, чтобы запускать AOT-компиляцию каждого приложения на этапе установки, он запускает приложение под управлением виртуальной машины, используя JIT-компилятор (почти так же, как в Android
BYOD в контейнере: виртуализуем Android. Часть первая
В пятницу на Хабре было опубликовано видео о том, как работает виртуализация на смартфонах Android. Ее разработали и довели до стадии прототипа в Parallels Labs два студента кафедры МиИТ Академического университета Санкт-Петербурга в рамках своей магистерской работы. Мне посчастливилось узнать, что у технологии под капотом, а также спросить участников проекта, какие задачи они решали, как преодолевали возникающие трудности и к чему в результате пришли. Обзор запланирован в двух частях. В этом посте будет короткий обзор существующих решений для виртуализации на Android, понятные схемы архитектуры нашего решения, короткое видео того, как все работает. Во второй части будет больше конкретики. Речь пойдет о виртуализации телефонной части смартфонов, звуковой подсистемы и системы ввода.
Я покажу, что у нашего решения под капотом. Расскажу, какие задачи решала группа разработчиков, как преодолевались возникающие трудности и какой результат был достигнут. Статья состоит из двух частей. В первой (под катом) будет короткий обзор существующих решений для виртуализации на Android, понятные схемы архитектуры решения, короткое видео того, как все работает.
Введение: зачем всё это нужно?
Концепция Bring Your Own Device (или BYOD), когда сотруднику разрешено работать с самым удобным для него «железом», — палка о двух концах. С одной стороны, юзеру удобно использовать на службе то, чем он привык пользоваться дома. Это теоретически повышает его производительность труда. С другой — BYOD добавляет головной боли системным администраторам и IT-директорам, которые вынуждены каким-то образом решать задачу защиты корпоративных приложений и данных, которые теперь крутятся на смартфоне. Один из основных подводных камней – пользовательское поведение. Часто юзеры игнорируют запрет на закачку и установку демо-версий стороннего ПО, хотя внутри таких приложений может прятаться вирус или «троянец».
Очевидный способ оградиться от такого рода угроз – создать для ненадежного ПО специальную «песочницу»; либо, наоборот, создать такую «песочницу» для корпоративного софта и бизнес-данных. Оба подхода должны быть реализованы деликатно, то есть без посягательств на частную (SMS, фотки с вечеринок и др.) информацию сотрудника. Такие «песочницы» встречаются сплошь и рядом в индустрии разработки и тестирования ПО и создаются с помощью виртуализации. Мы решили сделать нечто подобное, но – на смартфонах.
Ищем аналоги
Прежде чем погружаться в технические детали, рассмотрим весь зоопарк существующих решений и технологий виртуализации. Это нужно, чтобы понять, какой же конкретно подход может быть интересен для реализации нашей технологии. Первые известные попытки виртуализации мобильных устройств были начаты в 2008 году, и к настоящему моменту имеется несколько успешных подходов и проектов. Конечно, мы рассматривали наиболее зрелые и жизнеспособные подходы. Все они собраны для наглядности на одной на картинке, о каждой будет несколько слов отдельно.
Cells – первый проект, в рамках которого создана технология контейнерной виртуализации для платформы Android. (Что такое контейнеры и почему Android удобнее всего виртуализировать с помощью контейнеров, мы разберем немного позже.) Технология обеспечивает совместный доступ одновременно работающих окружений Android к устройствам ввода, графическому ускорителю, модулю сотовой связи и сетевым устройствам, а также позволяет ограничивать доступ контейнера к каждому системному устройству. Измерения показывают, что требования этой технологии к вычислительным ресурсам, а также расход заряда батареи устройства компонентами этой технологии незначительны.
VMware Horizon Mobile — полноценный гипервизор второго типа, виртуализирующий аппаратное обеспечение абстрактной машины. Под проект было создано ядро Linux с патчами Android, поверх которого запускается созданное VMware пользовательское окружение Android. Гипервизор работает на распространенных типах процессоров ARM, не имеющих расширений для аппаратной виртуализации, и является процессом в хостовой (основной) ОС — например, в родной для Android-девайса операционке. Очевидно, что в данном случае виртуализация всего аппаратного обеспечения требует достаточно много вычислительных ресурсов. Но, что еще важнее, запуск более чем одного гипервизора будет слишком быстро «высаживать» батарейку. Планшет, разряжающийся за полчаса, никому не нужен. К тому же подход VMware показался существенно сложнее в реализации, чем подход Cells.
TrustDroid является прототипом системы изоляции приложений для платформы Android, основанной на доменах доверия. Каждому приложению (в том числе стандартным приложениям Android) назначается домен. Приложения из разных доменов не могут взаимодействовать между собой и не могут работать с данными, опубликованными приложениями из других доменов. TrustDroid не использует виртуализацию аппаратного обеспечения или пространства пользователя. Для поддержки политики доменов изменения вносятся в ядро и в стандартные системные приложения Android. Данная система является самой нетребовательной к ресурсам по сравнению с двумя предыдущими.
Реализация сценариев BYOD и создание песочницы различна: в случае Cells и VMware политики настраиваются на уровне пользовательских окружений Android; при использовании же TrustDroid пользователю необходимо настраивать политики и домены вручную для каждого приложения. Это сложнее и муторнее для пользователя, потому что пользовательских окружений может быть несколько. У TrustDroid не все ОК с безопасностью. Предполагается, что стандартные системные приложения Android и ядро ОС никогда не скомпрометированы, но это может быть неверно, т.к. при получении прав суперпользователя их можно подменить.
Недостатки можно преодолеть, значительно доработав TrustDroid. Тем не менее, TrustDroid решает только задачу обеспечения безопасности на устройстве, в то время как пользователю также важна возможность изоляции данных, находящиеся в разных окружениях.
EmbeddedXEN — проект по портированию XEN на платформу ARM. Проект, насколько мне известно, пока не вышел из стадии активной разработки, а посему не может рассматриваться как законченное решение. В настоящее время в проекте уже адаптированы версии ядра Linux HTC Desire HD для работы в качестве Dom0.
Контейнерная виртуализация – это выход
LXC — надстройка над инфраструктурой пространств имен ядра Linux. Он не покрывает все потребности, возникающие при создании полностью изолированных контейнеров. Например, LXC не предоставляет механизмов виртуализации sysfs и стандартных устройств, таких как виртуальный терминал. Технология OpenVZ предоставляет все необходимые возможности для создания полностью изолированных контейнеров и широко используется хостерами. Поэтому первым делом разработчики попробовали портировать ее на ядро Linux, используемое в Android.
Портирование такого количества изменений на ядро 2.6.35 показалось нам чрезмерным. Но, отказавшись от OpenVZ, мы лишились готового решения по виртуализации sysfs: при создании нового виртуального окружения OpenVZ копирует дерево системных объектов (kobject) корневого пользовательского окружения, что потребовало от нас дополнительных усилий.
Итак, решено было использовать стандартные Linux-контейнеры LXC и всю инфраструктуру ядра, отвечающую за реализацию пространств имен (namespaces) и разграничение групп ресурсов.
На рисунке показана архитектура нашего решения.
Механизм управления контейнерами
Binder
Драйвер ядра binder — это механизм IPC, разработанный в рамках проекта AOSP. Наличие оригинального, отличного от стандартного IPC до конца не ясно, однако детали реализации binder были одним из препятствий для запуска нескольких виртуальных окружений Android. Проблема состояла в следующем. В этом драйвере есть статические переменные, значения которых можно установить системным вызовом ioctl. Этот системный вызов делает программа servicemanager, запускаемая в процессе инициализации Android. Драйвер binder проверяет, инициализированы ли эти переменные и, если да, то возвращает ошибку, что приводит к завершению программы servicemanager, а поскольку эта программа необходима для работы Android – то и к прекращению инициализации Android.
Таким образом, потребовалось создавать экземпляры упомянутых выше переменных для каждого контейнера и обращаться к экземпляру виртуального состояния, принадлежащему контейнеру, в контексте которого был сделан системный вызов ioctl().
Виртуализация периферийных устройств
Большой задачей виртуализации Android является виртуализация периферийных устройств и мультиплексирование потоков данных. Почти везде мы использовали один и тот же подход, который можно назвать виртуализацией состояний.
Android предполагает, что использует периферийные устройства монопольно. Драйверы этих устройств часто написаны исходя из предположения, что их использует только одна ОС. При запуске нескольких Android на одном устройстве в периферийных устройствах, их драйверах, программном стеке Android возникают критические ошибки.
Таким образом, для работы нескольких Android в контейнерах требуется обеспечить возможность одновременного использования периферийных устройств всеми операционками.
Далее мы рассмотрим как будет выполнена виртуализация графического экрана, а в следующей статье поговорим о виртуализации телефонии, звука и тачскрина.
Дисплей
Необходимость в разделении доступа контейнеров к экрану очевидна. При запуске нескольких контейнеров каждый из них начинает отображать свой UI на экране. Естественно, если не договориться о том, какой контейнер обладает эксклюзивным правом использовать экран, то на экране получится смешение пикселей и элементов интерфейса. Чтобы такого не происходило, экран надо виртуализовать. Необходимо, чтобы физическое устройство было подменено на виртуальное.
Согласно Android Porting Guide, для доступа к экрану используется драйвер типа Linux Framebuffer, и для портирования необходимо реализовать данный драйвер. Linux framebuffer имеет простой интерфейс, состоящий из двух десятков функций, большинство из которых имеют реализацию по умолчанию. Драйвер используется из пространства пользователя.
Перепрограммирование MMU GPU
Кроме драйвера фреймбуфера к физическому экрану имеет доступ GPU. Чтобы неактивные ОС не отображали свой UI на экране, требуется подменить операцию отображения их кадров. Выяснилось, что в случае с подопытными Google Nexus S и Samsung Galaxy SII экраны смартфонов копируют кадр для отображения из RAM при помощи DMA. Драйвер фреймбуфера сообщает экрану адрес, по которому находится кадр, предназначенный для отображения (память экрана). Таким образом, операция отображения кадра на экране выглядит как операция записи кадра в RAM устройства по определенному адресу.
Чтобы подменить операцию записи в RAM, требуется установить кем она может выполняться. В случае с обработкой графики запись кадра могут выполнять GPU или CPU. Современные GPU и CPU имеют в своем составе MMU. Для того чтобы кадры неактивных Android не записывались в память экрана, достаточно подменить отображение адресов в MMU так, чтобы адреса неактивных Android, отображаемые в память экрана, фактически указывали на обычный буфер в RAM устройства. Назовем его теневым буфером.
Теневой фреймбуфер
Android отрисовывает свой UI по мере его изменения, а не по таймеру. Поэтому если просто перенаправить MMU на память экрана при переключении активного Android, то активный Android может не перерисовать кадр на экране и изображение на нем окажется от предыдущего активной ОС.
Если выделить теневой буфер для каждого Android, то при переключении активной ОС достаточно скопировать кадр на экране в теневой буфер предыдущего активного Android. Чтобы отобразить Android, ставший активным, требуется скопировать содержимое его теневого буфера в память экрана. Но теневой буфер занимает от 2 до 4 Мб физической памяти. Имея возможность вызывать перерисовку кадра при переключении активного Android, можно избавиться от выделения теневого буфера для каждого Android, оставив единственный теневой буфер.
Такая возможность предоставляется механизмом fb_early_suspend. Теневой буфер теперь становится не местом хранения кадра Android, а местом куда все неактивные ОС пишут свою картинку. Кроме того благодаря наличию MMU можно сократить размер теневого буфера до одной страницы физической памяти, отобразив все 2−4 Мб адресов в единственную страницу.
Виртуальный драйвер Linux Framebuffer
Типичный сценарий использования драйвера Linux Framebuffer заключается в отображении памяти экрана в адресное пространство пользовательского процесса системным вызовом mmap() и вызовах стандартных и специальных IOCTL.
Стандартные IOCTL обрабатываются стандартным обработчиком IOCTL подсистемы Linux Framebuffer в ядре ОС. Специальные IOCTL имеют нестандартную семантику и могут быть обработаны только драйвером физического Linux Framebuffer. Так как физический Linux Framebuffer был подменен на виртуальный, то mmap() и IOCTL вызываются у драйвера виртуального Linux Framebuffer.
Все вызовы mmap() обрабатываются полностью в драйвере виртуального Linux Framebuffer без использования драйвера физического Linux Framebuffer, т.к. семантика этого системного вызова стандартна. Процессы активного Android при вызове mmap() получают доступ к памяти экрана. Процессы неактивных Android при вызове mmap() получают доступ к теневому буферу вместо памяти экрана. Для всех запущенных Android создается виртуальное состояние драйвера Linux Framebuffer. Для активного Android все вызовы в драйвер виртуального Linux Framebuffer немедленно перенаправляются в драйвер физического Linux Framebuffer, который изменяет состояние физического драйвера Linux Framebuffer. Для неактивных Android стандартные IOCTL’ы изменяют их виртуальные состояния Linux Framebuffer. Нестандартные IOCTL’ы для неактивных Android возвращают ошибку. На устройствах Google Nexus S и Samsung Galaxy SII этого было достаточно.
Промежуточные выводы
Технология виртуализации Android, построенная на контейнерах Linux, доказала свою работоспособность на нескольких моделях смартфонов. Мы смогли добиться одновременного выполнения любых приложений одновременно с микшированием звука и приемом входящих сообщений и звонков, так как это делал бы каждый их виртуализированных телефонов. Например, наш демо-сценарий показывает, что мы одновременно играем в Andgy Birds и воспроизводим музыку в разных контейнерах. Вот как это происходит, если кто не видел.
О том, как была реализована виртуализация звука, телефонии и ввода пользователя — в следующей статье.
Что такое виртуалка на android
Краткое описание:
Запуск виртуальной машины на базе Android.
VMOS is an APP software based on Virtual Machine (VM). VMOS can be installed in the form of a normal APP to Linux or Android system through VM technology. That is to run another complete Android system through an application Moreover, VMOS is not controlled by the host system. (Android on the phone).
VMOS Features:
— Create a Fake Phone Environment: Use VMOS to create a full virtual Android environment with a working Play store and network connectivity. This virtual Android machine will run Android 5.1.1 and appears as a native OS with full touch control just like you would use on your primary Android system. The Android VM is complete with an app drawer, Google services, and some standard apps like a file manager and internet browser. You can sign in with your gmail account and access the full Play store and download new apps as well.
— Root Support: The virtual machine that you create in VMOS can be rooted without affecting the primary system. This is a good solution for anyone looking to run root apps but don’t have the ability to root their actual phone. This is also an essential feature for developers testing apps. Root access is often required for specific functions of different applications. Now developers can run them without risking corrupting the primary system.
— Multiple Accounts and Apps: With the ability to run two Android systems on one phone, you can use the virtual space to run duplicated apps with different accounts. The VM is a good way to keep your personal apps and accounts separate from your work. Sign in with your personal email, snapchat, twitter ect. on your main system, then put all of your work related accounts on the VM. You can run VMOS in a floating window, making it easy to switch between systems quickly, giving you faster access to duplicated apps.
ПЕРЕД ТЕМ, КАК ЗАДАТЬ ВОПРОС — ПРОЧИТАЙТЕ ШАПКУ!
Если установить образ VMOS выше версии вашего Android на устройстве, то образ не запустится по ограничению ядра.
VMOS Pro не запустится, если в вашем устройстве менее 2ГБ ПЗУ-памяти
Приложение позволяет создать «второе пространство» внутри себя (с приложениями которые вы туда установите), работает одновременно и независимо с другими приложениями пользователя (при достаточном количестве оперативной памяти). Это не эмулятор и в Recovery через программу не войти!
Версии:
Версия PRO имеет Android 7 и поддерживает 64bit arm v8a приложения, возможность иметь несколько разных виртуальных машин и многое другое. Является улучшенной версией старого VMOS.
GL — глобальный релиз программы, имеет английский язык, редко обновляется
CN — китайский билд, имеет китайский язык, часто обновляется, в связи с этим имеет больший функционал в отличии от глобальной
Q. На какой телефон можно установить приложение?
A. Телефон должен иметь больше 32 ГБ памяти и 3 ГБ оперативной памяти, также телефон должен работать на версии android 5.1 и выше.
Q. Как дела с быстродействием системы?
A. На самом деле, данное приложение работает быстрее, чем облачные, так как все данные хранятся в локальном хранилище.
Q. Почему VMOS нужен доступ к хранилищу, информации об устройстве, расположению, IMEI и аудио?
A. VMOS требует данные разрешения для лучшего эмулирования системы.
Q. VMOS безопасен для реального устройства?
A. Конечно, реальный телефон и VMOS используют разные операционные системы. Данные из обеих систем не будут мешать друг другу.
Внимание, лайфхак! Если изучить шапку темы, то ты получишь ответ на 99% своих вопросов и проблем!