Android’s Activity Lifecycle (Part 1): Why (“new”) Developers Have Trust Issues With It.
Table of Contents
1. The Brutal Truth About Lifecycle Crashes
2. My Personal Trauma: The Sony Ericsson X10 Incident
3. What Actually Is an Activity
4. The 7 Stages of Lifecycle Grief
5. Why Your App Keeps Dying (And It’s Not Just Bad Code)
6. Coming Next: Deeper Into the Rabbit Hole
1. The Brutal Truth About Lifecycles Crashes
Why does my app crash when I rotate the screen?
Why does my MediaPlayer randomly stop or crash when i leave the screen?
Why does my Text lose its content when I rotate the phone?
Every Android developer, at least once (probably more like 47 times)…
Let’s start with some uncomfortable truths. According to multiple industry research reports approximately 30–40% of Android app crashes/ losing data are directly related to improper Activity lifecycle management [1]. Nope! That’s not a typo. Nearly half of your crashes could be prevented by understanding how Android actually works under the hood. Let’s talk about it
(personal note):
The most painful part of the Lifecycle: These “crashes” usually happen right when the users are doing something important:
- Filling out a long form (rotation = data gone)
- Playing a game at their highes score (process death = progress lost)
- Recoding a video (memory pressure = recording stopped)
- Making an in-app purchase (activity destroyed = payment confusion)
If you’ve never experienced the cold swear of realizing your app just ate someone’s carefully typed essay because you forget to handle onSaveInstanceState() then congratulations — i guess you are a lifecycle wizard!
2. My Personal Trauma: The Sony Ericsson X10 Mini Pro “Incident”
Time for some therapy through storytelling
Picture this: It’s 2010. The iPhone 4 just came out, but i was Team Android with my shiny Sony Ericsson X10 mini pro. The beast had a physical slide-out keyboard the pinnacle of mobile technology, or so I thought.
Sony Ericsson X10 Mini Pro
The X10 ran Android 1.6 (Donut) [2], back when Activities were basically digital Wild West. No proper lifecycle guidance, no ViewModel, no saved sate API’s. Just raw, unforgiven Android that would destroy you Activity faster than you could say “configuration change.”
Here is what happen:
1. I’d spend 10 minutes typing a detailed text message
2. Slide out the keyboard to fix a typo
3. Screen rotates to landscape
4. BOOM! Activity destroyed, message gone
5. Stare at empty text field in disbelief
6. Question life choices…
This wasn’t just user frustration — it was an early lesson in how Android’s process management actually works .
The OS doesn’t care about your carefully crafted text. When configuration changes happen, Activities get nuked and recreated. No exceptions, no mercy.
The Sony X10 taught me that Android is fundamentally different from desktop applications. Your app is not in control. The system is. And if you don’t play by the system’s rule, your users will suffer.
3. What Actually Is An Activity?
The Textbook definition
According to Google’s official documentation, an Activity is “a single, focused thing that the user can do” [3]. Helpful right? About as clear as saying a car is “a thing with wheels that moves”
More technically: An Activity represents one screen in your app like a login page, settings screen, or photo viewer. Each Activity is a Java/Kotlin class that extends the Activity base class and manages its own UI lifecycle
Activities are not just “screens”— they’re complex state machines that can exist in multiple states simultaneously. An Activity can be:
- Created but not visible
- Visible but not interactive
- Interactive but partially obscured
- Destroyed but still in memory
- “Dead” bit somehow still causing memory leaks
Now let’s illustrate it with a “Mental Model”
Mental Model:
Think of an Activity like a restaurant table
- The table exists even when no one’s sitting at it (Created)
- Customers can see the table but might not be seated yet (Started)
- Customers are actively eating and interacting (Resumed)
- Customers step away but their food is still there (Paused)
- Customers leave but the table isn’t cleaned yet (Stopped)
- The table gets cleaned and reset for new customers (Destroyed)
The key insight: The restaurant (Android system) manages the tables, not the customers (your app). You don’t get to decide when your table gets cleaned — you just have to be ready for it.
4. The 7 Stages of Lifecycle Grief
Every developer fosters through these phases. It’s basically a rite of passage.
Stage 1: Denial
“My app doesn't need to handle configuration changes. Who rotates their phone anyway?”
News flash: Users rotate their phones. Studies show that 60% of users regularly switch between portrait and landscape [4] [5] when using apps. Your denial won’t save you.
Stage 2: Anger
“Why does Android destroy my Activity for EVERYTHING? This is stupid!”
Android destroys Activities for good reasons:
- Memory pressure: Other apps need RAM
- Configuration changes: Screen size, orientation, local changes
- Process death: System needs resources for critical tasks
- User navigation: back button, task switching
It’s not personal. It’s resource management.
Stage 3: Bargaining
“Maybe if I just put everything in onCreate(), it’ll work fine…”
No. Stop. Don’t do this. You’ll create cold start performance issues and your users will uninstall your app faster than you can say “ANR” [6].
Stage 4: Depression
“I’ll never understand this. Maybe I should become a web developer.”
We’ve all been there. The good news: Once you get it, you really get it. And then you’ll wonder how you ever lived without proper lifecycle management.
Stage 5: Testing
“Let me just rotate the phone 47 times to see what breaks…”
Finally! You’re starting to think like the Android system. Pro tip: Use the developer options “Don’t keep activities” setting to simulate memory pressure [7].
Get Felix Boudnik’s stories in your inbox
Join Medium for free to get updates from this writer.
Stage 6: Understanding
“Oh, I see. The lifecycle is actually protecting users from bad experiences.”
Exactly! The lifecycle ensures:
- Battery efficiency: Paused apps use less power
- Memory optimization: Stopped apps can be cleaned up
- Responsive UI: Active apps get priority
- State preservation: Proper state saving prevents data loss
Stage 7: Acceptance (and Expertise)
“I am one with the lifecycle. The lifecycle is one with me.”
Congratulations! You now understand that fighting the lifecycle is futile. Embracing it leads to better apps, happier users, and fewer 2 AM debugging sessions.
5. Why your App Keeps Dying (And Its Not Just Bad Code)
The Android Memory Model
Android run on devices with limited RAM. Even flagship phones need to balance dozens of apps competing for resources (especially in a world with local LLMs). The system uses a Low Memory Killer that ruthlessly terminates processed based on priority
- Foreground apps (currently visible) = Highes priority
- Background apps (recently used) = Medium priority
- Cached apps (not recently used) = Lowest priority
- Empty processes = First to die
Your beautifully crafted Activity can be murdered by the system at any moment if memory gets tight. This isn’t a bug — it’s a feature that keeps the overall system responsive.
Configuration Changes: The silent App Killer (Simple)
When users rotate their device, change language, or connect/disconnect a keyboard, Android considers this a configuration change. The default behavior? Destroy the current Activity and create a new one with the updated configuration [8].
Why? Because your layouts, resources, and UI might need to completely change:
- Portrait vs landscape layouts
- Different screen densities
- locale-specific resources
- Keyboard availability
The nuclear option (destroy + recreate) ensures your app properly adapts to the new configuration. The downside? All your runtime data gets vaporized unless you explicitly save it.
The Process Death: Example
- User opens your app
- User fills out a complex onboarding form
- User switches to another app (your app goes to background)
- Systems run low on memory (assume it happens)
- Your entire process gets killed (not just paused — completely terminated)
- User returns to your app
- Android recreates your Activity from scratch
- User expects their form data still be there …
6 Coming Next: Deeper Into the Rabbit Hole
Part 2: The Seven Horsemen of the Lifecycle
”onCreate(), onStart(), onResume() — A Developer’s Guide to Not Going Insane”
Final Thoughts
*The Activity Lifecycle isn’t your enemy — it’s Android’s way of ensuring your app plays nicely with others.*
Mastering the lifecycle means:
- Fewer crashes(your Crashlytics dashboard will thank you)
- Better performance (proper resource management)
- Happier users(seamless experience across device changes)
- Less debugging (fewer 2 AM “why is this broken?” sessions)
The brutal truth? Every Android developer must eventually face the lifecycle. You can ignore it early in your career, but eventually, it will catch up to you in the form of production crashes, angry users, and that sinking feeling when you realize your app just lost someone’s important data.
Better to learn it properly now than to learn it the hard way later.
What’s your most embarrassing lifecycle-related bug? Drop a comment below and let’s commiserate together. We’ve all been there.
— -
Part 2
Here is Part 2, where we’ll get our hands dirty with actual code and fix these issues like the professionals we pretend to be!
— -
Ressources
[1] Large-Scale Analysis of Framework-Specific Exceptions in Android Apps
(https://arxiv.org/abs/1801.07009)
[2] Sony Ericsson Xperia X10 min pro
(https://www.amazon.de/Sony-Ericsson-Smartphone-QWERTZ-Tastatur-Megapixel-Schwarz/dp/B003GCAZUO)
[3] Android Activity Documentation
(https://developer.android.com/reference/android/app/Activity)
[4] Upright or sideways?: analysis of smartphone postures in the wild
(https://www.researchgate.net/publication/261403548_Upright_or_sideways_analysis_of_smartphone_postures_in_the_wild)
[5] Mobile Web: Scale Product Images Proportionally in Mobile Landscape Mode
(https://baymard.com/blog/scale-mobile-product-images-in-landscape)
[6] Android Performance Best Practices
(https://developer.android.com/topic/performance)
[7] Android Developer Options Guide
(https://developer.android.com/studio/debug/dev-options)
[8] Configuration Changes Handling
(https://developer.android.com/guide/topics/resources/runtime-changes)
Thanks for Reading!
Thank you for taking the time to read through my lifecycle blog! I hope you found it helpful (and at least mildly entertaining). If this saved you from a future crash or gave you a good laugh, I’d love to hear about it.
Feel free to check out my linktr.ee to find out more about me, or if you’d like to support my writing, I’d really appreciate it!
Best,
Felix
