Forking Android: Challenges and Tradeoffs

The contemporary mobile device market is characterized by a fundamental misalignment between the psychological well-being of the consumer and the revenue imperatives of the dominant platform providers. While there is a documented and increasing demand for "non-addictive" or "minimalist" hardware, the path for a startup to deliver such a product at scale is obstructed by a sophisticated architecture of legal, technical, and economic barriers. This report analyzes the structural mechanisms that reinforce the status quo of high-engagement device design and evaluates the trade-offs necessitated by those attempting to subvert this paradigm.

The current smartphone economy has transitioned from a hardware-centric growth model to one defined by "Service-as-the- Product." For dominant actors like Google and Apple, the physical device serves as a loss leader or a high-margin gateway for a perpetual stream of software-derived revenue. In the case of Apple, growth is increasingly tied to a 15–30% commission on digital purchases — often within addictive, microtransaction-heavy gaming ecosystems — and a massive $20 billion annual payment from Google to maintain search defaults. For Google, the Android operating system exists primarily to expand the global pool of users contributing to the 77% of its revenue generated by search advertising and YouTube consumption. Within this framework, any device modification that reduces user engagement is not merely a design choice; it is a direct attack on the primary revenue engine of the platform provider.

The Contractual Architecture of Compliance

The primary mechanism through which the Android ecosystem is kept "engagement-aligned" is the complex web of contractual agreements mandated by Google for any original equipment manufacturer (OEM) seeking commercial viability. While the Android Open Source Project (AOSP) remains technically open, the layers of proprietary services on top are controlled through a hierarchy of agreements that discourage or outright prevent the distribution of alternative, minimalist OS forks.

The Mobile Application Distribution Agreement (MADA)

The MADA is the central legal instrument for GMS (Google Mobile Services) licensing. Under the terms of the MADA, Google requires OEMs to accept the entire suite of Google applications as a non-divisible bundle. A manufacturer cannot choose to include only the Play Store to provide essential utility apps like banking while stripping out engagement-driving apps like YouTube or Chrome.

Section 2.7 of the historical MADA makes the license to distribute these applications contingent upon the device passing the Android Compatibility Test Suite (CTS) and conforming to the Android Compatibility Definition Document (CDD). This ensures that any "minimalist" adjustments to the OS do not break the standard API behaviors that Google relies on for data collection and advertising delivery. Furthermore, Section 4.3 grants Google final oversight over every device and telecom operator launch, creating a de facto veto over hardware/software combinations that might diverge too far from the standard engagement model.

Anti-Fragmentation and the Android Compatibility Commitment (ACC)

The most significant barrier for a startup attempting to build a "better" Android is the Anti-Fragmentation Agreement (AFA), now evolved into the Android Compatibility Commitment (ACC). This agreement mandates that any OEM signing it must ensure its entire portfolio of devices remains "compatible." If a manufacturer like Sony or LG were to experiment with a radically non-addictive fork of Android on one niche model, they would risk losing their GMS license for their entire product line. This "Single and Continuous Infringement" logic, as identified by the European Commission, effectively traps established brands in a cycle of high-engagement design.

Technical Moats and the Dependency on Google Play Services

Beyond the legal barriers lies a technical moat of proprietary background services. Google Play Services is not an application but a persistent system layer that handles critical functionality for the vast majority of third-party Android apps. This layer is closed-source, making it difficult for minimalist forks to replicate essential utilities without compromising their de-Googled principles.

The Firebase Gravity Well

Modern app development is heavily reliant on Firebase, specifically Firebase Cloud Messaging (FCM), for push notifications. FCM requires Google Play Services to function because Play Services is the only process permitted by the OS to maintain a persistent background connection to the cloud. When a minimalist fork like GrapheneOS or LineageOS removes Play Services, they often break the notification systems for banking, communication, and utility apps.

Startups have attempted to use alternatives like UnifiedPush or Gotify, which allow for decentralized notifications without a single company's oversight. However, these alternatives require app developers to specifically implement them, which rarely occurs for large-scale commercial applications. This forces minimalist phone users into a binary choice: accept the privacy and engagement compromises of GMS, or accept a device that cannot receive real-time updates from essential services.

The Technical Debt of MicroG

MicroG represents the primary effort to bridge this gap by providing a free-software reimplementation of Google's proprietary APIs. While MicroG allows many GMS-dependent apps to run on de-Googled forks, it introduces significant technical debt. Because Google frequently updates its APIs, the MicroG project must engage in constant reverse-engineering to maintain compatibility. In early 2026, reports emerged of numerous Play Store apps failing on MicroG-equipped devices due to new, unmapped dependencies in the GMS core, illustrating the fragility of this approach.

The Security Wall: Play Integrity and the Foreclosure of Trust

A critical challenge for any startup developing a non-standard OS is the shift toward hardware-backed attestation. The Play Integrity API (formerly SafetyNet) is the mechanism through which apps verify that the device environment has not been tampered with.

Hardware-Backed Attestation (TEE)

Modern Android security relies on a Trusted Execution Environment (TEE), such as the Titan M or KeyMint chips. These chips are physically isolated from the main OS and can cryptographically sign a verdict regarding the device's state. High-fidelity apps, such as those for banking, government ID, and enterprise VPNs, often require a MEETS_STRONG_INTEGRITY verdict, which signifies that the device has a locked bootloader and is running a Google-certified OS.

For a minimalist fork, this creates an existential hurdle. Because these forks are often installed on devices with unlocked bootloaders to allow for system-level modifications (like grayscale or engagement limits), they cannot pass strong integrity checks. This leads to the "Certified vs. Secure" paradox: GrapheneOS may be more secure than a stock OS, but because it is not certified by Google, banking apps will refuse to run on it, labeling it a security risk.

The Spoofing Arms Race

To counteract this, many custom ROMs and minimalist OS providers utilize "PIF" (Play Integrity Fix) modules that spoof device identity. This involves making a modern, hardened device masquerade as a legacy certified model (like a 2015 Nexus 6P) that Google must still support via weaker, software-backed attestation. However, this is a "whack-a-mole" strategy. Google frequently revokes the leaked keyboxes used for this spoofing, resulting in banking apps suddenly failing for thousands of users simultaneously.

Communication Standards and the RCS Monopoly

The ambition to build a phone that "helps people live their lives offline" is further complicated by the evolution of messaging standards. While SMS is an open, albeit insecure, standard, the industry's shift to Rich Communication Services (RCS) has been gatekept by Google's Jibe Cloud infrastructure.

The Proprietary Nature of "Open" RCS

Although RCS is touted as a GSMA carrier standard, Google has never published the public APIs required for third-party developers to implement it. This means that for a startup to offer a minimalist messaging experience that includes modern features (read receipts, high-res photos, group chats), they must bundle the Google Messages app and the "Carrier Services" binary blob.

Carriers are often incentivized to use Google's Jibe Cloud rather than building their own RCS infrastructure due to the high costs of self-hosting. In some regions, carriers have even shut down RCS because they believe free IP messaging cannibalizes SMS revenue. For the minimalist phone manufacturer, this means their primary communication tool is either an outdated SMS client or a Google-controlled portal that brings with it the very data-tracking and engagement features they aim to avoid.

The Physical and Economic Constraints of Minimalist Hardware

The essay provided by the user asks why "slipping" brands like LG or Sony do not try making a minimalist phone. The answer lies in the harsh economics of smartphone manufacturing and the loss of the "Attention Subsidy."

The Loss of RSA Subsidies

Established OEMs like Samsung operate on razor-thin margins (~5–10%). These margins are made viable by Revenue Sharing Agreements (RSAs) with Google, which can pay billions of dollars to ensure search and app store dominance. A startup selling a phone that actively reduces search volume and discourages app store spending receives zero RSA revenue.

Consequently, the hardware must be priced high enough to cover the entire cost of development, manufacturing, and long-term software support. This is why devices like the Light Phone III or Fairphone 6 appear "overpriced" compared to mass-market flagships with superior specs; the mass-market phones are essentially subsidized by the user's data and attention.

Manufacturing Costs and the Memory Crisis

The cost structure of a smartphone is heavily weighted toward its components, specifically memory and displays. For a mid-range device, memory can represent up to 20% of the Bill of Materials (BOM). In periods of global memory shortage, as seen in the 2026 market analysis, average selling prices (ASPs) for phones can rise by up to 8%.

Small OEMs lack the volume to negotiate the favorable pricing or low Minimum Order Quantities (MOQs) that giants like Apple or Samsung command. While a major manufacturer can order millions of OLED panels, a startup may face MOQs of 5,000 to 10,000 units for custom parts, forcing them to use expensive, off-the-shelf components that may not perfectly serve their minimalist design goals.

Case Studies in Minimalist Deviation

The trade-offs forced upon startups can be seen in the trajectories of the most prominent players in the "minimalist" and "fair" phone space.

Fairphone: The Cost of Ethical Longevity

Fairphone's mission is focused on sustainability and repairability, but their struggle to maintain a custom software stack is a blueprint for the challenges facing minimalist startups. To offer 5–7 years of software support, Fairphone must often bypass the SoC manufacturer (Qualcomm), who typically only supports chips for 2–3 years. Developing Android updates independently of the chip vendor is an enormous engineering burden that results in a less "polished" experience, with users reporting persistent bugs in background app management and camera performance.

The Light Phone: From E-ink to OLED

The Light Phone II represented the purest expression of digital minimalism, using an E-ink screen to provide a "calm" interface. However, the physical limitations of E-ink — specifically slow refresh rates — made essential tasks like texting and using directions "frustrating" and "glitchy."

For the Light Phone III, the company compromised by switching to a matte OLED display. While this improved performance and usability, it highlights the technical gravity of the modern smartphone standard; to make a device "livable" in 2026, the manufacturer had to move closer to the very emissive, high-refresh technology they initially rejected.

Punkt and Mudita: The Reliability Gap

Boutique "dumbphones" like the Punkt MP02 and Mudita Pure often suffer from a lack of technical depth. The Punkt MP02 relies on the Signal protocol (via the Pigeon app) for encrypted messaging, but users report frequent outages and a "non-intuitive" interface that requires a 56-page manual. Mudita Pure faced severe criticism for "uncooked" software and hardware that struggled with basic signal reception. These failures underscore that "simple" phones are not simple to build; they require the same level of rigorous engineering as a flagship, but without the revenue to support it.

Psychological Interventions: The Efficacy of Grayscale and Friction

Given the structural difficulty of building a minimalist phone, some developers pursue software-only interventions like minimalist launchers or system-wide grayscale.

The Neurological Impact of Color

App designers leverage color psychology to trigger dopamine releases; bright, saturated colors stimulate excitement and create an addictive reward cycle. Scientific studies have confirmed that switching a phone to grayscale makes interactions "less visually gratifying," reducing both time spent scrolling and the anxiety associated with screen time.

Quantitative Reductions in Screen Time

Research on undergraduate students indicates that grayscale mode can reduce screen time by an average of 38 minutes per day. However, there is a catch: while usage duration drops, the frequency of phone "unlocks" often remains unchanged. This suggests that the habitual impulse to check the device is deeply ingrained, even if the gratification of the experience is reduced. For a minimalist phone to be truly effective, it must address the "unlock" trigger, which is often tied to notifications — a system, as previously noted, controlled by Google Play Services.

Regulatory Intervention: The Digital Markets Act (DMA)

The European Union's Digital Markets Act (DMA) represents a significant regulatory attempt to break the gatekeeper dominance of Google and Apple. Under the DMA, users must be able to download apps from alternative stores and select default services through "choice screens."

The Failure of Sideloading to Shift Behavior

Despite the legal ability to "sideload" apps or use alternative stores, consumer behavior has remained largely unchanged. Reliance on Google, Meta, and Apple remains strong due to powerful network effects and ingrained habits. Furthermore, some report that the DMA has degraded the user experience by adding "friction" and "additional steps" to common tasks without providing meaningful alternatives that offer equivalent value.

Revenue Losses and Market Fragmentation

Economic studies suggest that the DMA's restrictions on data combination have caused annual revenue losses of up to €114 billion for EU businesses. For a minimalist startup, the DMA provides a more contestable legal environment, but it does not solve the fundamental problem: an alternative app store that doesn't have the "network-effect benefits" of the Play Store will struggle to attract both users and developers.

Synthesis: The Feasibility of a Non-Addictive Future

The recurring question posed by the context essay — why a company doesn't build a phone that gives you "30 hours a week back" — is answered by the totality of these systems. To build such a phone is to step outside an economic system where the device is a vehicle for $20 billion search deals and 30% digital "taxes."

The Strategy for a Minimalist Startup

A developer of an open-source Android fork wishing to pursue minimalism faces a tiered progression of challenges:

1. UI/UX Layer: Implementing grayscale and minimalist launchers. This is technically easy but only addresses the "gratification" side of addiction, not the "trigger" (notification) side.
2. OS/System Layer: Modifying background processes to reduce data collection and engagement. This triggers the loss of Google "Compatibility" and the Play Store.
3. Communication Layer: Implementing RCS and modern messaging. This hits the "Proprietary Wall" of Google's Jibe Cloud.
4. Hardware Layer: Designing ethical, repairable, or minimalist hardware. This faces the "Scale Barrier" of high BOM costs and the lack of RSA subsidies.

Final Conclusions

The "less addictive phone" is technically possible but economically and legally obstructed within the current Android ecosystem. Startups like Fairphone and Light Phone are not just hardware companies; they are "economic dissidents" fighting a system where every incentive — from the chip manufacturer to the carrier to the OS provider — is aligned toward maximizing user attention.

For the "slipping" brands like Sony or OnePlus, the risk of "rocking the boat" is too high because their businesses are intertwined with the very companies (Google and Qualcomm) that enforce the status quo. The future of the minimalist phone likely depends on regulatory efforts like the DMA succeeding in decoupling hardware from search / store monopolies, or the emergence of a "UnifiedAttestation" standard that allows for secure, non-Google devices to participate in the modern app economy without compromising their soul. Until such a paradigm shift occurs, digital minimalism will remain a premium, niche experience for a subset of users willing to pay more for a device that does less.

Appendix: Compatibility, CTS, and the Limits of UI Overlays

Follow-up conversation with Gemini, kept here because it grounds the "what can an OEM actually ship" question in specific contractual and test-suite mechanics.

The core tension in building a "less addictive" device within the official Android ecosystem is that Google's legal and technical frameworks are designed to ensure a consistent, high-fidelity environment for third-party apps and advertisers.

When a manufacturer signs the Mobile Application Distribution Agreement (MADA) and the Android Compatibility Commitment (ACC), they are not just agreeing to include Google apps; they are agreeing to a "Single and Continuous Infringement" policy. This means if they release one "non-compatible" device anywhere in the world, they risk losing their Google Mobile Services (GMS) license for their entire product line.

1. Examples of devices and configurations "outside" the agreements

Devices that fall outside these agreements generally fall into two categories: non-compatible forks (which ignore Google's rules) and de-Googled ROMs (which are community-driven rather than OEM-driven).

• Amazon Fire OS (Fire Phone / Tablets): The most famous "non-compatible" fork. Amazon uses the Android Open Source Project (AOSP) but does not pass Google's Compatibility Test Suite (CTS) or license GMS. Consequently, Fire devices lack the Play Store and rely on the Amazon Appstore.
• Post-2019 Huawei devices: Due to US sanctions, newer Huawei phones (P40, Mate 60 series) are forced outside the GMS ecosystem. They use AOSP with Huawei Mobile Services (HMS) and their own AppGallery.
• Privacy-focused ROMs (GrapheneOS, LineageOS): Not "devices" in the commercial sense but OS configurations. GrapheneOS, for example, is "completely honest" with Google's APIs, reporting that it is not certified. This honesty causes them to fail Play Integrity checks, which is why banking apps often break on them.
• Niche "minimalist" hardware: The Light Phone II runs a heavily modified (forked) version of Android (LightOS) but does not attempt to pass CTS or include the Play Store. It focuses on a text-based UI and an E-ink screen, which would likely fail various CTS UI and video performance tests.

2. Is it mostly about removing YouTube / Play Store?

No. While the MADA is about the "all-or-nothing" bundle of apps (you cannot have the Play Store without also having YouTube, Search, and Chrome), the ACC/CDD is about behavioral and technical consistency.

Even if you wanted to keep YouTube but change how the OS behaves — for example, by forcing a "Zen Mode" that makes the phone unusable for 20 minutes — you must ensure the OS still follows the Compatibility Definition Document (CDD) rules. These rules ensure that when an app (a banking app, a game) requests a specific system behavior, the OS responds in a standardized way.

3. Components of the Android Compatibility Test Suite (CTS)

The CTS is a "test-harness" that ensures a device provides a consistent environment for developers. It consists of several parts:

• Automated Tests (CTS): Thousands of JUnit tests packaged as APKs that run on the device. They check signature tests (all public APIs present with correct signatures), platform API tests (core Java/Android framework behaves exactly as documented), and Dalvik/runtime tests (.dex format and VM instructions work correctly).
• CTS Verifier (manual): Covers functions that cannot be automated — touchscreen, accelerometer, camera. A human must verify, for instance, that a camera photo actually looks like the target pattern and isn't distorted.
• Camera ITS (Image Test Suite): A specialized subset of CTS that verifies camera functions like exposure, focus, and color accuracy.

4. Constraints on overlays (grayscale / blur / Zen Mode)

If you are an OEM (Sony, OnePlus) and you want to implement "gradual grayscale" or "blur" overlays to reduce salience, you run into three main obstacles.

The "visual integrity" moat. The CDD (Section 3.8) requires the UI to correctly render all resources provided by apps.

• Grayscale: Standard Android already includes a grayscale accessibility feature. Because this is a standard platform feature, using it as a user-toggleable mode is fully compatible.
• Persistent blur / distortion: If an OEM adds a persistent blur over third-party apps, it could fail CTS-Verifier checks where a human must confirm that the screen displays content accurately. If the blur makes an app's UI unreadable or prevents a QR code from being scanned, it violates the "UI compatibility" requirements of the CDD.

MADA Section 2.6: the "anti-restriction" clause. The MADA specifically forbids taking any action to "limit or restrict the Android platform." If an OEM implements an overlay that intentionally makes third-party apps (Facebook, YouTube) "worse" to use, Google can argue the manufacturer is actively restricting the platform's utility.

The "Zen Mode" precedent. OnePlus Zen Mode is a rare example of a "restrictive" feature that survived. It works by setting a time limit (e.g., 20 minutes) where almost all functions are locked, while maintaining "essential" access (emergency calls, camera) to remain compliant — and it is user-initiated, not a forced gradual degradation of OS quality, which Google would likely view as a violation of the SSNDQ (Small but Significant Non-Transitory Decrease in Quality) standard used by regulators to define platform abuse.