Android 6.0 Marshmallow entered public availability on October 5, 2015, when Google began releasing it for supported Nexus devices and to the Android Open Source Project. The version did not radically redraw Android after Lollipop. Instead, it changed three fundamentals that users encounter every day: when an app receives sensitive permissions, how the phone conserves power while idle, and how fingerprint hardware works with the operating system.
Google had announced the final Android 6.0 SDK in August and confirmed the public rollout in its September device-readiness post. That staged process matters historically: the APIs were final before the consumer release, giving developers time to adapt applications to behavior that could otherwise break familiar workflows.
How did runtime permissions change app privacy?
Before Marshmallow, a person generally reviewed a list of requested permissions while installing an app and accepted the package as a group. For apps targeting Android 6.0, sensitive permissions could instead be requested at runtime. A camera app could ask for camera access when the user tried to take a picture, providing context for the decision.
Users could also open settings and revoke permission groups later. That moved control beyond a single installation moment. The change did not mean every permission generated a dialog, nor did older apps immediately adopt the new model. Compatibility rules allowed software targeting earlier API levels to keep legacy behavior on Marshmallow, which reduced sudden breakage but slowed the transition.
Google called runtime permissions one of Android’s largest permission-model changes in its official developer guidance. Developers had to check access every time, handle denial gracefully and explain why a feature needed data instead of assuming permission was permanent.
What did Doze and App Standby do for battery life?
Doze detected when a device had been left unused and stationary for a period. The system then deferred portions of background CPU and network activity, allowing apps to work during scheduled maintenance windows. App Standby limited the background impact of applications a person had not used recently.
Both features addressed idle drain rather than making the processor or battery physically more efficient. A phone could spend hours on a desk while many apps requested network access, alarms or synchronization. Coordinating that work reduced how often the hardware had to wake.
There were trade-offs. A deferred background job could make information less fresh, so Android provided exceptions for genuinely urgent messages. Apps that abused high-priority delivery could undermine the system. Actual savings also depended on hardware, signal, installed software and usage; no platform feature could guarantee a specific number of extra hours for every owner.
| Marshmallow change | Earlier pattern | New user-facing idea |
|---|---|---|
| Runtime permissions | Accept sensitive permission groups at install time | Ask in context and allow later revocation |
| Doze | Apps could wake an idle device more freely | Batch and defer background work while the phone rests |
| App Standby | Rarely used apps could continue background activity | Limit idle impact of apps the user is not opening |
| Fingerprint API | Manufacturer-specific implementations | A common Android authentication interface |
Why did a standard fingerprint API matter?
Fingerprint readers existed on Android phones before Marshmallow, but software support varied by manufacturer. Android 6.0 added a platform fingerprint API so compatible sensors could authenticate through a common system interface. Developers could build an authorization flow without writing a separate integration for every vendor’s implementation.
The sensor was not simply a replacement for all passwords. Android tied fingerprint use to a secure screen lock and hardware requirements, and apps received an authentication result rather than a copy of the fingerprint image. Implementations still depended on the quality of the device’s sensor, secure hardware and vendor software.
The Nexus 5X and Nexus 6P demonstrated the feature through “Nexus Imprint.” They combined rear fingerprint readers with Android Pay support, making the new API visible in both unlocking and payments. Our companion history explains why the two 2015 Nexus phones also pushed USB-C.
What other changes arrived with Android 6.0?
Marshmallow included Now on Tap, which used the context of the current screen to offer related assistance after a long press of the Home button. It also introduced automatic backup for supported app data, adoptable storage options, Direct Share targets and improved text selection. USB Type-C support aligned with the new Nexus hardware.
Some of these ideas changed or disappeared. Now on Tap was an important step toward system-level assistance, but it is not the interface people use on current Android phones. Adoptable storage was not enabled by every manufacturer. Direct Share evolved over later releases. Historical importance does not require a feature to remain unchanged; experiments can reveal what users and developers find valuable.
The final SDK announcement also shows how support libraries helped developers use new APIs while maintaining compatibility with older devices. Android’s active installed base never moved to a new version all at once.
Did every app and phone adopt the new rules immediately?
No. Runtime permission behavior depended partly on an app’s target API level. Developers needed to update and test their software, while users could still encounter an older app designed around install-time access. Google Play later raised target-API requirements, gradually making newer security behavior harder to avoid.
Phone updates followed the familiar Android chain of chipset support, manufacturer integration, testing and sometimes carrier certification. Nexus devices moved first; other models arrived on different schedules or remained on older versions. Doze behavior and fingerprint availability also depended on hardware and vendor implementation.
This is why an Android feature’s release date and its ecosystem adoption date are different facts. October 2015 marks platform availability, not instant global replacement of Lollipop.
Why does Marshmallow still matter today?
Current Android permission controls are much more detailed, including one-time access, while-in-use location and notification permission. Modern power management is also more sophisticated, and biometric authentication supports more methods. Marshmallow matters because it established the recognizable direction: sensitive access should be contextual and reversible, the system should restrain background work, and identity hardware should use a consistent platform interface.
Those principles make better everyday questions than a version-number trivia test. Does an app work after permission denial? Can a user understand why access is requested? Does background activity respect battery life? Is biometric data protected by appropriate hardware and fallback authentication?
Android 6.0 is now obsolete and unsafe as a current daily platform. In the Android history timeline, however, Marshmallow marks the point where Android put more practical control into the user’s hands without requiring that person to understand every internal process.
