Apple Silicon performance and support videos for Android Studio, Twitter. Apr 22, 2021 The M1 is the first appearance of the new paradigm that Apple has dubbed Apple Silicon. The new Macs available with the M1 include the MacBook Air, the 13-inch MacBook Pro, the Mac mini, and the. After pressing the launch button you will get your Android application running in your ARM virtual emulator:-) Conclusion. In this post, we have seen that is possible to install Android Studio in Macbook Air M1 and use a virtual device even that your M1 doesn’t support VT-x. You can learn more about this emulator in the following references. Why do people even use apple hardware anymore? The M1 chip is really good, but the rest of the system for every system that has it is garbage considering the price, they literally charge you $200 for an extra 8gb of ram and 800 fucking dollars for a 2TB SSD.
-->This article explains how to use the Android Device Manager to createand configure Android Virtual Devices (AVDs) that emulate physical Androiddevices. You can use these virtual devices to run and test your appwithout having to rely on a physical device.
After you have verified that hardware acceleration is enabled (asdescribed inHardware Acceleration for Emulator Performance),the next step is to use the Android Device Manager (also referred toas the Xamarin Android Device Manager) to create virtual devices thatyou can use to test and debug your app.
Android Device Manager on Windows
This article explains how to use the Android Device Manager to create,duplicate, customize, and launch Android virtual devices.
You use the Android Device Manager to create and configure AndroidVirtual Devices (AVDs) that run in theAndroid Emulator.Each AVD is an emulator configuration that simulates a physical Androiddevice. This makes it possible to run and test your app in a variety ofconfigurations that simulate different physical Android devices.
Requirements
To use the Android Device Manager, you will need the following items:
Visual Studio 2019 Community, Professional, or Enterprise.
OR Visual Studio 2017 version 15.8 or later is required. Visual StudioCommunity, Professional, and Enterprise editions are supported.
Visual Studio Tools for Xamarin version 4.9 or later.
The Android SDK must be installed (seeSetting up the Android SDK for Xamarin.Android).Be sure to install the Android SDK at its default location if itis not already installed: C:Program Files (x86)Androidandroid-sdk.
The following packages must be installed (via theAndroid SDK Manager):
- Android SDK Tools version 26.1.1 or later
- Android SDK Platform-Tools 27.0.1 or later
- Android SDK Build-Tools 27.0.3 or later
- Android Emulator 27.2.7 or later.
These packages should be displayed with Installed status as seen inthe following screenshot:
Launching the Device Manager
Launch the Android Device Manager from the Tools menu byclicking Tools > Android > Android Device Manager:
If the following error dialog is presented on launch, see theTroubleshooting section for workaroundinstructions:
Main Screen
When you first launch the Android Device Manager, it presents a screenthat displays all currently-configured virtual devices. For eachvirtual device, the Name, OS (Android Version), Processor,Memory size, and screen Resolution are displayed:
When you select a device in the list, the Start button appears onthe right. You can click the Start button to launch the emulatorwith this virtual device:
After the emulator starts with the selected virtual device, theStart button changes to a Stop button that you can use to haltthe emulator:
New Device
To create a new device, click the New button (located in the upperright-hand area of the screen):
Clicking New launches the New Device screen:
To configure a new device in the New Device screen, use thefollowing steps:
Give the device a new name. In the following example, the new deviceis named Pixel_API_27:
Select a physical device to emulate by clicking the Base Devicepull-down menu:
Select a processor type for this virtual device by clicking theProcessor pull-down menu. Selecting x86 will provide thebest performance because it enables the emulator to take advantageof hardware acceleration.The x86_64 option will also make use of hardware acceleration,but it runs slightly slower than x86 (x86_64 is normallyused for testing 64-bit apps):
Select the Android version (API level) by clicking the OSpull-down menu. For example, select Oreo 8.1 - API 27 to createa virtual device for API level 27:
If you select an Android API level that has not yet been installed, theDevice Manager will display A new device will be downloadedmessage at the bottom of the screen – it will download andinstall the necessary files as it creates the new virtual device:
If you want to include Google Play Services APIs in your virtualdevice, enable the Google APIs option. To include the GooglePlay Store app, enable the Google Play Store option:
Note that Google Play Store images are available only for some basedevice types such as Pixel, Pixel 2, Nexus 5, and Nexus 5X.
Edit any properties that you need to modify. To make changes toproperties, seeEditing Android Virtual Device Properties.
Add any additional properties that you need to explicitly set. TheNew Device screen lists only the most commonly-modifiedproperties, but you can click the Add Property pull-down menu(at the bottom) to add additional properties:
You can also define a custom property by selecting Custom... atthe top of the property list.
Click the Create button (lower right-hand corner) to create thenew device:
You might get a License Acceptance screen. Click Accept ifyou agree to the license terms:
The Android Device Manager adds the new device to the list ofinstalled virtual devices while displaying a Creating progressindicator during device creation:
When the creation process is complete, the new device is shown inthe list of installed virtual devices with a Start button,ready to launch:
Edit Device
To edit an existing virtual device, select the device and click theEdit button (located in the upper right-hand corner of the screen):
Clicking Edit launches the Device Editor for the selected virtual device:
The Device Editor screen lists the properties of the virtual deviceunder the Property column, with the corresponding values of each property inthe Value column. When you select a property, a detailed descriptionof that property is displayed on the right.
To change a property, edit its value in the Value column.For example, in the following screenshot the hw.lcd.density propertyis being changed from 480 to 240:
After you have made the necessary configuration changes, click the Save button.For more information about changing virtual device properties, seeEditing Android Virtual Device Properties.
Additional Options
Additional options for working with devices are available from theAdditional Options (…) pull-down menu in the upperright-hand corner:
The additional options menu contains the following items:
Duplicate and Edit – Duplicates the currently-selecteddevice and opens it in the New Device screen with a differentunique name. For example, selecting Pixel_API_27 and clickingDuplicate and Edit appends a counter to the name:
Reveal in Explorer – Opens a Windows Explorer window in thefolder that holds the files for the virtual device. For example,selecting Pixel_API_27 and clicking Reveal in Explorer opensa window like the following example:
Factory Reset – Resets the selected device to its defaultsettings, erasing any user changes made to the internal state of thedevice while it was running (this also erases the currentQuick Bootsnapshot, if any). This change does not alter modifications that youmake to the virtual device during creation and editing. A dialog boxwill appear with the reminder that this reset cannot be undone. ClickFactory Reset to confirm the reset:
Delete – Permanently deletes the selected virtual device. Adialog box will appear with the reminder that deleting a devicecannot be undone. Click Delete if you are certain that you wantto delete the device.
Note
If you are using a Mac with an Apple chip, such as the M1, you will need to install the Android Emulator for M1 preview from GitHub.
Android Device Manager on macOS
This article explains how to use the Android Device Manager to create,duplicate, customize, and launch Android virtual devices.
You use the Android Device Manager to create and configure AndroidVirtual Devices (AVDs) that run in theAndroid Emulator.Each AVD is an emulator configuration that simulates a physical Androiddevice. This makes it possible to run and test your app in a variety ofconfigurations that simulate different physical Android devices.
Requirements
To use the Android Device Manager, you will need the following items:
Visual Studio for Mac 7.6 or later.
The Android SDK must be installed (seeSetting up the Android SDK for Xamarin.Android).
The following packages must be installed (via theAndroid SDK Manager):
- SDK tools version 26.1.1 or later
- Android SDK Platform-Tools 28.0.1 or later
- Android SDK Build-Tools 26.0.3 or later
These packages should be displayed with Installed status as seen inthe following screenshot:
Launching the Device Manager
Launch the Android Device Manager by clicking Tools > Device Manager:
If the following error dialog is presented on launch, see theTroubleshooting section for workaroundinstructions:
Main Screen
When you first launch the Android Device Manager, it presents a screenthat displays all currently-configured virtual devices. For eachvirtual device, the Name, OS (Android Version), Processor,Memory size, and screen Resolution are displayed:
When you select a device in the list, the Play button appears onthe right. You can click the Play button to launch the emulatorwith this virtual device:
After the emulator starts with the selected virtual device, thePlay button changes to a Stop button that you can use to haltthe emulator:
When you stop the emulator, you may get a prompt asking if you want to savethe current state for the next quick boot:
Saving the current state will make the emulator boot faster when this virtualdevice is launched again. For more information about Quick Boot, seeQuick Boot.
New Device
To create a new device, click the New Device button (located in the upperleft-hand area of the screen):
Clicking New Device launches the New Device screen:
Use the following steps to configure a new device in the New Devicescreen:
Give the device a new name. In the following example, the new deviceis named Pixel_API_27:
Select a physical device to emulate by clicking the Base Devicepull-down menu:
Select a processor type for this virtual device by clicking theProcessor pull-down menu. Selecting x86 will provide thebest performance because it enables the emulator to take advantageof hardware acceleration.The x86_64 option will also make use of hardware acceleration,but it runs slightly slower than x86 (x86_64 is normallyused for testing 64-bit apps):
Select the Android version (API level) by clicking the OSpull-down menu. For example, select Oreo 8.1 - API 27 to createa virtual device for API level 27:
If you select an Android API level that has not yet been installed,the Device Manager will display A new device will be downloadedmessage at the bottom of the screen – it will download andinstall the necessary files as it creates the new virtual device:
If you want to include Google Play Services APIs in your virtualdevice, enable the Google APIs option. To include the GooglePlay Store app, enable the Google Play Store option:
Note that Google Play Store images are available only for some basedevice types such as Pixel, Pixel 2, Nexus 5, and Nexus 5X.
Edit any properties that you need to modify. To make changes toproperties, seeEditing Android Virtual Device Properties.
Add any additional properties that you need to explicitly set. TheNew Device screen lists only the most commonly-modifiedproperties, but you can click the Add Property pull-down menu(at the bottom) to add additional properties:
You can also define a custom property by clicking Custom...at the top of this property list.
Click the Create button (lower right-hand corner) to create thenew device:
The Android Device Manager adds the new device to the list ofinstalled virtual devices while displaying a Creating progressindicator during device creation:
When the creation process is complete, the new device is shown inthe list of installed virtual devices with a Start button,ready to launch:
Edit Device
To edit an existing virtual device, select the Additional Optionspull-down menu (gear icon) and select Edit:
Clicking Edit launches the Device Editor for the selected virtual device:
The Device Editor screen lists the properties of the virtual deviceunder the Property column, with the corresponding values of each property inthe Value column. When you select a property, a detailed descriptionof that property is displayed on the right.
To change a property, edit its value in the Value column.For example, in the following screenshot the hw.lcd.density propertyis being changed from 480 to 240:
After you have made the necessary configuration changes, click the Save button.For more information about changing virtual device properties, seeEditing Android Virtual Device Properties.
Additional Options
Additional options for working with a device are available from thepull-down menu located to the left of the Play button:
The additional options menu contains the following items:
Edit – Opens the currently-selected device in the deviceeditor as described earlier.
Duplicate and Edit – Duplicates the currently-selecteddevice and opens it in the New Device screen with a differentunique name. For example, selecting Pixel 2 API 28 and clickingDuplicate and Edit appends a counter to the name:
Reveal in Finder – Opens a macOS Finder window in thefolder that holds the files for the virtual device. For example,selecting Pixel 2 API 28 and clicking Reveal in Finder opensa window like the following example:
Factory Reset – Resets the selected device to its defaultsettings, erasing any user changes made to the internal state of thedevice while it was running (this also erases the currentQuick Bootsnapshot, if any). This change does not alter modifications that youmake to the virtual device during creation and editing. A dialog boxwill appear with the reminder that this reset cannot be undone. ClickFactory Reset to confirm the reset.
Delete – Permanently deletes the selected virtual device. Adialog box will appear with the reminder that deleting a devicecannot be undone. Click Delete if you are certain that you wantto delete the device.
Troubleshooting
The following sections explain how to diagnose and work around problemsthat may occur when using the Android Device Manager to configurevirtual devices.
Android SDK in Non-Standard Location
Typically, the Android SDK is installed at the following location:
C:Program Files (x86)Androidandroid-sdk
If the SDK is not installed at this location, you may get this error when you launchthe Android Device Manager:
To work around this problem, use the following steps:
From the Windows desktop, navigate toC:UsersusernameAppDataRoamingXamarinDeviceManager:
Double-click to open one of the log files and locate the Configfile path. For example:
Navigate to this location and double-click user.config to open it.
In user.config, locate the
<UserSettings>element and add anAndroidSdkPath attribute to it. Set this attribute to the pathwhere the Android SDK is installed on your computer and save thefile. For example,<UserSettings>would look like the following ifthe Android SDK was installed at C:ProgramsAndroidSDK:
After making this change to user.config, you should be able tolaunch the Android Device Manager.
Wrong Version of Android SDK Tools
If Android SDK tools 26.1.1 or later is not installed, you may see thiserror dialog on launch:
If you see this error dialog, click Open SDK Manager to open theAndroid SDK Manager. In the Android SDK Manager, click the Toolstab and install the following packages:
- Android SDK Tools 26.1.1 or later
- Android SDK Platform-Tools 27.0.1 or later
- Android SDK Build-Tools 27.0.3 or later
Snapshot disables WiFi on Android Oreo
If you have an AVD configured for Android Oreo with simulated Wi-Fi access,restarting the AVD after a snapshot may cause Wi-Fi access to become disabled.
To work around this problem,
Select the AVD in the Android Device Manager.
From the additional options menu, click Reveal in Explorer.
Navigate to snapshots > default_boot.
Delete the snapshot.pb file:
Restart the AVD.
After these changes are made, the AVD will restart in a state thatallows Wi-Fi to work again.
Wrong Version of Android SDK Tools
If Android SDK tools 26.1.1 or later is not installed, you may see thiserror dialog on launch:
If you see this error dialog, click OK to open the Android SDKManager. In the Android SDK Manager, click the Tools tab andinstall the following packages:
- Android SDK Tools 26.1.1 or later
- Android SDK Platform-Tools 28.0.1 or later
- Android SDK Build-Tools 26.0.3 or later
Snapshot disables WiFi on Android Oreo
If you have an AVD configured for Android Oreo with simulated Wi-Fi access,restarting the AVD after a snapshot may cause Wi-Fi access to become disabled.
To work around this problem,
Select the AVD in the Android Device Manager.
From the additional options menu, click Reveal in Finder.
Navigate to snapshots > default_boot.
Delete the snapshot.pb file:
Restart the AVD.
After these changes are made, the AVD will restart in a state thatallows Wi-Fi to work again.
Generating a Bug Report
If you find a problem with the Android Device Manager thatcannot be resolved using the above troubleshooting tips, please file abug report by right-clicking the title bar and selecting Generate BugReport:
If you find a problem with the Android Device Manager thatcannot be resolved using the above troubleshooting tips, please file abug report by clicking Help > Report a Problem:
Summary
This guide introduced the Android Device Manager available in VisualStudio Tools for Xamarin and Visual Studio for Mac. It explainedessential features such as starting and stopping the Android emulator,selecting an Android virtual device (AVD) to run, creating new virtualdevices, and how to edit a virtual device. It explained how toedit profile hardware properties for further customization, and itprovided troubleshooting tips for common problems.
Related Links
Related Video
Find more Xamarin videos on Channel 9 and YouTube.
From the announcement made on November 10th, 2020, users have had high hopes for the new Apple M1 devices. With its powerful Apple Silicon processor smashing benchmarks all over the place, users and developers were both asking if a native Dolphin build would be possible. Now we have the answer.
Apple's M1 hardware is incredibly powerful and excels at running Dolphin. This announcement has been in the works for some time, eagle eyed users may have noticed that earlier this month macOS builds were now being designated as 'Intel'. That's because delroth and Skyler had set up a new buildbot using a service called MacStadium for creating Universal macOS binaries. These builds are available immediately and natively support both macOS M1 and Intel macOS devices.
Tackling macOS on ARM¶
It is an understatement to say that Apple dropped a bomb on the PC industry with the M1 ARM processor. ARM is a Reduced Instruction Set Computing (RISC) architecture that was specifically designed for efficiency with portable devices. With a tight instruction set instead of the ever ballooning mess that is x86, ARM was able to get away with literally less processor while performing optimized tasks, giving it exceptional power efficiency. However given unoptimized workloads, an ARM processor would need many more cycles to perform it than an x86 CPU. All combined, ARM was the processor of choice for battery life in portable devices, but when pushed they had poor overall performance compared to Intel's x86 processors. It was a processor for casual things like phones, and not really meant for 'real work'. But that is the past.
Intel's iron grip of process superiority has long slipped, and the ARM instruction set has carefully expanded to more efficiently handle more tasks while not sacrificing power efficiency. Yet even with ARM reaching datacenters and even some interesting hardware giving us a glimpse at what could be, ARM's reputation as being weaker than x86 has remained firmly entrenched.
But with M1, Apple has completely shattered this foolish notion. Not only can the M1 perform the same tasks as their former Intel processors, they can do it faster even when using their Rosetta 2 translation layer! All of this while still providing considerably better single threaded performance compared to Intel. Let's just say they had gotten our attention.
We immediately put it through its paces. Using the Rosetta 2 translation layer with Dolphin's x86-64 JIT, the M1 easily ran most games at full speed and handily outran like-class Intel Macs. The experience wasn't entirely smooth due to jitter from Jitting a JIT, yet the processor proved itself more than capable of handling Dolphin. But the fact it had to do it through a translation layer was a huge performance bottleneck. Developers thought, why not just use Dolphin's AArch64 JIT for native support? And thus, the race was on as several people tried to figure out the hurdles of getting Dolphin's AArch64 JIT to run on the M1.
Unfortunately, getting the AArch64 JIT to work wasn't exactly trivial. Apple requires W^X (Write Xor Execute) conformance for native macOS M1 applications. What it does is make it so that areas of memory must be explicitly marked as for WriteorExecute, but not both! Because it's easier and hasn't been forbidden on any of the prior platforms that Dolphin supports, the emulator previously just marked memory regions used by the JIT as for WriteandExecute. This requirement from Apple is mostly a security feature to prevent bugs in programs that read untrusted data from being exploited to run malware. Outside of emulators, the primary place that you'll actually see self-modifying code is web browsers, which is often a vector for attack on a computer.
This was thankfully a lot less strict than on iOS devices, which strictly forbid mapping memory as executable whatsoever and made iOS untenable for us to officially support. Apple even provides documentation for helping developers port JITs to macOS on ARM. Skyler used a method described in the documentation that would change the mapped memory between Writeable when emitting code to Executable when executing code. Since Dolphin wasn't designed for this, there were a few hiccups along the way, but eventually everything was massaged into working with the new restrictions.
Once that was out of the way, the focus shifted towards maintainability and setting up the infrastructure. Beyond getting it to run correctly, this was by far the hardest challenge to official M1 support. Dolphin's infrastructure is rather complicated and sensitive to changes. Moving macOS builds over to a universal binary (x86-64 and AArch64 all in one) along with getting the hardware necessary to build macOS universal binaries was a challenge and could have proven to be an expensive endeavor. In the end, MacStadium made the move extremely inexpensive by providing us with free access to M1 hardware, so we were able to focus on making Dolphin's buildbot infrastructure handle the new builds.
Android Emulator Apple M1
Putting the M1 Hardware To The Test¶
So now that it runs, you're probably wondering how does it run. There's a few things we need to keep in mind. Dolphin's AArch64 JIT isn't quite as mature as the x86-64 JIT. While things aren't as bad as they were a couple of years ago and compatibility should be roughly the same thanks to efforts from JosJuice, it is still the less complete of the two JITs.
One of the differences is instruction coverage. Any PowerPC instruction that isn't included in the JIT has to fallback to interpreter, which costs a huge performance penalty. Most common instructions are covered by both JITs at this point. There is one important feature missing in the AArch64 Jit, though: memchecks. Thankfully, this only affects Full MMU games such as Star Wars Rogue Squadron II, III, and Spider-Man 2. There are some niceties missing from AArch64 JIT, too, like JitCache space reuse used to prevent spurious JitCache flushes.
AArch64 does have its advantages, though. Namely, the processors have 31 registers, compared to the 16 available in x86-64 processors. The PowerPC processor we are emulating has 32 registers, and while it is rare for all of them to be used within a single code block, more registers is always nice to have. Another difference is that AArch64 and PowerPC have 3 operand instructions while x86-64 only has two.
As you can see, it makes emulating some instructions much cleaner and easier than on our x86-64 JIT. Alright, enough with the boring details. How does the M1 hardware perform when put up against some of the beasts of the GameCube and Wii library? We also included data from two computers featured in Progress Reports previously for comparison.
There's no denying it; macOS M1 hardware kicks some serious ass. It absolutely obliterates a two and a half year old Intel MacBook Pro that was over three times its price all while keeping within ARM's reach of a powerful desktop computer. We were so impressed, we decided to make a second graph to express it.
The efficiency is almost literally off the chart. Compared to an absolute monstrosity of a Desktop PC, it uses less than 1/10th of the energy while providing ~65% of the performance. And the poor Intel MacBook Pro just can't compare.
Taking Things a (Lock)Step Further¶
After doing strenuous performance testing on the macOS M1 and its Apple Silicon, it was clear that it was powerful. The problem is that if you give developers a new toy, they eventually decide to push things further and further. This was the first time we got to see Dolphin's AArch64 JIT really stretch its legs on something other than a phone or tablet with an ultra aggressive governor that's also limited by graphics drivers. What is the absolute worst idea that we could come up with given this new found power? Netplay.
This was the real test to see if the AArch64 JIT and x86-64 JIT truly equals. We couldn't exactly test this before because the Android GUI lacks netplay support, but macOS runs the desktop version with no compromises. That includes having full netplay support. Now, testing this was mostly a joke because there are tons of differences between the JITs. Everything from instruction coverage to known rounding errors. The chances of this working was next to zero. But there was no reason to stop and think if we should - technology had made it so we could.
And it actually worked! We just can't be certain exactly how well yet due to limited testing. Every single game we've tested on netplay so far has managed to synchronize, albeit with Dolphin's desync checker giving a false positive. Testers have tried everything from Super Smash Bros. Melee and Mario Party 5 to things like spectating The Legend of Zelda: The Wind Waker. All of the sessions stayed in sync.
This might not be true for all games. Up until earlier this month, games like Mario Kart: Double Dash!!, F-Zero GX, and Mario Kart Wii would immediately desync due to physics differences. Thanks to the work of JosJuice, those rounding bugs in the AArch64 JIT and interpreter (...we'll get to that in the Progress Report) are now fixed, meaning these games should at least have a chance to sync on netplay.
Because of limited libraries, we don't have a great idea of what games will work and what games are problematic. As a stress test, Techjar and Skyler played the Super Mario Sunshine Co-op Mod. The physics calculations in Super Mario Sunshine are extremely sensitive to CPU rounding bugs and it provided a tough test for both JITs. Oh yeah, they also enabled the 60 FPS hack just to make things even more interesting.
Everyone knowledgeable on Dolphin's JITs thought that cross-JIT netplay would be impossible, at least without tons of dedicated fixes. Yet here we are, able to experience it first hand. And it can only get better from here, as we are now able to monitor and test JIT determinism on netplay. While you might be excited to dive right in, it's important to note that we were only able to test a few games and we have no idea what compatibility will look like when unleashed on the wider library.
Note:Yes, we're aware that Windows and Linux AArch64 devices existed before the M1. There was no allure to testing netplay on those because they could not run Dolphin reasonably. We really didn't expect this to work or we probably would have tried it sooner.
Android Studio Emulator Mac M1
In Conclusion¶
There's little else we can say: The M1 hardware is fantastic and higher tiers are on the way promising even better performance. But what we have is already efficient, powerful, and gives us a mainstream AArch64 device that isn't Android and uses our AArch64 JIT to its fullest potential. The only big downside is the proprietary graphics API present in macOS that prevents us from using the latest versions of OpenGL and forces us to use MoltenVK in order to take advantage of Vulkan. That is a very small price to pay to get a glimpse at some really cool hardware that redefines what an ARM processor can do. There's undeniable excitement for the next generation of AArch64 hardware to see how much further that this can go.
Android Emulator Apple M10
EDITORS NOTE: A small error was noticed in our 9900k performance testing. This has been corrected. However, the differences are very minor and do not affect our conclusion.