Android emulator apple silicon preview

Note: No longer needed

Support for downloading the M1-based emulator was added to SDK Manager, so it’s not necessary to go to the Github releases page to download a standalone .app anymore. In AVD Manager go to the Other Images tab as by default it doesn’t show the ARM64 images.

Android Emulator M1 Preview

This is a preview of some basic Android emulation functionality on the M1. There are still many issues, but apps work at a basic level. To be updated soon with more fixes. The release tag corresponds to this commit: https://android.googlesource.com/platform/external/qemu/+/aca144a9e9264b11c2d729096af90d695d01455d

Webview doesn’t work in the AOSP version, but works in the Google APIs version preview v3. However, Chrome doesn’t work.
No device skins
Video codecs not working
32 bit ARM apps won’t work
Graphical glitches in some Vulkan apps
Popup on startup about not being able to find the ADB path (ADB will still notice the emulator if you have it installed though)
When building, it may be faster to start then cancel the Python triggered build and then reissue ninja -C objs install/strip versus letting the Python triggered build finish.

This only works on M1 Apple Silicon Macs. M1 (or equivalently capable) SoCs are required; note that this does not work on DTKs as they do not support ARM64 on ARM64 hardware virtualization via Hypevisor.framework.

Go to the Github releases page, download a .dmg, drag to the Applications folder, and run. You’ll first need to right click the app icon and select Open and then skip past the developer identity verification step (we are working on providing official identity info). The first few times it starts up it will take a while to show up, but subsequent launches will be faster.

If you’ve installed Android Studio and Android SDK and adb is available, the emulator should be visible from Studio and work (deploy built apps, debug apps, etc).

How to configure

Edit /Applications/Android\ Emulator.app/Contents/MacOS/aosp-master-arm64-v8a/config.ini . Some notable options:

disk.dataPartition.size : size of userdata. When reconfiguring, you’ll also need to delete all userdata*.img files in that directory.
fastboot.forceColdBoot , fastboot.forceFastBoot : whether to enable snapshots. Current default is snapshots disabled. Set fastboot.forceColdBoot=no , fastboot.forceFastBoot=yes to enable snapshots.
hw.lcd.density : Virtual display DPI.
hw.lcd.width , hw.lcd.height : Virtual display dimensions.
hw.ramSize : RAM limit for the guest. (2GB minimum)

How to wipe data

Remove all userdata*.img files in /Applications/Android\ Emulator.app/Contents/MacOS/aosp-master-arm64-v8a/ .

How to build your own emulator

Building the engine

The emulator source code lives (here), but there are a bunch of other dependencies to download, so we use repo .

To build, first make sure you have Xcode and Xcode command line tools installed, and that you have Chromium depot_tools in your PATH (link). Then:

Note that canceling the python based build after it gets going and issuing just ninja -C objs install/strip may be faster.

The built artifacts are in /path/to/external/qemu/objs/distribution/emulator . They should be automatically signed. However, the binaries in objs/ are not; to sign them, issue ./sign-objs-binaries.sh . Note that this can only be done after ninja -C objs install/strip is successful.

Building the system image

The system image is built from AOSP master sdk_phone_arm64 with a few modifications. Ideally, let’s be on a Linux host when building the system image—the build is relatively untested on M1 systems, and at least, we need to create a separate case sensitive partition for the AOSP repo. Assuming you’re on Linux:

Источник

Android emulator apple silicon preview

Android Emulator M1 Preview

Note: There is an official repo now which is preferred: (https://github.com/google/android-emulator-m1-preview). We will still watch this repo for issues and comments, but please redirect your activity to the official repo.

Webview doesn’t work
No device skins
Video codecs not working
32 bit ARM apps won’t work
Graphical glitches in some Vulkan apps
Popup on startup about not being able to find the ADB path (ADB will still notice the emulator if you have it installed though)
When building, it may be faster to start then cancel the Python triggered build and then reissue ninja -C objs install/strip versus letting the Python triggered build finish.

This only works on M1 Apple Silicon Macs. M1 (or equivalently capable) SoCs are required; note that this does not work on DTKs as they do not support ARM64 on ARM64 hardwre virtualization via Hypevisor.framework.

If you’ve installed Android Studio and Android SDK and adb is available, the emulator should be visible from Studio and work (deploy built apps, debug apps, etc).

How to configure

Edit /Applications/Android\ Emulator.app/Contents/MacOS/aosp-master-arm64-v8a/config.ini . Some notable options:

disk.dataPartition.size : size of userdata. When reconfiguring, you’ll also need to delete all userdata*.img files in that directory.
fastboot.forceColdBoot , fastboot.forceFastBoot : whether to enable snapshots. Current default is snapshots disabled. Set fastboot.forceColdBoot=no , fastboot.forceFastBoot=yes to enable snapshots.
hw.lcd.density : Virtual display DPI.
hw.lcd.width , hw.lcd.height : Virtual display dimensions.
hw.ramSize : RAM limit for the guest. (2GB minimum)

How to wipe data

Remove all userdata*.img files in /Applications/Android\ Emulator.app/Contents/MacOS/aosp-master-arm64-v8a/ .

How to build your own emulator

Building the engine

The emulator source code lives (here), but there are a bunch of other dependencies to download, so we use repo .

To build, first make sure you have Xcode and Xcode command line tools installed, and that you have Chromium depot_tools in your PATH (link). Then:

Note that canceling the python based build after it gets going and issuing just ninja -C objs install/strip may be faster.

Building the system image

We first need to make an edit to remove all 32 bit support. Patch this change: link to build/make/target/board/emulator_arm64/BoardConfig.mk . Then:

After that’s done, we can use this script to package up the system image for use in /Applications/Android\ Emulator.app/Contents/MacOS/aosp-master-arm64-v8a/ . Assuming you’re still in the Android build environment:

Then, $ZIPPED_NAME.zip can be sent over to the M1 and the contents of its files/ can be coped over into /Applications/Android\ Emulator.app/Contents/MacOS/aosp-master-arm64-v8a/ .

About

A place to store preview versions of Android Emulator on Apple Silicon and provide instructions/support.

Источник

Apple Silicon M1: взгляд разработчика

Обсуждение нового чипа Apple Silicon M1 повсюду. Я купил MacBook Air 16 ГБ M1, чтобы понять, насколько он жизнеспособен в качестве основной машины для разработки — вот предварительный отчет после недели тестирования.

Xcode на Apple Silicon M1

Xcode на M1 работает БЫСТРО. Компиляция PSPDFKit PDF SDK (debug, arm64) может конкурировать с самыми быстрыми MacBook Pro на базе Intel, которые предлагает Apple на сегодняшний день — 8:49 мин против 7:31 мин. Для сравнения, мой Hackintosh билдит то же самое менее чем за 5 минут.

Трудно переоценить, насколько это впечатляет для машины без кулера. Последним экспериментом Apple с MacBook без него была 12-дюймовая версия 2017 года, в которой тот же проект собирался 41 минуту.

My M1 MacBook Pro arrived today. Chances are you have various questions, but I think a whole lot is summed up in this 50-second video. (Alt text, because Twitter still doesn’t make this easy: Xcode 12.3 beta unzips in 5 minutes on an M1, vs 13 minutes 22 seconds on an Intel i9) pic.twitter.com/STiivUXXnH

Наши тесты в основном прошли нормально, хотя я обнаружил ошибку, специфичную для arm64, которую мы пропустили раньше, так как мы не запускаем наши тесты на реальном оборудовании в ходе CI. Перенос симулятора на ту же архитектуру, что и у продающихся устройств, будет полезным и поможет найти больше ошибок.

Тестировать iOS ниже 14 проблематично. Похоже, WebKit дает сбой в распределении памяти, выдавая EXC_BAD_INSTRUCTION (code = EXC_I386_INVOP, subcode = 0x0) (FB8920323). Производительность также кажется очень плохой: Xcode периодически зависает, и вся система становится настолько медленной, что курсор мыши дергается. Некоторые симуляторы создают проблемы даже с iOS 14, например iPad Air (4-го поколения), который все еще эмулирует Intel, поэтому постарайтесь избегать этого.

Мы были очень взволнованы переносом нашего CI на Mac Mini с чипом M1 и ожидаем, что MacStadium получит эти устройства, однако, похоже, нам придется ограничить тесты только iOS 14, чтобы это работало. В соответствии с нашим текущим графиком мы планируем отказаться от iOS 12 в третьем квартале 2021 года и от iOS 13 в третьем квартале 2022 года, так что пройдет некоторое время, пока мы сможем полностью перейти на Apple Silicon.

Есть шанс, что Apple исправит эти проблемы, однако на это не стоит рассчитывать — учитывая, что это затрагивает только старые версии iOS, проблема в какой-то момент просто «исчезнет».

Сейчас мы работаем над сбоями в WebKit отслеживая трансляцию Rosetta2 во время выполнения и просто пропуская тесты, в которых используется WebKit. Это не очень хорошо, но, к счастью, мы не часто используем WebKit в нашем текущем проекте. Производительность кажется приемлемой, если вы ограничиваете параллельное тестирование не более чем двумя инстансами — в противном случае системе просто не хватает оперативной памяти, и свап происходит очень медленно.

Docker

Мы используем Docker для автоматизации нашего веб-сайта и загрузочных сред для наших веб и серверных PDF SDK. Docker опубликовал в блоге сообщение о текущем состоянии дел, признав, что в настоящее время система не работает, но они пытаются исправить это. Есть хитрые способы использовать Гипервизор Apple для запуска контейнера Docker вручную, однако для этого нужны контейнеры на основе ARM.

Я ожидаю решения в первом квартале 2021 года, в котором будут работать контейнеры на базе ARM. Нам нужно будет немного поработать, чтобы добавить поддержку arm (что-то уже есть в дорожной карте), так что это только проблема перехода.

Виртуализация и Windows

Чтобы тестировать наш Windows PDF SDK, большинство наших разработчиков использует виртуальную машину VMware с Windows 10 и Visual Studio. В настоящее время ни одно из решений виртуализации Mac не поддерживает Apple Silicon, однако и VMware, и Parallels работают над этим. Я не ожидаю, что Virtualbox будет обновлен в ближайшее время.

Я ожидаю, что в конечном итоге мы сможем запускать Windows с набором коммерческих инструментов на базе ARM. Уже существуют различные proof-of-concepts, и производительность кажется многообещающей. Microsoft в настоящее время не продает Windows на базе ARM, поэтому будет интересно получить лицензию.

ARM-Windows может эмулировать приложения x86, а Microsoft работает над эмуляцией x64, которая уже внедряется в сборках Insider. Через несколько месяцев появится возможность разработать и протестировать наш Windows SDK с Visual Studio на M1 с приемлемой производительностью.

Запуск более старых версий macOS может быть более проблематичным. В настоящее время мы поддерживаем macOS 10.14 с нашим AppKit PDF SDK и macOS 10.15 с Catalyst PDF SDK, обе версии ОС требуют тестирования. Еще неизвестно, включат ли VMWare или Parallels полный уровень эмуляции x64. Скорее всего, это будет очень медленно, поэтому я бы не стал на это рассчитывать.

Кроме того, 16 ГБ ОЗУ — это мало. При запуске параллельных тестов машина начинает сильно свапить, и производительность действительно падает. Это будет еще более проблематично при запущенных виртуальных машинах. В будущем у Mac-ов будет вариант с 32 ГБ, что поможет решить эту проблему.

Android Studio на Apple Silicon M1

IntelliJ работает над портированием JetBrains Runtime на Apple Silicon. В настоящее время приложения работают через Rosetta 2, однако сборка через Gradle происходит очень медленно. Gradle создает код в рантайме, что кажется особенно плохим сочетанием с логикой опережающей трансляции Rosetta 2.

Я ожидаю, что большинство проблем будет решено к первому кварталу 2021 года, однако, вероятно, пройдет еще больше времени, пока все версии Java не заработают на ARM. Много усилий было вложено в развертывание циклов и векторизацию, и пока еще не все доступно на ARM.

Homebrew

Homebrew в настоящее время работает через Rosetta 2. Просто добавьте перед всем префикс arch -x86_64, и все будет работать. Можно установить дополнительную (основанную на arm) версию Homebrew в /opt/homebrew и смешать установки, поскольку все больше и больше программного обеспечения добавляет поддержку ARM.

В настоящее время это не проблема (производительность хорошая), и со временем это будет просто работать нативно.

Приложения

Большинство приложений просто работают, Rosetta еле заметна. Более крупные приложения в начале заметно снижают производительность (например, Microsoft Word нужно около 20 секунд на трансляцию), но затем двоичные файлы кэшируются и последующие запуски выполняются быстро.

Иногда бывает, что приложение не может быть транслировано и падает при запуске (например, Beamer или клиент Google Drive), но это случается редко. Некоторые приложения не понимают своего места на диске и просят переместить их в каталог Applications, хотя на самом деле это просто переведенный двоичный файл, который выполняется где-то еще. Большинство этих запросов можно игнорировать. Некоторые приложения (например, Visual Studio Code) блокируют автоматическое обновление, поскольку местоположение транслируемого приложения доступно только для чтения. Однако в случае VS Code сборка Insider уже обновлена для ARM и нормально работает.

Приложения на основе Electron работают медленно, если работают на Rosetta. Похоже, что оптимизированный компилятор JavaScript V8 блокирует ahead-of-time трансляцию. Последняя стабильная версия Electron (версия 11) уже полностью поддерживает Apple Silicon, и такие компании, как Slack, уже обновили свои бета-версии для работы в нативном режиме.

Google только что выпустил Chrome, который работает на ARM, однако между ним и Apple Safari, который просто летает на Apple Silicon, все еще существует значительный разрыв в производительности.

Вывод

Новые MacBook M1 быстрые, красивые, тихие, и хайп полностью оправдан. В области программного обеспечения еще многое предстоит сделать, чтобы наверстать упущенное, и ошибки, связанные с более старыми симуляторами iOS, доставляют больше всего проблем.

Все это можно исправить в самом ПО, и вся отрасль в настоящее время работает над улучшением этого опыта, поэтому к следующему году, когда Apple обновит 16-дюймовый MacBook Pro и выпустит следующее поколение своей линейки чипов M, можно будет использовать Mac M в качестве основной машины разработчика.

В настоящее время Apple Silicon M1 будет моим вторым ноутбуком в путешествиях, и я продолжу работать с 16-дюймовым MacBook Pro с частотой 2.4 ГГц и 32 ГБ оперативной памяти, который сейчас является более быстрой машиной. Мне будет намного труднее принять шум постоянно работающих кулеров теперь, когда я знаю, какая тишина скоро станет возможной.

Источник