2022-05-08 eSIM, and the Sad State of AOSP

The current state of AOSP (Android Open-Source Project) is sad. Or rather, sad from a user / third-party developer perspective. I'm sure this same opinion has been reiterated a million times across the Internet, but my recent endeavor with eSIM only proved this point even more.

For the longest time, I thought eSIM was a huge threat to user freedom on Android devices, because I believed all of them had proprietary interfaces that can only be operated through a proprietary vendor app, which often depends on Google services. On Pixel devices (and a few from other vendors), this is the EuiccGoogle app, which is part of the GMS stack. As a result, I became increasingly worried about the future of mobile devices, as carriers move to eSIM or even eSIM-only models, and I can't say I haven't put the blame on GSMA, the GSM Association, at least mentally.

Turns out, this worry is completely unnecessary, or at least not for the reason I started with. The GSMA publishes the complete standard for consumer profile eUICC (eSIM) chips, GSMA SGP.22, which includes full specification of the protocol to communicate with said chips and the protocol to download new eSIM profiles over the internet from carriers. At first, I did not believe that this standard is actually followed and I thought there must be some proprietary stuff on every single one of these chips preventing an open-source implementation of a eSIM management app. However, from my attempt to dig into the internals of the eSIM.me app, I discovered an open-source library from Truphone, which claims to implement the ES9+ and ES10x protocol to communicate with both eUICC chips and carriers' servers (RSP servers).

I, of course, did not believe this would actually work for eUICC chips embedded in consumer devices. However, because I knew phhusson has an interest in SIMs, I pinged him anyway for this discovery, saying that if this is what eSIM.me used, it might work for other eUICC chips, but I wasn't too motivated to put a lot more time into it. He, though, was excited. The very same night, he seemed to have stayed up very late to play with this library, and told me that it worked on his Samsung devices to successfully provision new eSIM profiles. I saw his message the next day, and immediately became intrigued. I pulled out my dust-collecting Pixel 4a, and tested phhusson's proof-of-concept, and confirmed that the library was able to communicate with the eUICC chip on my Pixel as well.

What prevents me from just making an open-source version of EuiccGoogle, then? I thought. At that point, I already realized that it is totally possible to make an open-source eSIM Local Profile Assistant (LPA) app that replaces EuiccGoogle. As I had some free time that day, I figured there was no better time to start the OpenEUICC project. I was able to finish a basic UI that day, and was able to manage and provision eSIM profiles on my Pixel 4a from my open-source app. I later decided to make it a full LPA implementation by integrating with the system EuiccService API, which is still an ongoing effort.

Why does AOSP not include an eUICC management app, then, as it seems that there is nothing proprietary about the management API / protocol itself? I don't know. One of the reason could be the need for proprietary firmware updates, but that is not really different from any other hardware that needs firmware, and I don't think it is a valid reason to keep the entire app closed-source only. Not to mention that EuiccGoogle does not even handle firmware updates itself -- it is delegated to another device support app. The only reason I could think of is laziness and the lack of "importance" of the open-source Android community -- just look at the current state of AOSP in general. The AOSP Dialer, SMS, Calender, and Clock apps are all stuck in their Android 6-era style. It is no wonder that nobody wants to introduce an entire new open-source component given that they do not even want to update the existing ones.

I would also like to make it clear that I do not want to put the blame on Google, or anyone else in the Android community. I could go on for days to talk about this, but at the end of the day, no single person or even company is responsible for this situation. All I want to say is that the current state is sad for an operating system that boasted openness and geek-friendliness, and I hope that my project, OpenEUICC, can contribute its tiny bit of help in alleviating this sadness.