Understanding China's Android Push Notification Landscape and the United Push Alliance

Author: 冬冬/小明 (Original article, please credit the author and source when reproducing).

If you are an Android developer, you probably know that the push notification environment in China differs greatly from overseas and is rather chaotic. In mid‑October, Hujiang, representing developers, attended the Ministry of Industry and Information Technology’s "United Push Alliance" founding conference, announcing a national effort to unify app push services. The following is an overview of the conference and our reflections.

Domestic Android Push "Chaos"

Because Google’s unified push services (FCM & GCM) are unavailable in China, third‑party providers and device manufacturers have built their own push channels and maintain long‑lived SDK connections to push servers.

Maintaining these long connections consumes network traffic and, crucially, battery power, especially when the app is not in the foreground. The system cannot judge the necessity of many persistent connections and may kill those it deems unnecessary, causing push failures. To ensure delivery, providers often keep SDK background processes alive by “waking” the app, which further drains battery.

Consequently, manufacturers restrict app persistence at the ROM level while also offering their own push channels. Developers, seeking high delivery rates, integrate multiple manufacturer SDKs, leading to several push SDKs co‑existing in a single app and still failing to solve the power‑consumption problem. Moreover, many domestic developers underestimate the impact of push on user experience and overuse notifications to boost activity and retention metrics.

This mismatch of interests creates a "prisoner’s dilemma" for the push ecosystem: manufacturers limit background processes for system purity, while apps fight to keep processes alive for delivery, worsening the overall experience.

The prisoner's dilemma of the domestic Android push ecosystem

The introduction of Android O further tightened system‑level controls, posing a disruptive challenge to the existing push ecosystem, including manufacturer‑built channels.

These factors lead to a poor user experience and a chaotic push ecosystem, making a unified system‑level push channel urgently needed.

Establishment of the United Push Alliance

To standardize the domestic push environment, the Ministry of Industry and Information Technology invited major device manufacturers, push service providers, and app developers to form the United Push Alliance (UPA). The alliance will issue technical interfaces and standards that balance the interests of users, app developers, push providers, and manufacturers, while ensuring compatibility with existing push implementations.

Three Aspirations of the Alliance

Good user experience. The alliance aims for power‑saving, bandwidth‑saving, and minimally intrusive notifications.

Co‑building a healthy ecosystem. By sharing resources, avoiding duplicate efforts, and encouraging industry self‑discipline, the alliance seeks a sustainable push ecosystem.

Information security and content controllability. All interfaces must be authenticated, use HTTP/2 and encryption, and push content must be traceable for rapid accountability.

Unifying Push Standards

Technically, the alliance proposes that apps only need to integrate a single unified SDK (UPSSDK – United Push Service SDK) to obtain push functionality.

The diagram below illustrates the proposed architecture:

Unified push technical architecture

The architecture defines four roles:

App & Push Backend: The app’s backend sends a message to the manufacturer’s push server (or via a third‑party provider) through a unified interface.

Manufacturer Push Service: Manufacturers run a UPS Server that receives messages from upstream app servers and forwards them to devices using the same standardized API, allowing limited interoperability between different UPS servers.

Device: The device firmware contains a USP‑Client that implements the UPS‑SDK interface, receives messages, and distributes them locally. Because the client is built into the firmware, a single push service can serve all apps, keeping the heartbeat at the system level and eliminating the need for app‑side keep‑alive, thus saving power.

App side: Developers only need to integrate the UPS‑SDK; they do not need to manage individual manufacturer channels. The app simply receives and processes messages.

The design follows these principles:

SDK is lightweight, defining only interfaces while hiding implementation on the service side.

Uniform interfaces mask underlying differences among manufacturers and third‑party providers.

Consistent basic behavior across platforms reduces maintenance costs.

Adoption of industry‑standard development technologies.

Flexibility and extensibility for future enhancements.

Although many technical details remain to be finalized, a test version of the unified push SDK is expected to be released to developers soon.

Thoughts on the Push Ecosystem

Whose interests does the alliance serve?

The ecosystem involves the government, device manufacturers, push service providers, and app developers, each with distinct interests. Balancing these interests is complex, but the fundamental baseline must be protecting users and ensuring a good push experience.

Building an ecosystem reinforcement loop

From a system‑dynamics perspective, users are a crucial stock in the ecosystem. More engaged users increase the overall commercial value, creating a positive feedback loop. To foster this loop, the alliance should focus on two product‑level standards:

User control. Currently, many Android ROMs enable notification permissions by default and hide the settings entry, making it hard for users to disable unwanted notifications. Providing clear permission prompts and easy access to settings empowers users.

Message layering. Not all notifications have equal importance. Allowing users to categorize or prioritize messages reduces notification overload. Some manufacturers and Android O have begun experimenting with layered notifications, a trend likely to expand.

Self‑regulation of the push ecosystem

What Should an Ordinary App Developer Do?

Be a self‑disciplined developer

Focus on delivering real value to users rather than chasing DAU metrics. Consider negative impact metrics such as notification opt‑out, app uninstall, and retention decline when evaluating push campaigns.

Build a "simple" push system

Since the unified standard is not yet live, developers can improve delivery rates without excessive complexity. Instead of maintaining device IDs for each channel, use the alias feature to map user IDs to push identifiers. Additionally, consider outsourcing push channel integration to providers that already aggregate multiple manufacturer channels, reducing integration effort for small‑to‑medium teams.

The Future of Push

Mobile internet is maturing, and push will evolve from a simple alert mechanism to a contextual, multi‑scenario assistant. Future push will stitch together various user journeys (e.g., travel itineraries) and become increasingly intelligent, leveraging AI for content analysis, user behavior prediction, and on‑device machine learning to personalize and prioritize notifications.

Although challenges remain in unifying China’s push ecosystem, standardization will ultimately benefit users, developers, and the industry as a whole.