Подробное руководство по установке Android-x86
Эмулятор который идет в комплекте с Android SDK, не очень шустрый.
Основная идея использовать VirtualBox + Android X86, для преодоления проблем с производительностью.
Что нам необходимо:
Среда разработки Eclipse + Android SDK тут,
а также VirtualBox.
Под катом много картинок, и процесс установки, а также некоторые полезные советы.
Создаем Виртуальную машину:
Имя: Android-2.2-Generic
Операционная система: Linux
Версия: Linux 2.6
Память: 512 MB
Жесткий диск: 3GB
В Настройках машины:
Свойства->Сеть
Адаптер 1 — NAT (в виртуальной машине будет виден как eth0, для интернета).
Адаптер 2 — Виртуальный адаптер хоста (в виртуальной машине будет виден как eth1, для управления ADB).
Подключите образ к виртуальной машине.
И так сверимся какие параметры машины. 
Запускаем виртуальную машину
Управление производится стрелками влево, вправо, вверх, вниз
По шагам как инсталлировать линукс:
В загрузчике выбрать пункт меню
1. Installation — Install Android-x86 to harddisk
Создаем разделы.
2. Create/Modify partitions
Выбрать [New] -> [Primary] -> Size (in MB) 3216 press [ok]
Выбрать [Bootable]
Выбрать [Write] подтвердить запись изменений yes
Выход [Quit]
Выбираем раздел для установки
3. Select partitions to install Android-X86
[sda1 Linux VBOX HARDDISK]
Выбор файловой системы
4. Please select a filesystem to format sda1
[ext3]
Подвердить форматирование Yes
Установка загрузчика GRUB
5. Do you want install boot loader GRUB?
Подвердить Yes
Вы хотите сделать /system для чтения и записи
6. Do you want to install /system directory as read-write?
Подтвердить Yes
В Этом образе идет много примеров Snake,NotePad из Eclipse будет не возможно будет установить свои, в самом низу статьи есть утилита для разрешения данной проблемы.
Процесс установки завершен
7. Android-x86 is installed successfully.
Создаем SD карту
[Create a fake SD Card]
size 2000 MB
отключить CD-ROM
Перегрузить систему
Reboot
Горячие клавиши:
- esc, правая кнопка мыши Назад
- кнопка меню между правым ctrl и alt, на некоторых ноутбуках отсутствует
- alt+f1, alt+f7 переключение между консолями
- alt+курсор влево , alt + курсор вправо
- f6 Выбор режимов, авиа режим, выключение
, перегрузка - клавиша win домой
Если у вас не работает курсор мыши.
Идем в Машина-> Выключить интеграцию мыши host + i ( клавиша host по умолчанию правый ctrl).
Разблокируем экран потянув стрелку вверх
Настройка Сети
По умолчанию эмулятор не может работать с двумя сетевыми адаптерами — не проблема.Нам нужен интернет + внутренний адрес для отладки.
Идем в запуск приложений
Выбираем приложение
Settings -> Configure Ethernet
Ставим eth0 dhcp выбираем save.
Перегружаем Эмулятор.
Когда машина загрузится переключаемся в текстовую консоль alt+f1
Магический порядок
root@android:/ #
# netcfg
# netcfg eth1 down
# netcfg eth1 dhcp
*action ‘dhcp’ failed (invalid argument)*
*без этой комманды не выделялся адрес вообще*
# netcfg eth1 up
# netcfg
Всё выглядит приблизительно так.
Запоминаем адрес eth1 он будет нужен для adb.
Шаги по настройки сети с консолью к сожалению надо делать каждый раз, когда эмулятор стартуете по новой.
Теперь на компьютере переходим в папку где стоит Android-SDK, в вашей системе может другая папка
C:\Program Files\Android\android-sdk\platform-tools\
Используем команду adb eth1 адрес, у меня был 192.168.56.101
Вывод будет подобный:
C:\Program Files\Android\android-sdk\platform-tools>adb connect 192.168.56.101
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
connected to 192.168.56.101:5555
Пример работающего приложения.
Как быть если хочу поставить NotePad,Snake и другие примеры
можно поставить данную утилиту SystemApp_Remover_4_19.ap.
Процесс установки будет выглядеть приблизительно так.
C:\Program Files\Android\android-sdk\platform-tools>adb install c:\temp\SystemApp_Remover_4.19.apk
Потом удаляете из списка системных приложений то с чем конфликтует Eclipse
p/s Переключение видео режимов.
В Меню загрузки нажимаем e
Появится другое меню
kernel /android-2.2/kernel /quiet root .
Еще раз нажимаем e и добавляем в конце строки через пробел vga=ask
Чтобы загрузится нажимаем enter b, и потом выбираем нужный режим из списка.
p/p/s Это мой первый пост на Хабре, не судите строго.
Источник
Виртуальная операционная система 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 — китайский билд, имеет китайский язык, часто обновляется, в связи с этим имеет больший функционал в отличии от глобальной
- Нажать на установку в маркете.
- Принудительно закрыть маркет.
- Снова в него зайти.
Если не заработало — попробуйте перезапустить VMOS.
- VMOS вправе работать нестабильно, как и программы в нём. На вашем устройстве теперь работают сразу две системы.
- Если есть проблемы с одной программой/игрой, можно попробовать поменять как и приложение, так и используемый ром.
- Для более-менее стабильной работы VMOS Pro необходимо 2гб+ ОЗУ.
Q. Как работает VMOS?
A. VMOS — это новая и инновационная технология. Он виртуализирует собственную операционную систему Android на вашем телефоне. С VMOS вы можете переключаться между реальной и виртуальной системами в любое время. Данные и приложения хранятся локально.
Q. На какой телефон можно установить приложение?
A. Телефон должен иметь больше 32 ГБ памяти и 3 ГБ оперативной памяти, также телефон должен работать на версии android 5.1 и выше.
Q. Могу ли я клонировать приложение из реальной системы в ВМ?
A. Да. File→Choose APP→Import [Файл -> выбрать приложение -> импорт].
Q. Как дела с быстродействием системы?
A. На самом деле, данное приложение работает быстрее, чем облачные, так как все данные хранятся в локальном хранилище.
Q. Почему VMOS нужен доступ к хранилищу, информации об устройстве, расположению, IMEI и аудио?
A. VMOS требует данные разрешения для лучшего эмулирования системы.
Q. VMOS безопасен для реального устройства?
A. Конечно, реальный телефон и VMOS используют разные операционные системы. Данные из обеих систем не будут мешать друг другу.
Внимание, лайфхак! Если изучить шапку темы, то ты получишь ответ на 99% своих вопросов и проблем!
Источник
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.
- текущая экспериментальная версия патча OpenVZ есть для ядра версии 2.6.32, но на смартфонах, на которых разрабатывалась и тестировалась технология, работают ядра версии 2.6.35;
- при попытке наложить патч OpenVZ на одно из используемых ядер не удалось пропатчить 166 файлов из 1682; кроме того, патч модифицирует 34 файла, специфичных для архитектуры x86.
Портирование такого количества изменений на ядро 2.6.35 показалось нам чрезмерным. Но, отказавшись от OpenVZ, мы лишились готового решения по виртуализации sysfs: при создании нового виртуального окружения OpenVZ копирует дерево системных объектов (kobject) корневого пользовательского окружения, что потребовало от нас дополнительных усилий.
Итак, решено было использовать стандартные Linux-контейнеры LXC и всю инфраструктуру ядра, отвечающую за реализацию пространств имен (namespaces) и разграничение групп ресурсов.
На рисунке показана архитектура нашего решения.
- Панель управления. Графический интерфейс к LXC; позволяет управлять контейнерами (запуск, остановка, переключение активного контейнера).
- Cупервизор ядра, на рисунке — AndCont supervisor. Инициализирует виртуальное состояние драйверов, перехватывая момент запуска контейнера, реализует переключение между контейнерами.
- Механизм межконтейнерного взаимодействия (ICC). Средство коммуникации между контейнерами на основе Netlink, обходящее проверки в прикладных сетевых протоколах и на основе разделяемой памяти.
- Диспетчер ввода. Нужен для совместного использование устройств ввода Android, работающих параллельно.
- Драйвер виртуального фреймбуфера. Обеспечивает возможность одновременного использования экрана устройства.
- Драйвер GPU. Реализует возможность одновременного использования GPU всеми контейнерами.
- Binder. Драйвер IPC, сделанный в рамках проекта Android Open Source Project (AOSP).
- Alarm. Интерфейс к часам.
- Прокси-сервер для механизма управления радиоинтерфейсами (Radio Interface Layer, RIL). Обеспечивает совместный доступ нескольких контейнеров Android к оборудованию доступа к мобильным сетям.
- Прокси-клиент RIL. Принимает запросы к сервису телефонии от приложений в контейнере и передает их прокси-серверу RIL.
- Прокси-клиент аудио. Получает контроль над звуковыми потоками контейнера и передает их прокси-серверу аудио.
- Прокси-сервер аудио. Воспроизводит звуковые потоки контейнеров.
- Вспомогательный контейнер. Предназначен для запуска системных демонов и библиотек Android, по разным причинам вынесенных из гостевых Android.
Механизм управления контейнерами
- Заблокирован сброс флага CAP_SYS_BOOT, отвечающего за возможность перезагрузки системы, который используется виртульной java-машиной Dalvik при ее инициализации.
- Опущены проверки открытых файловых дескрипторов, отличных от стандартных в lxc_start.
- Исправлен дефект, приводящий к утечке файловых дескрипторов из демона adbd, который используется для доступа к смартфону через USB.
- Добавлены нотификации супервизора уровня ядра о запуске нового контейнера перед запуском процесса init.
Binder
Драйвер ядра binder — это механизм IPC, разработанный в рамках проекта AOSP. Наличие оригинального, отличного от стандартного IPC до конца не ясно, однако детали реализации binder были одним из препятствий для запуска нескольких виртуальных окружений Android. Проблема состояла в следующем. В этом драйвере есть статические переменные, значения которых можно установить системным вызовом ioctl. Этот системный вызов делает программа servicemanager, запускаемая в процессе инициализации Android. Драйвер binder проверяет, инициализированы ли эти переменные и, если да, то возвращает ошибку, что приводит к завершению программы servicemanager, а поскольку эта программа необходима для работы Android – то и к прекращению инициализации Android.
Таким образом, потребовалось создавать экземпляры упомянутых выше переменных для каждого контейнера и обращаться к экземпляру виртуального состояния, принадлежащему контейнеру, в контексте которого был сделан системный вызов ioctl().
Виртуализация периферийных устройств
Большой задачей виртуализации Android является виртуализация периферийных устройств и мультиплексирование потоков данных. Почти везде мы использовали один и тот же подход, который можно назвать виртуализацией состояний.
Android предполагает, что использует периферийные устройства монопольно. Драйверы этих устройств часто написаны исходя из предположения, что их использует только одна ОС. При запуске нескольких Android на одном устройстве в периферийных устройствах, их драйверах, программном стеке Android возникают критические ошибки.
Таким образом, для работы нескольких 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 и воспроизводим музыку в разных контейнерах. Вот как это происходит, если кто не видел.
О том, как была реализована виртуализация звука, телефонии и ввода пользователя — в следующей статье.
Источник
