Zomato Android
The Uninvited SDK Guest
A food delivery app was 30% slower to start than it needed to be. The culprit initialized itself automatically — without anyone asking it to.
The Incident
Zomato's Android team noticed their app was underperforming on mid-range Android devices — the dominant device tier in India, their primary market. A systematic startup audit revealed that SDKs were initializing themselves via ContentProviders during Application.onCreate(), before any app code ran. One was particularly egregious: it initialized regardless of whether the user had any intention of using it.
Evidence from the Scene
- Startup was 25–30% slower than internal targets, especially on ₹10,000–₹20,000 devices
- Android Profiler showed ContentProvider initialization completing before Application.onCreate()
- One SDK contributed ~6% of total startup time even for users who never used its feature
- Removing a single SDK from the manifest reduced startup by 6% in a local test
- Legacy SDKs from deprecated features were still initializing every launch
- The SDK in question initialized even when the user opened the app to reorder last night's dinner
The Suspects
2 of these are the real root causes. The others are plausible-sounding distractors.
Facebook SDK auto-initializing at every app start via ContentProvider — even for non-Facebook users
Legacy SDKs for deprecated features still initializing on every launch
No Baseline Profiles — JIT compilation adding overhead to every new install
Deep XML layout hierarchies in the home screen causing slow inflation
SharedPreferences loaded synchronously on the main thread before home screen rendered
The Verdict
Real Root Causes
Facebook SDK auto-initializing at every app start via ContentProvider — even for non-Facebook users
The Facebook SDK registers a ContentProvider that triggers initialization before Application.onCreate(). For users who never use Facebook Login, this is pure waste. Disabling auto-init and deferring it to the Facebook Login button tap saved 6% of startup time immediately.
Legacy SDKs for deprecated features still initializing on every launch
Auditing the full SDK manifest revealed libraries for features that had been removed from the app months ago. Their ContentProviders were still running on every launch. Removing them saved another ~20% of startup time.
Plausible But Wrong
No Baseline Profiles — JIT compilation adding overhead to every new install
Baseline Profiles were also added as part of the fix and provided additional improvement — but the dominant issue (25–30% of startup time) was the ContentProvider chain, not JIT compilation warmup.
Deep XML layout hierarchies in the home screen causing slow inflation
Layout inflation overhead contributes to startup, but the profiler trace pointed to ContentProvider initialization as the primary bottleneck — these run before layouts are even considered.
SharedPreferences loaded synchronously on the main thread before home screen rendered
SharedPreferences main-thread reads are a real issue (StrictMode violation) but a secondary contributor. The SDK ContentProvider chain was the dominant startup cost.
Summary
Zomato's startup problem was SDK sprawl: libraries initializing themselves automatically via ContentProviders, including Facebook SDK running for every user regardless of intent. The fix required a systematic SDK audit, disabling Facebook SDK auto-init, and removing dead SDK code. Combined with Baseline Profiles for AOT compilation, Zomato achieved 25% startup improvement on average and 30%+ on the mid-range devices their users actually own. The lesson: every SDK you add ships a ContentProvider that runs before your code does.
The Real Decision That Caused This
“Integrating SDKs without auditing their ContentProvider initialization cost and never removing deprecated SDKs when their features were retired.”
Lesson Hint
Chapter 7 (Platform & Performance) covers startup optimization and SDK initialization patterns. Chapter 2 (App Architecture) covers the App Startup library as a replacement for ContentProvider-based SDK init.
Want to test yourself before reading the verdict?
Open Interactive Case in Autopsy Lab