How to create Android emulators in M1 Mac. Using Android Studio Emulators in M1 Mac: Previously, when M1 Macbooks were released, Android studio didn’t have any support for emulators. Google has released a different preview build for emulators. You can check this build here. This is the first preview. This only works on M1 Apple Silicon Macs. It has a lot of rough edges. To use, open the.dmg, drag/drop to /Applications, then right click in /Applications and select Open; skip the developer identity verification check. The first launch may take a while. Files: android-emulator-m1-preview.dmg: Download this file.
M1 Macbook Android Studio Emulator
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.
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.
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.
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.
🕑 Updated on: September 4, 2021
Note: Most of this article was updated in August 2021. The Macbook Pro M1 I was using crashed and stopped working without any reason on August 25, 2021. In just seven months of use.
It took time to get it repaired. That forced me to buy another laptop. While setting up the new laptop, I thought it is an excellent time to update this post.
lol @apple started shipping used/damaged products to India by boxing them as NEW?
cc: @AppleSupportpic.twitter.com/hmgZwiS5Kl
I recently upgraded from Macbook Air 2017 to Macbook Pro with an M1 chip. My four-year-old Macbook Air was giving up. The performance to run heavy tasks like using the iOS simulator when developing and working on React Native apps was declining. I had long given up using the Android emulator and used an actual Android device for testing. December 2020 was the time I decided its time to upgrade.
I had a long internal discussion with myself for almost a month about whether I should upgrade to M1 or stick with Intel-based chips and spend them bucks. Don't get me wrong here, M1 is not cheap either as I did go for a RAM upgrade to max limits, which is currently 16GB in the base model.
After going through some online reviews and research, the kind of performance I was expecting has been worth it so far (it is fast, no doubt). I received it two weeks back when writing this post, and since then, I have installed all the necessary tools and utilities that help me work on Web development and React Native apps.
My local environment currently includes:
- Homebrew (now supported Apple Silicon machines since
2.6.0) - Git
- Node.js
- npm
- Zsh
- Oh My Zsh
- iTerm
- Xcode
- yarn
- VSCode
- Rosetta 2
OS apps:
- Brave
- Android Studio
- Insomnia as REST API client
- Xcode
- Slack or Discord (for work and community)
- There (to track team mate's timezone)
- LICEcap (for gifs)
- Zoom (for work)
- GitHub Desktop App
- Cleanshot (for screenshots)
- Google Chrome
- set to default
- First things to do:
- Log in to: Gmail, Twitter, GitHub, Outlook
- Developer mode on
- Extensions:
- Grammarly
- Toby to organize tabs
- First things to do:
- set to default
System Settings:
Android On M1 Mac
- Disable Ask Siri
- Disable Spotlight search except Applications, Calculator, Definition, and System Preferences.
- Trackpad:
- Fix direction: Scroll & Zoom > Natural off
- Right click: Point & Click > Secondary Click
- Disable dictionary lookup: Point & Click > Look up & data detectors off
- More gestures > Swipe between pages off & App Exposé off
- Finder settings:
- Preferences > Advanced > Show filename extensions
- Enable show path bar: View > Show Path Bar
- Dock:
- Turn auto hiding on
Copy dotfiles.
iTerm
My favorite terminal app that I have been using for years is iTerm. I am currently using two versions of iTerm on my setup. One with Rosetta 2 enabled and the default one. This way, I can only use the Rosetta 2 emulator when required. There are no performance issues I have found with using iTerm with Rosetta 2 for ARM-based applications.
If you'd like a similar setup, go to the Applications folder in your Macbook and duplicate the iTerm application.
You can rename the duplicated iTerm app. I have renamed it to iTerm_rosetta to differentiate between the two. Right-click the duplicated app and click Get Info. In the General, check the box where it says Open using Rosetta.
Now, if you open the second terminal, it will be using Rosetta 2 emulator by default.
Other iTerm profile settings that I use:
Recently I started using Jetbrains Mono font.
For the overall looks and appearance, I use Dracula Pro Color Presets created by Zen Rocha.
And my last favorite thing is to split the working directory into two more different tabs using Command + D for horizontal panes.
Make sure to have the following setting configured from
General > Working Directory > select Advanced Configuration > click button Edit... > select Reuse previous session's directory under Working Directory for New Split Panes.
For terminal prompt, I use Spaceship ZSH.
Xcode
After installing Git, for me, the next step is to install Xcode app from Apple's App Store.
Then, install 'command line tools'. It is required by many of the formulae in Homebrew.
After installing it, make sure to open it for the first time, from the menu bar, open Xcode > Preferences > Locations and make sure that Command Line Tools point towards the current Xcode app.
Homebrew
On December 1, 2020, the Homebrew team announced on their website about the version release 2.6.0. The most significant changes among others they listed were the support for macOS Big Sur, using brew commands instead of brew cask and beginning to support macOS M1 and Apple Silicon or ARM-based chips.
Using the terminal, you can install the Homebrew by executing the default command:
brew installs:
- node/npm
- scrcpy (control Android devices connect via USB on mac)
- adoptopenjdk8 (required for React Native)
- Karabiner-Elements (remapping function keys)
- watchman (required for React Native)
What is Karabiner-Elements?
When I bought Macbook Air M1, it had function keys (that got me excited), but I don't understand why Apple decided to replace function keys that would allow me to control Keyboard Brightness?! And moreover, replace it with 'Do Not Disturb'.
Why? That got me confused 🤷
I found this tool called karabiner Elements that can be installed as a brew formula:
Here are the key mappings I am using now:
Git
I did install Git using brew command:
To authenticate GitHub to be used from the terminal environment, I'd recommend you to check out the official document on creating and accessing personal tokens.
🔥 Tip: As of Git version 2.28 there is a new config option to set the default branch to main. Set it globally and forget about it.
ZSH and Oh My Zsh
ZSH is the default shell in macOS Big Sur. However, I like to use Oh My Zsh to manage the ZSH configuration, plugins, and a theme to prettify the terminal.
To install, run the command below:
After installation, make sure that the file .zshrc is exporting the below path at the top:
M1 Macbook Android Emulator Download
The first I like to do after setting up the bare minimum ZSH configuration is to install a plugin called zsh-syntax-highlighting. It provides syntax highlighting for the ZSH shell. Execute the series below commands in the terminal window:
This is my final ZSH configuration in the file ~/.zshrc file:
After installing the syntax highlight plugin, it starts to recognize the commands:
VSCode
VSCode and VS Code Insiders are currently supported on ARM chips (as of March 13, 2021). Download the installer for Insiders edition from here and for VSCode here.
I am still using the same VSCode configuration from my previous setup:
Themes
I usually like to switch between a dark and a light theme.
- For the dark theme where I spent most of my time, I am was previously using morgan.codes-theme, but now I am using fairyFloss.
- Other themes I switch between:
- Quiet Light
- Other themes I switch between:
- For file icons, I love Material-Icon-Theme.
- For terminal prompt, I use Spaceship ZSH.
- Font: Jetbrains Mono font.
Extensions
I use VSCode editor for both writing code and writing blog posts. Thus, the list of extensions below is the combination of extensions that fulfills both of my purposes.
Global NPM Packages I use
- gatsby-cli To build and test out my personal blog built with Gatsby.
- npm-check to check for outdated, incorrect, and unused dependencies.
- git-watch-log to watch a git repo and recent changes.
For React Native Development
- install node
- install Watchman to watch changes in the filesystem using the command:
brew install watchman. - install following gems:
- install Java Development Kit using the command:
brew install --cask adoptopenjdk/openjdk/adoptopenjdk8. - Currently, I am using Arctic Fox Canary that supports Apple's based machines for Android Studio.
- Then install Android SDK (I do not prefer AVD and use an actual device for testing)
- scrcpy to display and control Android devices connect via USB on Mac.
⚛️ For more instructions on how to set up a development environment for React Native, please follow the official documentation here.
Rosetta 2
Update: I am not using the Rosetta environment to install anything on the secondary machine since August 2021. That is the reason I've mentioned it at the end of the post.
Rosetta 2 is the lifeline that allows you to run apps designed for Intel-based chips that use x86 architecture on ARM-based chips (in this case M1). This solution is provided by Apple in the form of an emulator and doesn't come pre-installed. You have to install it manually. Fire up the Terminal application that comes pre-installed on the Big Sur and let your first command to execute be:
If you decide not to put the flag --agree-to-license, you will be prompted by Apple's interactive install, and you will have to agree to their terms and license conditions to use it.
Conclusion
That’s the setup I now use for my JavaScript, Node.js, React and React Native. I think it's a good machine. Hopefully, M1 is just the beginning of a new era of powerful computers for daily work use 🤞
🤔 The only thing left for me is to find a way to transfer all laptop swag/stickers from my Macbook Air 2017 to Pro. I miss having them on this one.
isapplesiliconready.com is another helpful link I found to check what is compatible to work on Apple Silicon chips natively or using Rosetta or not optimized at all.