Regular readers of Styling Android may already be aware that I am very much in favour of using a build server to speed up my builds. In the past, I have documented how I use Mainframer and Mirakle. I have a very meaty 6 core i9 8950HK with 32Gb RAM, and 512Gb SSD running a headless Debian 11 for my build server. Which is pretty quick! However, sometimes there are issues with the build artifacts not working. I’ve yet to fully understand why this happens. But my best guess is weird compatibility issues between Mirakle and the Android Gradle Plugin. However, there’s a new kid on the block which has been developed by JetBrains named Projector.
In the previous article, we got Projector installed on my Debian 11 Linux build server. The process was much easier than I anticipated. So, while the setup was easy enough, how does it actually perform when we start using it?
Being based upon IntelliJ IDEA it initially performs well. However, it is not without issues. This may be in part because Android Studio because Android Studio forks lag behind IntelliJ IDEA. Android Studio Artic Fox Canary 14 is a fork from IntelliJ IDEA 2020.3.1, whereas the latest IDEA is 2021.1. It’s entirely possible that the niggles I have encountered
The Good
When you fire this up for the first time, you have a real “I can’t believe that worked!” moment. I certainly did! Your browser takes a second or two to load the page, but it’s just there. There’s no waiting for initial indexing or anything because that happened as soon as we launched the Projector Server from the command line.
Obviously, build speeds are going to vary depending on the specs of the machine running the Projector Server, but in my case, I’m getting builds taking half the time of my high-spec MacBook Pro.
At the time of writing, the latest Canary build is Arctic Fox 2020.3.1 Canary 15. My experiences are based upon that version and a couple preceding it.
The Bad
There are a few glitches when running Android Studio, that I didn’t experience with an IntelliJ IDEA instance. The first of these is when viewing the Logcat window in Android Studio. For some reason, there’s a real lag when you first open it, and your browser may reload a couple of times. This generally settles down after a short while, but it certainly slows things down when you first view Logcat.
The second issue is when you hit a breakpoint while debugging. Once again, the UI becomes somewhat unresponsive, and the browser may reload the page a couple of times.
Both of these are annoyances, but non-destructive ones. The browser reloading has no risk of losing any of your work because the Android Studio instance remains running on the Projector Server. The reload is because the network connection is getting reset. Once it resolves things, then everything returns to normal. It is a little frustrating, though.
The Ugly
The worst thing that I found was opening the Layout Inspector window. I’m referring to the new real-time Layout Inspector, here. I have found this to be a little finicky, anyway. When it works, it’s really nice. But it seems a little hit and miss, at times.
Opening it inside an Android Studio instance running on Projector Server is badly broken. It’s fine up until the point where it tries to display the layout details, then it messes with the entire IDE display. It makes everything window within the entire IDE fail to draw. You can redraw individual items by clicking on them, but the Layout Inspector visual display never appears, no matter what you do. Refreshing the browser window makes no difference. But closing the Layout Inspector window, even with Layout Inspector still running, bring everything back to normal. As does stopping the inspector with the window still open.
In short, Layout Inspector is completely unusable when running in a Projector Server instance.
Another area that is broken is launching emulator instances from AVD. When I try this, I get an error: AVD could not be started. I went through various fixes to grant the user permission to /dev/kvm, and then try to launch the emulator from a command line. However, I eventually discovered that the emulator wants to connect to a display, and there isn’t one on my headless Linux box. Even when using an Android Studio window to host the instance, it still appears to require a connection to a physical display in order to start.
Possible causes
The common factor in all of the performance / responsiveness / UI rendering issues is that all of the underlying features rely upon adb. Logcat, the debugger, and LayoutInspector all use adb to communicate with a real device, in my case. It is entirely possible that either adb or the underlying USB drivers on my Debian box are the root cause. However, I tried using adb to bridge to a device connected to another machine (as per Joaquim Verges excellent setup guide), and still got the same laggy performance. This will not have used the local USB drivers, so would appear to rule that out as a cause.
I have already mentioned that Android Studio is branched from IntelliJ IDEA 2020.3.1, so these niggles may actually be IDEA issues which have been fixed in the current version. So we may have to wait for Android Studio to migrate to a newer version of the underlying IDEA code.
Self updater
Another niggle that I had was that the Android Studio self-updater is broken when using Projector. I believe that it kills the current Android Studio instance, and runs an update script outside of the running Android Studio process. This does not work with Projector because when the Android Studio process dies, it also kills the Projector Server instance. While it is possible to run a system service to automatically respawn the Projector Service when it terminates, this does not help. I’m not sure whether the Android Studio update task simply does not run in this environment, or if it runs but gets killed when the Projector Servicer instance terminates. Either way, the update simply does not happen.
The work-around for the update issue is to do it from the command line. Download the version of Android Studio for your build server OS from here. Then unpack it to the directory where your Projector config for Android Studio resides. The next time that the Projector Server starts it will be the newest version of Android Studio.
Conclusion
The Logcat and breakpoint issues slow you down for long enough to be irritants and Layout Inspector is a real problem.
I think I could live without Layout Inspector, but the other niggles do slow things down when it comes to performing common development tasks. The whole point of using a build server is to speed up development by reducing build times. Some developers may not be happy if the cost of this benefit is being slowed down elsewhere. Personally, I’ve become too frustrated with the unresponsiveness and reloading issues to continue using Projector with Android Studio, for the time being.
I don’t think that Android Studio is that far away from working extremely well with Projector. Let’s hope that it’s not too long before it becomes fully compliant with Projector. But, for now, I’ll be sticking with Mirakle to run my builds remotely.
© 2021, Mark Allison. All rights reserved.
Copyright © 2021 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.
