Attempting to Emulate Blue Archive on Linux

What’s up guys, David Korenski here back at it with another anime-themed product: Blue Archive - a strategy role-playing mobile game tacked onto a gambling machine. But this time, I’m going to talk about how painful it was to try play it on a Linux desktop. A few months ago, Sumiko kindly helped me set up Linux Mint, which I quite liked and now use as my daily driver. I’ve since gotten rid of my old Windows shindows boot and I don’t want to install gross mobile games on my phone, so when I needed to emulate Android… well, my options were quite limited.

The first step to emulation on Linux is to lay out our options. What comes to mind when you think “Android Emulator”? Probably Bluestacks, Nox, MuMu. Unfortunately for us, all of those are Windows. So we’re going to have to resort to more “developery” alternatives. The options we have then are Genymotion and Google’s official Android Studio emulator. The former requires a license for additional features, so that’s off the table. That leaves us with the Android Studio emulator.

Adventures with Android Studio

Last time I tried Android Studio on Windows, the emulator was painfully slow. However, with a new install on Linux and a brand new Android 12 SDK, it ran suprisingly okay. No noticable stutter or slowdowns. I could even get it to run faster by installing QEMU/KVM. QEMU (Quick Emulator) is a free-and-open source emulator, so you can run a lot of cool OSes on there like Linux, or Windows, or MacOS, or even Android! The latter is what I needed! Meanwhile, KVM (Kernel-based Virtual Machine) is the primary hypervisor for the Linux kernel, allowing QEMU to efficently use host resources. Once installed, Android Studio will use it to load up your virtual devices.

Android 12.0 with x86_64

Alright, let’s see if Android Studio’s emulator will work: Pixel 4 with Google Play on Android 12.0 with x86_64 architecture. Boot up, download Aurora Store so I don’t have to log into Google Play, spoof my device to allow me to install Blue Archive, and voila, the anime game manages to open up its splash screen and download its assets. Until I get to the “touch to start” menu. Once clicked, the game places a “Now Loading” indicator in the bottom right… then crashes to the home screen. Woop.

I figured at the time that it was a graphical issue with OpenGL running at 2.0 instead of 3.0. I couldn’t figure out how to get the “Emulated Performance” setting in the emulator to show 3.0 in the dropdown, so I moved on to check out another SDK.

Android 7.0 & 11 with x86

On the x86 side, I tried out the Nougat x86 SDK, which Nox seems to use. After downloading Blue Archive, it refused to install because it lacked the correct “ABI”. I realized later the game only provides arm64 and arm32 downloads when laziness drove me to just download the game’s APK off ApkPure. The reason it for Android 12 was because Google added a proprietary ARM translation layer in Android 11. I can’t remember why it didn’t work on Android 11, but it didn’t.

Okay, so maybe we should run the arm64 app in an entirely arm64 enviroment.

Android ARM SDKs

Well, none of the ARM-based Android SDKs work. Android S and Sv2 don’t even launch. Allegedly any SDK above API level 28 (Oreo) crash because Google’s removed support for full ARM emulation on x86 hardware. However, even Oreo won’t work. It launches, no window pops up, then eventually times out. The previous major version, Nougat, will work… as in launch, show the Android boot splash, then just never progress past the boot splash.

Why won’t anything just work?!

logcat

After figuring out that I can use ADB’s logcat on the Android 12 emulator, I found that the game’s Crashlytics .so file would ironically crash the entire app, spewing out the error below.

linker  : error: "/data/app/~~zNYiAP1NrSA6e_vW2Yp0ag==/com.nexon.bluearchive-ZWYbKxLlSH57pr5VoFQcBg==/lib/arm64/libcrashlytics-trampoline.so" is for EM_AARCH64 (183) instead of EM_X86_64 (62)

I thought that the translation layer should take care of that file - I guess not. I couldn’t figure out how to fix it, so I gave up on Android Studio.

The Search for Another Emulator

Clearly a clean, relatively performant option like Android Studio was not going to cut it. What other options do we have then? Something more esoteric, unstable, perhaps. Trudging though the hellscape of Reddit, I learned of five new alternatives: Anbox, Waydroid, the Android x86 project, Prime OS and Bliss OS. From some searches, I learned that Waydroid, Android x86, and Bliss OS support both ARM and ARM64 through libhoudini, a legally-questionable library originally ripped off of Intel’s proprietary ARM translation layer, developed during its foray into the mobile space. What matters, though, is if it can get the job done.

Let’s assess each one.

The ones that run on the desktop:

• Anbox: Anbox is allegedly deprecated, so I assume it’s not going to work with such a recent game.
• Waydroid: The successor to Anbox, but on the Wayland desktop enviroment instead of the time-tested X11. Linux Mint’s Cinnamon is still on X11, so if I want to test it, I need to install a whole new OS. That’s rather annoying. A 20-day old post on /r/linux_gaming asked whether NIKKE and Blue Archive works on Waydroid and the only reply reported that it did not work using libhoudini, so that’s another thing to worry about. I’ll save this as a last resort.

The ones that I will either need to install or run in a VM:

• Android x86: A full-on operating system allowing you to run Android directly on your desktop hardware. Provides downloads up to Android 9.0.
• Prime OS: Couldn’t find a source code link on its website and it doesn’t seem to flaunt being open source, so I think it’s safe to assume it’s not. Dealbreaker.
• Bliss OS: An open source operating system seemingly built on top of Android x86. Stable release runs Android 11 with ARM support enabled by default. Pretty good.

The Android x86 Rabbit Hole

Android x86 is a pretty cool project. Despite its name, it does support x86_64. Doesn’t look like there’s much movement in terms of activity though; its FossHub lists its last updated date as March 25, 2020. Date aside, the latest release is “android-x86_64-9.0-r2”, but the Reddit post that recommended I use Android x86 said to use “android-x86_64-8.1-r6” instead. I decided to try the newer release first.

For reference, every test of Android x86 was installed using virt-manager on QEMU/KVM.

Android 9.0

I installed it successfully, but Blue Archive crashed when I tried to launch it. The native bridge option doesn’t seem to work. It doesn’t create the /data/arm directory or show any download notifcation for libhoudini. In addition, the manual “enable_nativebridge” command was broken - spitting out complaints about mounting errors. Checking out the libhoudini files listed on multiple GitHub READMEs, it appears the only libhoudini for 9.0 is 8_y - which converts x86_64 to only armeabi - 32-bit ARM. Since the manual command didn’t work and I don’t want to figure out how to fix it, I moved down a version.

Android 7.0

Nougat is the only release where all the libhoudini libraries actually exist. Native bridge also works this time. When you turn it on in the settings, a notification pops up showing that it’s actually downloading libhoudini. But what doesn’t work this time is Blue Archive. After downloading the APK, the game either crashes immediately, or launches a black screen that Android asks to kill after a short while. Maybe the middle is the right move.

Android 8.1

Turns out the READMEs were also lying here as well, as all the listed 8.1 links to android-x86.org for libhoudini simply 404… except for 8_y.

Oh well, might as well try. I also noticed that it’ll install libhoudini into /sdcard/arm instead of /data/arm for some reason.

Blue Archive actually does launch! And it gets all the way to the press-to-start menu as well! But - just like Android Studio - when you click it, it breaks. The loading text appears, then the app becomes unresponsive and the sparkly sci-fi cursor in the game stops working. No crash this time, but also no indicator to why it’s frozen. On a side note, something fun I noticed is that the background and loading text still keep going despite being frozen because it’s a video played with FFMPEG. That’s pretty cool.

There was also another problem with the game other than not being able to launch: the game was stuck in the bottom left corner. The big modal that pops up on the touch-to-start as well as the splash showing the developer logos scale correctly, but not the rest of the game. Annoyingly, this problem would plague me in my next exploration.

The Bliss OS Expedition

I installed Bliss OS v11.13 (Google apps version) in QEMU/KVM. The installation went smoothly and I downloaded Blue Archive, which launched without a hitch. Again, the incorrectly-sized splash screen video showed up, but that did not deter me. Then the moment of truth arrived when the touch-to-play stared me in the face.

But this time, it actually worked! I was greeted by the account selection screen, a beauty to behold! I signed in as a guest and went all the way through the prologue. I played through the combat mission and all the way to the forced gacha roll, getting Hoshino as my three-star.

The performance of Bliss in a VM left a lot of be desired compared to Android Studio, however. Attempting to run the VM using OpenGL on NVIDIA’s proprietary drivers didn’t work, so I had to use Intel’s integrated graphics. It still seemed stuttery though. Trying to swtich the video mode to use Virtio instead of QXL broke Bliss OS, spitting you out on the GearLock command line instead of booting correctly. Performance is defintely a high priority - I don’t want to play a stuttery mess, but I haven’t explored performance options any further.

Meanwhile, the other big problem is the game scaling. For some reason, despite running Bliss OS at 1920x1080, Blue Archive refuses to scale the game itself to the full resolution. Even messing with the screen density doesn’t do anything. It just stays in the same bottom left corner at what I believe is 1520x720. I don’t know what’s up with that - probably a Unity issue. Putting it in windowed mode in Bliss seemed to get rid of the massive black space, but that defeats the purpose of running at my monitor’s resolution. The incorrect scaling also seems to mess with the mouse as well. The closer the cursor is to the bottom left corner, the closer your click matches up to the tap in the game. It’s a little broken in windowed mode as well.

Into the Future

I’ll need to figure out how to get Blue Archive to scale correctly and improve the performance of Bliss. Alternatively, seeing that whatever Bliss OS did for the ARM bridge works, I want to try and see if Waydroid will work too. I expect Waydroid will run far better since I won’t be running an entire operating system.

But I’m happy that the game does run using Bliss OS though. Finally, the delicious taste of success (or, at the very least, progress).