What inspired you to go into Android development?
To be completely reductive, being a broke college student is what started me on my Android journey. Way back when I was in university, a few classmates of mine and I wanted to start delving into the world of app development. Android and iOS were both fairly new at the time. What it really came down to was the fact that I did not have a MacBook or the $100 to pay for Apple’s developer program. Google’s offering was a free SDK that you could use in any environment (Linux/Mac/Windows) and did not require any kind of special permissions to deploy an app to a phone. You only needed to pay a one-time fee of $25 if you wanted to actually publish an app to the Play Store. So, it was a pretty clear choice for me at the time.
After I graduated, I actually worked as a Django developer for a while. For those that don’t know, Django is a web app framework written in Python. I ended up getting laid off from that position fairly shortly after I began, and landed another job at a local shop doing Android work, which I’d always been tinkering with in my spare time. Eight years and one company later, and I’m still at it.
What is your specialty/area of expertise?
If I had to choose an area of expertise, it would probably be working with UI. Not necessarily design stuff, I’m definitely not a designer. But building out UI is something I’ve always been quite fast at, and quite good at. So much so that I appear to have a bit of a reputation now at Signal for being fast at that kind of stuff, so a lot of those sorts of tasks get thrown my way. That being said, I do consider myself a full stack developer of sorts, as I do deal with all aspects of the “stack”, including networking, database stuff, UI, and so on. Mobile development sort of forces that on you. I’d also say I’ve got a very strong grasp of software architecture. Stuff like the SOLID principles, design patterns, and the like of which, and I reference that knowledge on a daily basis.
What is your team working on overall?
My team specifically handles the development and deployment of the Android application. Day to day, I spend the majority of my time slinging code and doing code reviews. We are all very senior developers, so there’s a lot of trust and responsibility placed on each of us to get done what we need to. However, it is a very collaborative environment, and needs to be, especially when you’re dealing with cross-client features.
There’s a lot of cool stuff in the pipeline, some of which I obviously can’t talk about. If people are curious about what is on the way, they can take a look at the `FeatureFlags.Java` file in our codebase on GitHub. There are some hints there!
What are Signal's Biggest challenges? The biggest challenges in your role?
I think our biggest challenge is getting the app installed on devices. There’s this concept of the “network problem”, where people are hesitant to adopt a new communication tool because others they know aren’t currently using it. That sort of self manifests in a way where, well, Alice doesn’t install because Bob isn’t on it and Bob doesn’t install because Alice isn’t on it, to put it super simply. On top of that, the other key players in this field are for-profit and are backed by billions of dollars. They can influence markets through methods like pre-installs (for example, how Samsung will pre-install Facebook on their devices) or through deals with cell providers for zero-rating data (for example, some telecoms will zero-rate data from WhatsApp). Zero-rating just means that the customer doesn’t pay for this data.
In my role, I experience the normal pains of any Android developer around version fragmentation and manufacturers’ tendencies to muck around with the operating system. That manifests itself in a few ways. For example, we maintain two different camera implementations and choose which to use at runtime based on not only the devices’ API level but also against a blacklist we maintain of devices with known issues with some of the newer APIs.
Additionally, there’s this concept I like to refer to as security-first programming. This really boils down to putting the user’s privacy and security at the forefront of everything we do. For example, we do not allow any user content such as photos or videos to be written unencrypted to the user’s device. What this means is that there are situations where we have to remove functionality in order to preserve privacy.
An example of this is video capture in the Android application. This is only available for API 26 and higher (Android 8). This is due to a single constructor on MediaFormat which is only introduced at that API level and is not available earlier. The constructor allows us to hand the MediaFormat a file descriptor instead of a file path. In previous API levels, we needed to hand it a file path somewhere on disk to write to while it was processing the file. This is a no-no because it would result in unencrypted data being written to disk. Being able to write to a file descriptor means we can now do everything in memory. Since this isn’t backported to earlier API levels (older versions of Android), we need to restrict access.
What have you learned that surprised you the most while working at Signal?
Working for a non-profit has been a refreshing experience because there is no bottom line. There are no shareholders or investors that have some stake in you, and no one trying to profit off your work. I think that makes for a different development experience. When we plan out our work, there’s some amount of democracy in that decision process. We do have our larger goals we work towards, but they’re all in the name of making a better, safer product for our users.
Additionally, the people who work at Signal are all so passionate about the mission. Democratizing security and privacy. Making this stuff easy and automatic. And everyone is so smart here as well. I’m constantly learning from the people around me. So I guess that’s the surprise. It’s not a huge, wow but it was very eye-opening to go from working primarily on projects focusing around ad revenue and analytics, to one which was just trying to make the best product possible for its customers.
What are some of the unique challenges working on open-source that is focused on security and privacy?
The biggest challenge I can think of here is that we are always under the eye of public scrutiny. We have folks from organizations like Project Zero constantly testing our code, and looking for vulnerabilities. We also constantly have people taking a look at our commits, feature flags, etc, to try to get an idea of where we are headed. To be honest, while this is a challenge in that we really need to be on our A-Game when it comes to delivering secure features, the scrutiny makes us stronger. We are publicly vetted by security professionals constantly, and the application is better for it because if they do find issues, we can adapt and fix them very quickly. I think this is what positions Signal as the most secure messaging platform on the market.
What advice do you have for people wanting to get involved in Android development?
My biggest piece of advice for learning anything is to start small, and set goals. Have some idea of what you want to learn, and what you’re hoping to get out of it. Android is vast, and to be completely honest there are large portions of it that are just a plain pain to deal with. These parts could be poorly written, buggy, etc. Knowing what to do, what not to do, and so on comes with time. I recommend also having a strong grasp of both Kotlin and Java if you’re looking to get into the job market. I spend a good amount of my time reading the Android source code, trying to figure out why something isn’t working properly, and it’s all Java. Most employers these days have made the switch to Kotlin, so having that skill set is important as well. To be honest, if you know Java, Kotlin should only take a couple of hours to learn. You don’t need to know every single little feature of the language you’re working in to be productive. It’s more important to start writing real code than it is to continue doing small exercises. Lastly, you need to put the hours in and actually build sometime. The Android developer’s website has excellent guides that will get you writing some code fast. I think this is the number one resource I would recommend.
What technology and trends are you most excited about?
Rust is super interesting to me. I think that if I wasn’t an Android developer I’d definitely want to be doing something in Rust-land. My background is in Computer Engineering (not that I’ve ever worked an actual C-Eng job in my career) but I find Rust quite exciting and refreshing. For those that don’t know, Rust is a programming language aimed mostly at system-level stuff. It has this unique take on memory management and data ownership through the use of lifetimes and scopes that appears to eliminate a lot of common bugs in multithreaded programming and in manual memory management, while still not requiring the overhead of a separate garbage collector. I’m also interested in Rust from a multi-platform development toolset, whereas you could build out the domain layer (business logic) of an application in Rust and then distribute that along with some bindings to your Android / iOS / desktop developers.
The trends I’m most excited about are those involving cross-platform app distribution. I do think that we are going to move towards more cross-platform sharing, it’s just not super clear to me what that’ll end up looking like yet. Signal does already employ a bit of cross-platform sharing, via our Rust libraries. This allows us to reuse code between different clients and have a single, well-tested source of truth. I think that long term this is an amazing step for stability and is a great area of investment. There are also tools out there like Flutter and React Native that I’m not quite as hot on personally because I do believe that Android users and iOS users expect different things when they use an application. When you try to shove all of these different patterns into a one-stop platform like Flutter, you normally end up with either something that only ever feels like an Android app or only ever feels like an iOS app. I’d be curious to see more work in this field around making it not only easy to get the same UI working on both platforms but have it automatically look, feel, and act like it should on each. It can’t just be an option, because that feels like something you then need to spend time on. What I’d be more interested in seeing is a structure that has a Rust core containing all of the low-level stuff, domain logic, and so on, and then native front ends for that core. These front ends could be written using the latest and greatest on each platform. For example, SwiftUI and Compose.