Dual Boot Android from SD Card or Why It's Not Needed

Software
1

Later this year I might travel overseas. I have been trying to daily drive my Librem 5, and on my real/primary phone I prefer to not have Waydroid installed since I am suspicious of Google. But at some point recently, someone who might go on the overseas trip with me encouraged me to use some app that has no Librem 5 equivalent and so I busted out my old Android that normally is condemned to its faraday cage. Using the app, as with most Android apps, did not actually improve the quality of my life and was arguably not truly necessary, but I chose to do it.

After using that for a bit, I started to really want to run Android in a dual boot so that if a situation like this pops up while I’m overseas with only the Liberty Phone, I could similarly dual boot to Android and then participate in their society of bad software, while having the power to exit it back to my real phone for most of the time. I have my concerns that overseas customs, or any manner of other system I do not plan for, may declare I must “get their app,'” for all I know. It is not a guarantee, but I also cannot rule out the possibility.

But I like the Librem 5. I like the hardware kill switches and I like the removable battery. It’s a good hardware. I should not use Android, but if I do, I would rather it to be on something with Librem 5 hardware features.

But when I tried downloading Android for i.MX 8M Quad from the NXP website to see if I could make that go on my old backup Librem 5, I nearly bricked it. It was saved by the graces of obscure knowledge from @dos , and I got it back to the safety of running PureOS.

But I still would like to have a plan, for if I’m overseas and get in a “download our app” situation wherein some foreign system forces its will upon me.

So tonight I tried something different. Last time I tried Waydroid, it felt clunky performance wise. I was running it on the original Librem 5 with 3GB RAM, on my backup, when booting from SD card to try to keep Google out of as much stuff as possible. Back then, when my goal had not been nebulous but been a very specific Android app that I needed for my job, what I found was that the app only functioned in the GAPPS version of Waydroid - which is to say, when it was infested with Google Play Services.

But it ran too slowly. The point of the app, as I have ranted about elsewhere, was for something I have to do every single day and it should be fast. It entails basically clicking an unlock button. But inside the app, when decompiling it, it was built with react, libfacebook, Azure AI vision, mechanisms for pretending to be skype so users don’t notice its network traffic, a system for experimentation services to experiment on the user, and a communication protocol where what the user sees as a simple OK button actually sends home to a server endpoint that isn’t in the app code and is instead received within the notification system’s property map from Google Services, and submitting the OK button to the endpoint requires metadata including user location, country, timezone, and anything else they can get to ascertain that the Android app was itself running in the way they intend.

Sorry for that tangent, but what I mean to say is that the human time investment for the reverse engineering of this particular app was seemingly a no-go back then. But within Waydroid it was maybe a 20, minute boot process to emulate running the app. It was really too much pain for solving a problem whose use case is an “OK” button that the user must click within 30 seconds. So I had a tendency to see Waydroid as junk that isn’t really going to work.

But tonight I threw the kitchen sink at the Android problem. The advice from @dos about my stupid NXP Android idea was that if I was serious about that, I should recompile AOSP against the PureOS kernel tree and get a GUI that way. But tonight I didn’t figure I had that much time, and I wasn’t at the high power desktop with the specs to be sanely compiling AOSP in good time, so instead I tried running Crimson PureOS booted from an SD card, with the Zram speed ups described on recent forums threads, and then with Waydroid on top of that. I used waydroid prop set persist.waydroid.width and the same for height to convince Waydroid to use all the pixels, and the GNOME fullscreen keybind to hide the PureOS title bar and bottom bar. And I ran all of this on the Liberty Phone with the 4GB of RAM so it already started out ahead even before Zram.

And here, having thrown the technology kitchen sink at pretend-droid emulation, I just wrote this post with Android keyboard since Phosh keyboard is gone via fullscreening (other than some periodic flickering back in that it occasionally does).

But I guess it leaves me with some questions, for review:

  • If I were to actually compile AOSP on top of the PureOS kernel tree, rather than only downloading L5 Waydroid from the standard guide, would things like camera and battery percentage “just work” that aren’t available inside Waydroid, or would they likely all be similarly busted/disabled until someone wrote drivers that I probably wouldn’t bother to write?
  • Does running GAPPS Waydroid probably mean that Google can write over the L5 firmware blob storages and infest my device even when I boot back out of this Waydroid SD card (I surely hope not but just curious; if this is a theoretical possibility, have people had success with MicroG+Waydroid to solve that issue?)
  • Can I stop the Phosh keyboard and Phosh borders from flickering on periodically while the Waydroid app is in “GNOME”-based fullscreen mode?
  • Are other people doing this? Is it a sufficient replacement for dual boot to Android in most cases? Performance seems pretty acceptable and I can literally download junk from the evil Google Play store

This entire post was written with the Waydroid keyboard. A few times it froze towards the end, but then I just used Waydroid minimizing and resuming of the AOSP " app" window and it reset and unlocked the keyboard, for whatever reason.

Edit:
Writing this post seemed to burn me down from maybe 67% to 38% battery in a relatively short time. The device is also running hot. Does Crimson maybe run hotter than Byzantium at the moment, or perhaps does Zram crunch through more processing? Would AOSP on PureOS-based kernel tree use less energy than Waydroid somehow, or is Waydroid… Basically literally that same thing?

2 Likes
2

I would put it this way: if you run unverified Google code on bare metal then all bets are off.

I don’t know that Google would permanently alter the device but you don’t know that they won’t.

Worse still, as a practical concern, is that Google could basically lock your bootloader so that you can’t run any other operating system ever again … similar to what already happened but worse; so bad that even @‌dos can’t get you out of it. :wink:

My suggestion for exploration: Run Waydroid on a bigger computer, leave said computer running when you go overseas, and remote in to the bigger computer from your Librem 5 (making whatever security arrangements you deem appropriate for allowing remote access in to the bigger computer).

That or just take the Android phone but keep it switched off for the entire overseas excursion unless and until some overseas party deems that you must run their dodgy app, and otherwise use the Librem 5.

2 Likes
3

I have historically described that I was doing something like this as the solution to my older Android app life problem – which is to say, running Waydroid in a rented cloud node and remote connecting into it.

But, truth be told, it’s more complicated than that. I don’t know if it’s Google, or human apathy and my fault for not bug reporting and contributing to open source tools, or what. But in reality, running Waydroid indefinitely in a remote access endpoint has given me some major troubles:

  • Waydroid seems to crash about once per week in that situation
  • The libhandy version of the VNC client that I tended to use does not fully forward keyboard key strokes (at least in its Byzantium version), so running the terminal command waydroid show-full-ui in the remote sway window manager session to restart Waydroid literally doesn’t work when a Librem 5 is the client
  • Due to the above, my daily driver Librem 5 has typically only been a “short term client” for the remote Waydroid session. Every 5th time, when I log in to find Waydroid has crashed, it is actually my Librem 14 whose VNC client has full keyboard access, that I have used to step in and resolve issues and restart everything.

And for my overseas trip, folks said they wanted to travel lean, and take only phones and not laptops. So if I was actually going to use remote-controlled Waydroid as my serious broader-scope solution to the problem when overseas, then I probably ought to be spending more time on this to figure out the faults in our software.

Meanwhile, I again wrote this entire reply from my full screen Waydroid SD-card boot, but it’s on my good daily driver here. It’s temptingly smooth to use. Remote controls for a Waydroid box, or at least the ones I have used previously, are nothing like this. I wouldn’t write a post here with them. I am not so much a masochist.

Of course, Phosh and PureOS are so good that if writing posts were all I had to do, then I shouldn’t ever need Waydroid. In my head, I’m moreso just seeing the state of this technology. But maybe I have irreparably ruined my privacy and security by putting too much faith in a LUKS password hiding the eMMC from Google, as if that meant that when I power off Google would be gone.

3 Likes
4

It depends on how much malevolence or similar you want to attribute to Google or to anyone else whose code you randomly run.

For sure, the LUKS password is only as solid as the boot path. You’ve already seen how Android modifies the boot path, in that case probably not maliciously - but because the Android image wasn’t really suited to or specifically for the Librem 5 hardware it is difficult to know.

Automatically restart it on the bigger computer overnight (local time at your destination)?

2 Likes
5

I think it might be easier and in the long term more productive to have another looks at whether reverse engineering the functionality you need into a native app isn’t possible. From what you’ve said I assume there’s a proprietary sass service involved but you probably don’t need to reverse engineer the whole app with it’s AI vision parts, Skype etc.

Could you use Wireshark to inspect the requests being sent in and out and see if you can replicate them?

1 Like
6

Maybe for my old issue there might be some truth to this, but for the new problem of trying to have preventative Android ready to go in case some foreign official tells me, “Run our app or die,” I think for this new problem what you’re saying would not help.

The app mentioned from my past is Microsoft Authenticator. Microsoft has a lot of money. Even for an “open source” app like Signal, an app that is well funded by CIA can dodge having a Librem 5 client that works by updating all the time and sending legal takedown notices to forks, as they do. Why would we think I could similarly succeed at reversing a complex app that doesn’t even pretend to be open source?

The reasonable solution is to change employer, to someone who does not require this kind of freedom-disrespecting app. As others have said on this forum, if my employer is going to require me to run that, they should have at least provided me a hardware to run it on.

[Although, admittedly, that seems like a bit of a copout solution and having a work-provided spy device still means living with a spy device.]

3 Likes
7

Just for grins … has anyone ever asked Microsoft to document the protocol used by the proprietary part of Microsoft Authenticator (i.e. the part that is not just a TOTP implementation)? Surely Microsoft isn’t hiding behind “obscurity is security”?

I agree with your bigger point though … you won’t have time while on holiday to reverse engineer some random crappy app in order to provide an open source implementation. :slight_smile:

1 Like
8

I guess I could boot Windows on one of my machines, then call Microsoft tech support and say I need to do a secure Microsoft Authenticator login for my job. When they tell me Windows isnt secure and Authenticator isn’t supported on Windows, I could open Visual Studio or vscode and tell them I’m a programmer and I’ll do the unlock message from code, just give me the API for me to do it on my secure windows computer.

Forces them to admit that they dont want their customers using Windows. Could get a laugh even knowing in the end they won’t help.

2 Likes