Android and its Developers
Android has always been good to its users. Android, an Open Source operating system, has been around since 2008, when it was first released to the public as Android 1.0. It was created by Andy Rubin as a small company in 2003, and was acquired by Google in 2005. Since then, many more versions of the OS have been released, with each version named alphabetically and with the theme of a sugary treat (Lollipop, Marshmallow, Nougat, Oreo, etc). For Android 10, they did away with the treats theme (it probably would have been difficult to come up with a ‘Q’ name), and in November 2020, Android 11 was made available to the public through an over-the-air update.
A large part of what keeps the Android ecosystem alive is its apps. The Google Play Store, a pre-installed store on the device, allows users to browse millions of apps and download them. Apps vary in category and function, from weather and news apps to custom web browsers to social media apps to mobile games. Most devices come pre-installed with a small set of useful apps like email, calendar, and camera apps, usually written by developers from Google or manufacturers like Samsung. The majority of apps available on the Play Store, however, are written and maintained by developers outside of Google. They range from solo developers writing hobby apps to teams of developers hired by companies to write and maintain official apps such as Facebook, Slack, and Reddit. The rich selection and availability of these apps will keep most users attached to and satisfied with Android as a whole.
But what of Android and its relationship with developers? As we generally see with major platforms that cater to both developers and users, developers are a key part of the equation when it comes to platform health. Users flock to a platform, attracted by the number of quality of apps, and developers write for the platform hoping to capture a slice of the large userbase, and the cycle continues. If one side of the platform is neglected, the positive feedback loop may break. Often, one of the initial steps to getting a platform off the ground is to incent a large number of developers first.
Using the Circuit of Culture as a guideline for analyzing the Android platform and its relationship with developers, I will look at the how the Android SDK is made and how developers use it, how Android presents itself to its users and to developers, and finally, discuss the change in restrictions placed on the Android platform over time.
Production
How does one begin writing an app, and how do they work? The answer is relatively simple. Developers at Google, Android’s parent company, write and maintain the Android SDK and the tooling around it. The SDK is responsible for connecting low-level hardware functions like the display and the camera and providing a high-level interface for developers to use in their apps. The bulk of the Android API (Application Programming Interface) is written in the programming language Java, which is a popular language frequently that is also frequently used in university computer science courses. Java is designed with a write-once-run-everywhere philosophy, as the Java Runtime Environment (JRE) abstracts away many of the lower-level details and allows developers to focus on the design of their app and the business logic.
To begin writing an app, a developer should know a little Java, download the Android tooling, and start with the building your first app page, which gives an overview of the platform and a step-by-step guide on writing a “Hello World” app that will run on an Android device. It’s how most Android developers got started, and it’s how I began writing Android apps as well.
Guides are usually rich with explanations of concepts, code samples, diagrams and pictures, and they often have links to deeper topics and exercises. References, on the other hand, are very specific set of articles that detail the exact names, inputs, and outputs of classes (in Java, this is a blueprint of an object that can do something) and is mostly just organized text. Both are necessary for developers to understand how to build their apps.
Consumption
Developers typically use a conglomerate of sources to help with writing Android apps (similarly with other platform programming as well), but a bulk of the consumption of information will come from the official Android documentation. However, besides documentation, which provide official recommendations on how to do things, there is an abundance of information available in online question forums. Stack Overflow is one such place where developers will convene to search for or ask questions on how to accomplish a specific task.
Besides looking for guides on how to write code, developers also will seek information on general news about the platform and information on new releases. Users in communities like the subreddit /r/androiddev will aggregate news and information, and many developers check the front page to find out about new releases to tooling, as well as ask questions or answer them just like in Stack Overflow.
Restrictions and Regulation
In most comparisons to other application platforms, Android’s restrictions are relatively light. To publish on Android, one must create a developer account, accept the developer content policy and distribution agreement, and pay a service fee of 30% for any payment for in-app products that your app might offer. Unlike iOS, which requires a $99 dollar annual fee to begin developing for iOS, Android is free to get started. Both platforms share the 30% service fee, and so Android’s barrier to entry for developing is lower indeed.
One form of regulation that is implicit in developing software, however, is that an API is inherently a restriction on the functions that an app can use. It allows developers to interface with hardware such as the camera and the display, but ultimately how they are accessed is controlled by the API. In Android, this is apparent in the permissions system that developers must know about and work with in order to get access to specific device features.
Very briefly, the permissions system is a way for Android to give control of device access to the user, who allows to disallows an app access to certain hardware features. Before Android 6, a user would accept a list of permissions during install, without the ability to deny any one single permission. Research into this permission model showed that a majority of users did not understand what each permission did, and in some cases, malicious developers would take advantage of this and, for example, harvest contact information to sell to spammers and fraudsters.
In 2015 and introduced in Android 6, the OS began considering some kinds of access to hardware features potentially dangerous for user privacy and security and thus, required explicit user consent for an app to use them. This required some small changes that developers needed to abide by, lest their application crash.
In 2018, however, Android introduced another change that would restrict apps that used SMS or Call Log permissions. Apps that used these permissions would need to submit a form that showed that SMS or Call Log were used as a primary function of the app, like phone and texting apps. They gave developers 6 months to submit a review of their app or be removed from the Play Store.
This meant though that third-party apps with features not specifically related to calling, such as call recorders or SMS backup apps did not qualify. The app verification process did not include these categories as primary functions, and in many cases, developers who worked on useful apps that required these permissions were crippled. One prominent example is Open Data Kit Collect, which is a humanitarian research data collection app. One of its key features is to use SMS fallback to deliver data in conditions where cellular data is weak. The founder, after not being able to get his app verified through Google Play, appealed to the public on Twitter, but ultimately was not able to get the ruling reversed.
Representation
Android’s new policy around SMS and Call logs was certainly well-intentioned. As far a user privacy and security goes, the new restrictions would generally benefit users who may not even know that their data was being harvested. In the extreme end, even the Facebook app quietly scraped call data from users’ phones for years before quietly removing those permissions after the new policy was announced.
The Android team’s wording in announcing the policy was friendly and presented the Android team as willing to work alongside developers to work out the kinks in the policy.
We’ll be working with our developer partners to give them appropriate time to adjust and update their apps, and will begin enforcement 90 days from this policy update.
https://android-developers.googleblog.com/2018/10/providing-safe-and-secure-experience.html
In general, Android presents itself as very developer friendly and encourages practices that will safeguard user privacy and security while allowing innovation to occur on the platform. In this case though, it appears that in an effort to reduce the man-hours required to review thousands of apps that would submit permissions declaration forms, the Android team relied heavily on automation and bots. As the deadline for form submission neared, many developers had their requests to be whitelisted rejected and couldn’t even get in contact with a person to appeal the decision. Even popular apps such as Tasker and IFTTT only just barely made the cut as at the last minute, an exception for automation apps was added.
As the Android OS evolves over time and updates its permissions controls, it’s certain that developers will be held to higher standards of security and privacy as more and more people adopt Android. In the long run for platform health, such changes are generally positive as the methods that malicious apps use are discovered and removed. However, the announcement and enforcement of these recent policy changes could certainly have been handled better.
In 2019, Android introduced yet another security control to protect users’ device storage, called Scoped Storage. The initial reactions from developers was the initial implementation was flawed and would cripple another category of useful apps, namely file managers. Some developers even created a petition, urging the Android team to rethink the security control.
This time around though, it seems that the Android team may have learned their lesson and will give ample time for for exceptions to be discussed and implement changes, should they be required. A special flag was given to developers, requestLegacyExternalStorage, that allows developers to continue to use the old storage model until they are required to target the changes in November 2021. Hopefully, this model for introducing breaking changes can appease developer unease and while still benefiting users hoping for stronger security quickly. Strong developer relations will certainly fortify the Android ecosystem for many more years to come.
Cultural History of the Internet 