From Android 1.0 to 8.0: How the World’s Most Popular Mobile OS Evolved

Android m3 and m5

Few people realize that the first public Android release wasn’t Android 1.0 in 2008—by which time iPhone OS 2.0 was already out—but a build called m3, which came out almost simultaneously with the original iPhone.

This emulator depicts the HTC Sooner (aka HTC EXCA 300), which was supposed to be the first Android smartphone. It’s clear Google was targeting business users: owners of BlackBerry devices, Nokia’s E-series, and Samsung’s i-series (i780). After the iPhone launched, Google’s stance changed dramatically: the HTC Sooner was canceled, and in the Android m5 emulator released just a few months later, the handset shown adopted a more familiar form factor.

Despite having a keyboard and a joystick, Android m3 also supported touch input. You could tap any UI element, and swipe gestures were implemented—for example, on the home screen you could swipe left or right across the app tray to scroll through the apps. Gesture-based scrolling worked in lists too; you could, for instance, scroll a web page in the browser.

Outgoing call and conference call (m3)

The touchscreen didn’t make the device any easier to use—it felt tacked on. UI elements were too small and not designed for finger input. The m5 version is a different story: the interface elements are large and hard to miss. The launcher still looks unusual but more familiar (see screenshot): the four most recently launched apps appear on the right.

As with iPhone OS, Android m3 had a full-fledged browser. These days it barely works: it constantly complains about expired certificates, runs painfully slow, and many sites either don’t render at all or show up distorted with missing elements.

Modern sites won’t load, but WAP works

That said, the browser doesn’t feel like a rough, unfinished product. It’s no worse than the stock browsers that shipped on regular phones of that era. You get bookmarks and history, plus a dedicated option to clear history, cache, and cookies.

On the M5, the browser is different and optimized for touch input, but that’s where the differences end.

The M5 browser

Both versions come with Google Maps preinstalled. However, you won’t be able to view the maps through this app—they simply don’t load. Fortunately, even without them, you can still evaluate the app’s interface and functionality.

Here’s what basic maps look like (m3 on the left, m5 on the right).

Nice, isn’t it? Even the Java version of Google Maps had more features (yes, Google used to release Maps for Java phones; it could determine your location via cell towers and GPS, and it could even do routing).

Contacts and recent calls (m3)

It’s clear that m3 has more in common with classic button-based feature phones and looks nothing like iOS. At least now we know why older Android smartphones had a “Menu” button—it’s the equivalent of the right soft key (the “Options” key) on a typical feature phone.

Back in the day, Android m3 could have been a solid rival to Symbian and feature phones. There’s no point comparing it to Android 8. Same goes for Android m5 versus the new Android 8—it’s clearly a concept build that Google rushed out after the iPhone launch.

Android 1.0–1.5

After booting, you’re greeted by the lock screen. By today’s standards it looks terrible, but it’s not far off from Android Oreo’s lock screen—just missing missed events and notifications. To unlock the device you have to press the Menu button. Swipes don’t work here.

The launcher looks familiar. It settled into the look that would persist up to Android 1.6. It supports widgets and shortcuts that you can freely move around the home screen. Overall, the concept is similar to the Pixel Launcher that ships by default with Android 7+, except it can’t automatically move shortcuts into available space and doesn’t allow widget resizing.

Oddly enough, version 1.0 had no settings—they didn’t show up until 1.5.

The notification shade is there, but compared to modern builds it only does two things: you can tap a notification to open the app, and you can swipe it away. No Quick Settings, no notification display options or blocking. Notifications can’t expand or include action buttons. And of course, there’s no iOS-style Heads Up banner that shows a notification at the top of the screen.

The Maps app in 1.0 still works. It can display points of interest (like shops), but it doesn’t show extra details such as phone numbers, business hours, or popular times. There’s no quick “nearby” search for places like hospitals, cafes, bars, gas stations, supermarkets, and so on. Street view mode still works, though. There’s no multi-touch support, and overall it’s very awkward to use.

The browser now supports tabs! There are major under-the-hood changes too: the engine has clearly been updated. It’s now correctly detected by sites as a mobile browser (in m5 and earlier, it tried to load heavy desktop pages) and it’s noticeably faster. I was able to open our magazine’s homepage, but the browser crashed when I tried to view an article. As I later found, it tends to crash when opening heavyweight sites packed with scripts and images.

Browser (left), Gallery (right)

Music player (left), Messages (right)

Technical Details

Based on the hardware of the HTC Dream, the recommended system requirements for Android 1.0 were roughly as follows:

• Touchscreen, 320 x 480 resolution
• Call and End call keys; Menu, Home, and Back buttons
• 528 MHz processor
• 192 MB RAM
• 256 MB ROM

However, our small investigation confirms (see screenshots) that the OS could easily fit into 128 MB of ROM. On the emulated device, the system partition is 64 MB, of which the OS uses 42.3 MB, leaving 23.2 MB for future updates. In /data (app data and third-party apps), 29.8 MB is used out of 64 MB, with 35.7 MB free. The cache also has 64 MB allocated, but it only needs 1.1 MB. Bottom line: the system takes about 73 MB in total, and the rest can be left for third-party apps, which at the time rarely exceeded a megabyte.

A sufficient amount of RAM for the OS is 64 MB—first, because in the emulator the system runs just fine with 92 MB, and second, back in the day Chinese manufacturers were churning out smartphones with 64 MB and they worked perfectly well (speaking as the owner of one, I can confirm. — Ed.).

Let’s take a look at what the system image contains. To do that, we’ll unpack system.img. Compressed, the image is only 26 MB; once unpacked, it’s 41.3 MB. By today’s standards—when a single app can be 100 MB—that’s tiny. Yet it’s a full-fledged operating system that can do much of what modern Android can.

Directory structure in Android 1.0 (left) and 7.1 (right)

All system applications and services reside in the app directory. In modern Android, applications with elevated privileges—mostly system services—are placed in a separate priv-app directory.

Open app and behold a minor miracle: the apps take up almost no space. The heaviest ones are the launcher (1.32 MB) and the browser (0.98 MB). Some are under 100 KB (Voice Recorder — 44.4 KB, Calculator — 86.1 KB, Street View — 94.9 KB).

Let’s peek into the etc directory. This is where configuration files (settings) for various system utilities live. The otacerts directory is particularly interesting. Based on its name and the files inside, Android 1.0 supports OTA updates.

There’s no lib64 directory, and the OS doesn’t support 64-bit applications. The Java class libraries (framework) take up only 6.3 MB, compared to 251.3 MB in the current version.

Run the mount command and you’ll see that early Android used the YAFFS2 file system, designed for flash media with high wear rates (back then NAND quality was poor and bad blocks were common). YAFFS was single-threaded and slow, so in Android 2.3 Google dropped it in favor of ext4, the standard file system for Linux-based systems.

Another hallmark of Android 1.0 was the absence of a JIT compiler. Java has always been Android’s official language, but instead of the standard JVM it ran apps on Dalvik, a register-based VM that was more memory‑efficient than Java’s stack-based virtual machine. While Dalvik used less RAM, it was significantly slower than a conventional Java VM at executing applications.

Google didn’t fix this until version 2.2, when it finally introduced a JIT compiler that translated bytecode into machine instructions on the fly instead of interpreting it. In Android 5.0, it was replaced by an AOT compiler, which converted apps to machine code at install time—slowing down installation and limiting the virtual machine’s opportunities for runtime optimizations.

To address this, Android 7 adopted a hybrid JIT/AOT compiler. Right after installation, the app runs under a JIT compiler, but when the phone is idle and charging, the AOT compiler kicks in and compiles it ahead of time to native machine code. In reality, the pipeline is more complex; explaining all the nuances would require a separate article.

Interestingly, Android 1.0 already had application sandboxing, implemented in a neat way: each app ran as its own Linux user, so it could only access its own directory under /data/data.

Applications could communicate with each other and with the operating system only through the Binder IPC mechanism, which required authorization to perform actions. The same mechanism was also used for a number of other purposes: the system used it to notify apps about system events such as an incoming call, an SMS arriving, the charger being plugged in, and so on. Apps would receive these messages and could react accordingly.

Thanks to this design, Android has long offered extensive automation capabilities, as seen in apps like Tasker, Automate, and Locale. All of these apps are available on Android 8 as well, though certain risky capabilities—such as toggling airplane mode—are now off-limits to regular apps.

Android 1.0 had no push notification support and imposed no limits on background app activity. Inept developers often abused this, shipping apps that chewed through battery life. Google didn’t really fix the issue until Android 8, which blocked starting background services—although some Chinese ROMs like MIUI had already implemented similar restrictions earlier.

Most importantly, early Android was sluggish. It stayed that way until version 3.0, which finally learned to leverage the GPU for 2D rendering. Why wasn’t that there from the start? Because Android was designed to run on everything, including the cheapest phones—many of which didn’t ship with a graphics accelerator at the time.

The Paradox of Novelty and Security

Year after year, Google’s engineers added new protection mechanisms to Android. At first glance, that might make Android 1.0 and 8.0 look as far apart, security‑wise, as Windows 95 and Windows 10. But that’s not quite the case. As we’ve already covered, the OS was designed from the start with app sandboxes, an IPC mechanism, and a permission model with multi‑layer privilege checks (down to the Linux kernel). Most of the OS was written in Java, whose design prevents writing code that can trigger buffer overflows, out‑of‑bounds array access, use‑after‑free, and other classic exploitation techniques.

Over time, the operating system accumulated new features and capabilities. And the more complex and sprawling the code became, the harder it was to debug and fix defects. As the system evolved, entire subsystems emerged that attackers could exploit.

For example, Android 1.0 didn’t include the Stagefright media framework (it arrived in Android 2.3), which was later found to contain numerous vulnerabilities that could let an attacker compromise a smartphone just by sending an MMS or getting the user to open a specially crafted link.

Android 1.0 didn’t even have the Accessibility service, which today can be abused to take full control of a device. It also lacked Device Administrator mode, a feature malware loves to use to block removal.

On the other hand, many defenses introduced later didn’t exist back then: SELinux, Seccomp, app permission prompts and controls, the Verified Boot system integrity check (introduced in Android 4.4 but only fully enforced in 7.0), data encryption, downgrade/rollback protection, and the Verify Apps online antivirus that’s been around since 4.2. You couldn’t even set a PIN on the lock screen.

Legacy apps

Opera

In January 2009, Opera Mini 4.2 appeared on the Android Market. What’s notable is that it’s the regular phone build of Opera Mini 4.2 running inside a Java ME emulator. It still renders pages very well, thanks to the compression proxy.

SlideScreen

One of the most unique Android launchers. Displays lots of useful information on the home screen. Works great on Android 1.5.

Facebook

At the time, it was just a wrapper for the site’s mobile version. All features still work to this day.

ES File Explorer

A file manager with an excellent feature set, even by today’s standards. It’s only 1.87 MB in size.

Conclusion

Android 1.0 was a genuinely interesting OS. It’s lightweight and runs well under tight resource constraints. Its architecture was solid from day one, so it’s misguided to claim that Android only became a “real” operating system recently.