Learn from my Mistakes - Trying Flutter Development on Chrome OS

Schadenfreude. Oxford Languages defines it as pleasure derived by someone from another person's misfortune. Personally, I just hope it's enough to get you through the next 1,200 words I have to say about the Flutter framework.

Anyone who looks at some of the other stuff I've written here could probably guess that I've been running my Chromebook for a while. I've been using the Linux container since it was still in Beta, and it looks like that fact may have contributed to some of the issues I've had getting Flutter up and running the way I wanted.

Giving Credit Where Credit is Due

To be fair to the various teams involved at Google, I was able to get a basic Flutter experience up and running without too many issues. I downloaded the ~600 MB SDK, unzipped it to a suitable directory, added that location to my PATH, and proceeded to download ~800 MB of Android Studio, so I could go back and download I-forget-how-much data for the required command line tools, the required Android SDK, and the Android Studio Flutter plugin (which requires the Dart plugin!) to get this whole thing up and running.

Once I figured out that I had to accept several Android license agreements through the flutter doctor command line tool (you couldn't give me a button in Android Studio, which I'm required to download anyway?), I was able to get the starter project to run under Linux. I clicked the little floating action button a bunch of times to get a big number, and switched to Android Studio to change the app's primary color scheme, since the IDE really wants you to try the Hot Reload feature. I was duly impressed.

But no one downloads ~800 MB of Android Studio, plus however much the Android SDKs and tools are, just to change the color on a button clicking app on Linux. I want to change the color of the button clicking app on my phone!

Powerwash to Continue

The problems began when I realized I wasn't able to just plug in whatever Android device I wanted, and send the app over like on Windows, or normal Linux. Since the whole thing was running inside a sort of virtual machine which was running under an OS that's supposed to be simple and secure, I didn't really expect it to be that easy. At the same time, it's a Google SDK (two, technically), using a Google IDE, running on a Google operating system, which the Flutter SDK explicitly calls out as a supported development platform. It probably shouldn't be difficult to test apps on a real device.

According to the installation guide, I should have been able to plug in my device, and (assuming it's in developer mode, which it was) see a popup asking me to connect to Linux. I did not. Right below that section, they also list instructions for testing Android apps on the Chromebook, itself. Just go to Settings, Developers, Linux Development Environment, Develop Android Apps, hit Enable ADB debugging, and restart. That sounded easier than trying to figure out how to get it to see my phone, so I looked for the switch.

It was disabled.

Instead of letting me turn on ADB debugging, the option had a message warning me that I'd need to perform a factory reset of my device in order to enable that feature.

For Chromebooks, this normally isn't that big of a deal. The basic premise of the devices, at least originally, was that you can pull one out of the box, sign in with your Google account, and pick up right where you left off, since everything saves to the cloud. With just a few clicks, you can also powerwash an existing Chromebook, and pretend you just took it out of the box. Android apps, and Linux containers don't work that way, but here we are.

Of course, the minds at Google already thought of that, so they provided the option to back up a Linux container, and fill a new Linux container with the contents of the ironically named .tini file they give you. (Mine was over 9 GB, which is actually pretty decent compression for the size of my container.) It took about an hour to generate that file, and save it to a USB solid state drive, which seems excessive. Once the device was powerwashed, it took another hour for it to read back all those files, and try to rebuild my old Linux container.

It failed.

Twice.

Since I have a bad case of this-Chromebook-only-has-64-GB-itis, I'd long since deleted the ~600 and ~800 MB install packages. But since I couldn't seem to get my backup to restore properly, I had to go grab them, again. And the Android SDK. And the command line tools. Linux desktop support also has some prerequisites that I'd already had installed before, which weigh in at about 150 MB to download. I ran flutter doctor to accept the license agreements we all know I definitely read. The doctor still thinks I don't have Chrome installed, since I refuse to install Chrome inside a virtual machine that runs on Chrome—at least not while I'm suffering from 64-GB-itis, anyway.

This time, however, it recognized my phone instantly. After all this work, I now have a Google IDE ready to build apps with a Google SDK, from inside a Google provided Linux environment on a Google OS, which can run on the Google OS on my Google phone. It looks like this:

Conclusions

As much as this installation process has annoyed me, I still have high hopes for Flutter. The cross platform aspect definitely appeals to me, as someone who has explored Qt Quick (using Material Design!), as well as React Native. During my initial experiments, I was able to prototype things fairly quickly, though it remains to be seen how productive I can be when I move beyond that stage.

Data Loss?

While the initial plan to restore my Linux container from a backup was an epic, and time consuming failure, I still have the data. According to this Google Support page, the giant .tini file is essentially a gzipped tar archive, which is a common file format in the Linux world. Google officially recommends installing the Wicked Good Unarchiver Chrome extension to access the files, if a standard restore doesn't work. Simply change the file extension from .tini to .tar.gz to browse its contents with Wicked Good Unarchiver.

Fortunately, I was already aware of alternate methods to access the backup data before I started the process, and didn't have anything terribly important stored in the previous container, to begin with. On top of that, I can also understand why the backup tool may have struggled with my particular setup. After all, I created the container with a beta version of Crostini. At one point, I performed an in place upgrade from Debian 9 to 10—probably before I was officially supposed to be able to do that. To make things worse, the 64 GB storage space seemed to be causing problems, despite the fact that I kept the backup on external media. Newer containers on systems with more storage should fare better.