An Android's Life
George Burns was an old comic, and working with Android makes me think of one of his old jokes that I’ll paraphrase:
Someone asked me, "George, are you dating much?" I replied, "I date almost every night. I almost had a date on Monday, I almost had a date on Tuesday, I almost had a date…"
Why does that remind me of Android? Well, Android uses Java. Almost. Android is Linux. Almost. As I experiment with Android Studio, all of these differences come back to me. It is tempting to imagine that if you know Linux and Java, you know Android. Almost.
Let's start with the operating system. Linux is a multiuser operating system (although from the way many people use Linux as a desktop system, you'd hardly notice). Android makes the realization that your phone or your tablet are (usually) single user device. As a result, the Android architects flipped it around and made every application a separate user. With the introduction of multiple users (because people do share their tablets and, sometimes, even their phones, after all) the system creates unique user IDs for each app installed by each user.
As a result, each program runs in its own jail, just like each Linux user does. The system can prevent programs from writing to any places it shouldn't. You might think that you could write a program that posed as another program's user ID to gain access to its data. You can't. First, you don't know the user ID since it potentially is different on every machine. Second, you have to have the same digital signature as the other program in that user ID. You can actually use that to your advantage if you have multiple programs that you want to interact — sign them with the same certificate, and they will get the same user ID, if they use the same
sharedUserId attribute in their manifest files.
That helps explain why signing an APK (the package file for Android) is so important, even if you usually use a self-signed key. If you think about it a bit, it makes sense. Linux is already there as the base operating system and offloading security to that already-existing component means the virtual machine (Dalvik or ART, the new Android Run Time) doesn't have to worry about it. Presumably, that makes the virtual machine leaner and simpler.
Dalvik (or ART) is part of why I say Android is almost Java. The virtual machine for Android is different from a standard JVM (the security model is just one example). In addition, Android has its own set of standard classes, which include a subset of the standard classes (some of which you are warned you should probably not use anyway).
If every application is a user, then how do apps ever talk to each other? Android provides a set of fine-grained permissions (for example,
WRITE_EXTERNAL_STORAGE; you can find a full list on the Android developer site). These are declared in the program's manifest and the user has to agree to them at install time.
To fully understand permissions, you need to know a bit more about the components of an Android application, which I'll discuss next time. Meanwhile, how does all this relate to Android Studio? For the most part, unless you want to share a user ID, it all comes down to adding permissions you need in the AndroidManifest.xml file (under your src directory). The new project wizard leaves a default one there for you:
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.al_williams.ddj1" > <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> </manifest>
To add a permission, you will have to manually add