The evolution of notifications

A notification is the one place an app can put something in front of a user who is not using it. That makes it the most contested surface in the platform, and its history is a record of the platform deciding, again and again, who may interrupt whom.

TL;DR#

• 2008: a pull-down shade with a ticker line and a small icon. No expansion, no actions.
• 2012 (4.1): expandable notifications — BigText, Inbox, BigPicture — and up to three actions.
• 2014 (5.0): lock screen notifications and heads-up peeks.
• 2016 (7.0): direct reply and bundled groups.
• 2017 (8.0): channels. Every notification belongs to one, and the channel holds the importance the user can change.
• 2020–2022: conversations and bubbles (11), then POST_NOTIFICATIONS as a runtime permission (13).
• 2023–2026: full-screen intent restrictions (14), notification cooldown (15), Live Updates (16), and tighter custom-view limits (17).

Mental model#

Think of a building's PA system.

In the first version, anyone with access could broadcast to every speaker at any volume. A maintenance notice and a fire alarm sounded the same.

Then the building added zones (channels): the cafeteria, the workshop, the offices. Each zone has its own volume, and a tenant can turn one down without silencing the others.

Then it added a priority override (heads-up), but only for zones configured as urgent. Then it added a visitor log (the shade) and a rule that you cannot broadcast at all unless the tenant signed a form (the runtime permission).

The PA system did not get quieter. It got more structured, and every structure is a decision about what counts as urgent.

Where the analogy breaks#

A building has one PA system and one landlord. Android has SystemUI drawing the shade, but the notification's content is rendered from a description supplied by the app — a RemoteViews (glossary definition) for custom layouts, or a system-drawn layout for the standard styles. The app controls what it looks like without running code in SystemUI's process, which is a security boundary the analogy has no equivalent for.

The big picture#

Use the two selectors to compare, for example, 2.3 against 8.0. The visual difference is small; the policy difference is the entire history.

Deep dive#

2008–2011: the ticker#

The original notification was a small icon in the status bar, a ticker line that scrolled once, and a row in the shade with a title and one line of text. Tapping it fired a PendingIntent.

There was no priority concept. Every notification made a sound, and the only user control was a per-app on/off switch. That is why the era's apps felt noisy: there was no vocabulary for "this is important" and "this is not".¹

2012: expandable and actionable#

Android 4.1 introduced Notification.BigTextStyle, InboxStyle and BigPictureStyle, plus up to three actions. The collapsed view stayed one line; the expanded view could show a paragraph, a list or an image.

This is the release where the notification became a small application surface rather than a message. It also introduced the pattern that persists today: the collapsed view is a summary, and the expanded view is the content.

2014: the lock screen and the peek#

Android 5.0 brought notifications onto the lock screen and added heads-up notifications — a small card that floats over the current app for a few seconds.

Both changes raised the same question in a new form: what should a stranger holding the phone see? The answer was a visibility setting per notification (VISIBILITY_PUBLIC, PRIVATE, SECRET), which is still the mechanism today.

The cost was immediate: an app that put a message body on the lock screen was leaking it to anyone in the room. VISIBILITY_PRIVATE with a redacted public version became the correct default, and most apps got it wrong for years.

2016: reply without opening#

Android 7.0 added RemoteInput, which lets a notification carry a text field that sends a reply back into the app without launching an activity. It also added bundling: notifications sharing a group key collapse into a stack with a summary on top.

Direct reply is architecturally interesting because it is the first time a notification could carry data into the app. The reply is delivered to a BroadcastReceiver or service through a PendingIntent, not through an activity launch, which is why it works without disturbing the user.²

2017: channels#

Android 8.0 made notification channels mandatory. Every notification must specify a channel, and the channel holds the importance, sound, vibration and visibility settings.³

This is the most important structural change in the history of the feature, and the reason is political as much as technical. Before channels, the user's only control was "notifications from this app: on or off". Many users turned apps off entirely rather than tolerate one noisy category. Channels let an app say "these are messages, these are promotions" and let the user mute one.

val channel = NotificationChannel(
    CHANNEL_MESSAGES,
    "Messages",
    NotificationManager.IMPORTANCE_HIGH,
).apply {
    description = "Direct messages from people you talk to"
}
 
notificationManager.createNotificationChannel(channel)

2020–2022: conversations, bubbles, permission#

Android 11 added conversation notifications — a notification marked with a Person and a shortcut gets its own section at the top of the shade and can be turned into a bubble. The mechanism is the setShortcutId and the long-lived sharing shortcut, not a new API surface.

Android 13 made POST_NOTIFICATIONS a runtime permission. An app must ask before it can post anything visible, and a denial means notify() silently does nothing.⁴

That last change reframed the whole feature. For fifteen years, the right to notify was implied by installation. Now it is a grant, requested in context and refusable — the same model as the camera.

2023–2026: restrictions and Live Updates#

Recent releases have mostly tightened:

• Android 14: full-screen intents require USE_FULL_SCREEN_INTENT, and Play policy restricts which apps may request it.⁵
• Android 15: notification cooldown reduces sound volume when many notifications arrive rapidly.⁶
• Android 16: Live Updates — a promoted, ongoing presentation for progress-style notifications like rides and deliveries.⁷
• Android 17: custom notification view restrictions tighten further, closing a URI-based loophole.⁸

The direction is consistent: standard styles are privileged, custom views are constrained, and urgency must be justified.

The three questions every release answered#

Across sixteen years, the same three questions come back, and each release answers them slightly differently.

Who may interrupt? 2008: anyone who installed. 2017: anyone whose channel the user had not muted. 2022: anyone the user granted POST_NOTIFICATIONS to. The direction is toward explicit consent, and it is not reversible.

How loudly? The ticker had one volume. Priority (2014) and then channel importance (2017) made loudness a per-category property, and Android 15's notification cooldown made it a property the system can reduce on its own.

What may it look like? 2012 opened the door to custom layouts; the releases since 2021 have been closing it. The standard styles are now the safe path, and custom views are a compatibility risk that must be retested on every release.

Reading a new notification feature through those three questions usually explains both what it does and why it arrived when it did.

The quiet feature that mattered most#

Direct reply (Android 7.0) gets less attention than channels, but it changed the shape of messaging apps. Before it, replying meant opening the app: the notification was a door. After it, the notification was a surface, and the app could be used without being opened.

That shift is why messaging apps now invest heavily in the notification's presentation, and why the conversation APIs (people, shortcuts, bubbles) exist. Once a notification can carry an interaction, its structure becomes product design rather than plumbing.

The channel design mistake to avoid#

The most common channel mistake is creating one channel per notification type at first launch and then discovering, months later, that the categories were wrong. Channels are permanent: deleting one and recreating it with a new importance does not restore the user's trust, and the old channel's settings persist on devices that had it.

The mitigation is to create few channels and make them meaningful: messages, ongoing activity, promotions, and maybe one more. A channel per feature is a channel per future migration problem.

How it evolved#

Under the hood#

• ‹›Notification.java↗the builder, the styles and the channel requirement
• ‹›NotificationChannel.java↗the channel object and its importance levels
• ‹›NotificationManagerService.java↗where a posted notification is validated, ranked and dispatched
• ‹›↗where the shade rows are inflated and drawn

Curiosity corner#

• The ticker text is gone but the field is not. setTicker() still exists on the builder and is ignored by modern versions, which is why old code compiles and does nothing.
• A notification is a Parcelable. It is serialised across Binder to system_server, which is why the content is size-limited and why large bitmaps are a real problem.
• The shade is drawn by an ordinary app. SystemUI is privileged, not magic; if it crashes, the status bar disappears while the rest of the system keeps running.

Try it#

$ 
adb shell dumpsys notification --noredact | grep -A3 "mId="

com.example.app:
  mId=messages mImportance=4
  mId=promotions mImportance=2

$ 
adb shell dumpsys package com.example.app | grep POST_NOTIFICATIONS

android.permission.POST_NOTIFICATIONS: granted=false

$ 
adb shell dumpsys notification | head -60

NotificationRecord{... pkg=com.example.app channel=messages importance=4}

Build it#

Create two channels — one IMPORTANCE_HIGH for messages and one IMPORTANCE_LOW for background status — and post to both. Then open Settings and mute the low one. The app's code did not change; the user's control did. That is what channels bought.

Check yourself#

Sources#