Как стать автором
Обновить

Комментарии 13

какое-то переусложнение задачи
можно взять готовый rpm пакет с предустановленной qemu виртуалкой с android-x86 на их же сайте и после установки одной командой просто её запускать как на десктопе ярлыком в меню так и на сервере без отображения интерфейса qemu. для тестирования и небольших задач самое оно
из преимуществ:
1) никакой винды и hyper-v (в этой задаче это ненужный и медленный пласт)
2) меньше телодвижений (по факту две команды curl для скачивания и rpm -U для установки, можно даже совместить в однострочник)
3) никаких ошибок на этапе создания vm (в пакете уже лежит ярлык запуска vm со всеми нужными флагами)

правда я не знаю насколько это актуально ибо с такими задачами не сталкивался уже пару лет, но раньше применял для разрабов android команды, для тестирования через adb прикручивалось к idea/android/studio. потом вроде бы в студии появилась нативная поддержка qemu но мне уже было не интересно так как клиент не обращался с повторной задачей

upd: глянул, готовые rpm всё ещё выкладывают

Это всё хорошо, когда ты владеешь Linux. Как я понял из статьи, пользователи хотели эмулятор именно на Windows, от этого и все сложности.

может быть я смотрю на это предвзято, с высоты своего может быть не самого популярного опыта. но мне видится так:
1) для разработки и тестирования приложений под android разработчикам windows не нужна совсем, никак, ни зачем (разве что дизайнеру может понадобиться, но на эту тему можно дискутировать отдельно очень долго).
2) писать код и тестировать желательно всё же не на одной машине. написал, запушил, ждёшь пока соберётся и задеплоится в тестовую vm. при необходимости ручного тестирования с qemu это не проблема, vm может жить хоть на другом конце света что не помешает потыкать её хоть гуём хоть через adb.
я понимаю что многие смотрят на решение этой задачи не так как я и всё вышесказанное - ИМХО.

Как правило на виртуальных машинах разворачивают такие эмуляторы не для тестирования и не для разработки. А для каких-то других нужд.
Чисто по логике вещей, я использую все эмуляторы железа обычно под рукой, ибо так удобнее. Если только это не оговорено политикой компании.

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

Согласен с вами, не знаю тех кто пишет или тестирует под android и юзает windows, как то это сложно и мудрено получается. А если не умеешь пользоваться virsh-ом из консоли ставь что нибудь типа VMmanager/Proxmox. Будет тебе создание ВМки из интерфейса одной кнопкой

Ставил десяток раз (на всякий случай и сейчас поставил) и всегда после установки и перезагрузки система вываливается в консоль. Никаких "Здравствуйте" тебе. ЧЯДНТ?

Ради интереса поставил себе на ВМ под Win 8.1, android-x86_64-9.0-r2.iso, всё получилось. Вы ставили видимо 32-битную версию, попробуйте 64.
Кстати, даже не понадобилось вручную прописывать ip адреса, получен автоматом.

Говорят может быть что-то с видеокартой связано или с графическим ускорителем :\

Попробуем-с и 64x.

использую под KVM

export QEMU_AUDIO_DRV=pa
export QEMU_PA_SERVER=/tmp/pulse-PKdhtXMmr18n/native
qemu-system-x86_64 -cpu host -smp 4 -m 4096 \
 -name Anroid8 -machine pc,accel=kvm \
 -soundhw hda \
 -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \
 -chardev spicevmc,id=spicechannel0,name=vdagent \
 -device virtio-net,netdev=user.1,addr=0x4 -netdev user,id=user.1,ipv6=off \
 -device virtio-balloon \
 -drive file="android.img",if=virtio,format=qcow2,index=1 

К сожалению, по какой-то причине Android не прописывает автоматически IP адрес, Шлюз и DNS, и поэтому их надо указать вручную (если кто-то из читателей в курсе, как решить эту проблему, буду рад почитать об этом в комментариях).

Windows по умолчанию умеет в AutoIP, а для Android остаётся либо вручную прописать параметры сети, как описано в Вашей статье, либо поднять DHCP-сервер во внутренней сети, к которой подключена ВМ с Android, т.к. в виртуальной сети Hyper-V инструментов для этого нет. Можно поднять роль DHCP-сервера прям на той же машине, на которой Hyper-V поднят, либо на отдельной ВМ развернуть. Только смысла в этом не вижу, проще руками прописать, если этот DHCP будет использоваться для раздачи адреса единственной машине.

В Hyper-V для Windows 10 (начиная непомнюскакой версии) поднимается виртуальный DefaultSwitch, который даёт NAT + DHCP + кэширующий DNS (на DG) и к которому по умолчанию цепляются все виртуалки. Удалить, модифицировать и отключить его нельзя. В Windows Server аналога обнаружить не удалось, возможно, добавят такие возможности в следующих версиях.

Далее -> далее -> далее -> готово.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий