Common Mistakes Beginners Make in Android Development

Every Android developer has shipped at least one of these: a screen that loses its data on rotation, a crash that only happens on slow networks, an API key committed to GitHub. They're not signs that you're bad at Android. They're the platform's sharp edges, and everyone cuts themselves once.

This article collects the most common beginner mistakes, grouped by area. Each one has a symptom so you can recognise it, a cause, and a fix with Kotlin code.

Threading mistakes

1. Doing slow work on the main thread

Symptom: frozen UI, "App isn't responding" dialogs, NetworkOnMainThreadException. Cause: network, database or file work on the UI thread. Fix: use coroutines with main-safe APIs (Retrofit and Room suspend functions), and withContext(Dispatchers.IO) for your own blocking code.

fun load() = viewModelScope.launch {
    val articles = repository.fetchArticles()     // suspend + main-safe
    _uiState.update { it.copy(articles = articles) }
}

2. Using GlobalScope or unmanaged threads

Symptom: work continues after the user leaves, crashes when updating destroyed UI, leaks. Fix: launch in viewModelScope or lifecycleScope so work is cancelled automatically. See Coroutines and Flow Explained.

Lifecycle and state mistakes

3. Losing state on rotation

Symptom: typed text or loaded data disappears when the screen rotates or dark mode toggles. Cause: state stored in the Activity or in plain remember. Fix: screen state in a ViewModel, and UI-element state in rememberSaveable.

4. Ignoring process death

Symptom: after the app has been in the background for a while, it returns with an empty or broken screen. Fix: persist critical in-progress input with SavedStateHandle, and test with Don't keep activities. See How an Android App Works Internally.

5. Holding a Context or View in a ViewModel or singleton

Symptom: memory leaks, and LeakCanary warnings about destroyed Activities. Fix: never store Activity contexts in long-lived objects. Use the application context if you really need one.

// ❌ Leaks the Activity after rotation
class ProfileViewModel(private val activity: Activity) : ViewModel()

// ✅ Depend on what you need, not on the Activity
class ProfileViewModel(private val repository: ProfileRepository) : ViewModel()

Architecture mistakes

6. Putting logic in composables or Activities

Symptom: screens that are hard to test and change, and duplicated logic. Fix: keep composables focused on rendering state and emitting events. Validation, formatting rules and data loading belong in the ViewModel or below.

7. Exposing mutable state

private val _uiState = MutableStateFlow(UiState())
val uiState: StateFlow<UiState> = _uiState.asStateFlow()   // UI can read, not write

8. Over-engineering too early

Symptom: five modules and twenty interfaces for a two-screen app. Fix: start with ViewModel + repository, and add structure when real complexity appears. See Clean Architecture: Practical Lessons.

Data and error-handling mistakes

9. Coding only the happy path

Symptom: crashes or infinite spinners on slow or offline networks. Fix: model loading, empty, error and success explicitly, and offer retry.

sealed interface ArticlesUiState {
    data object Loading : ArticlesUiState
    data object Empty : ArticlesUiState
    data class Success(val items: List<Article>) : ArticlesUiState
    data class Error(val message: String) : ArticlesUiState
}

10. Using !! to silence the compiler

Symptom: NullPointerException crashes. Fix: handle nullability with ?., ?:, early returns, or better types. See Kotlin Null Safety Explained.

11. Using Double for money

Fix: use BigDecimal or integer minor units (paise or cents) for currency.

Security and quality mistakes

12. Hard-coding API keys and secrets

Symptom: keys leaked on GitHub or extracted from the APK, and unexpected bills. Fix: keep secrets on a server. Restrict any keys that must ship in the app. See Secure API Keys in Android Apps.

13. Hard-coding text and sizes

Fix: put user-facing text in strings.xml (via stringResource) for translation, use sp for text and dp for sizes, and test with large font scale.

14. Ignoring accessibility

Fix: give icons content descriptions, keep touch targets at least 48dp, ensure contrast, and try TalkBack once on every new screen.

IconButton(onClick = onDelete) {
    Icon(Icons.Default.Delete, contentDescription = stringResource(R.string.delete_note))
}

15. Skipping version control and tests

Fix: commit small changes often, and write unit tests for ViewModels and pure logic first. They're cheap and catch regressions immediately.

A quick self-review checklist

• ☐ No network, database or file work on the main thread
• ☐ All coroutines launched in a lifecycle-aware scope
• ☐ Screen survives rotation and process death
• ☐ No Activity, View or Context stored in a ViewModel
• ☐ Every data screen has loading, empty and error states
• ☐ No !! without a comment explaining why it's safe
• ☐ No secrets in source code
• ☐ Strings in resources; icons have content descriptions

Frequently asked questions

Conclusion

Beginner mistakes in Android follow predictable patterns: blocking the main thread, ignoring lifecycle and process death, putting logic in the UI, coding only the happy path, and leaking secrets. Each has a well-established fix, and once you've internalised them your apps become dramatically more reliable.

Next step: run the checklist against your current project, then deepen your Kotlin with Kotlin Basics Every Android Developer Should Know.