On Medium, @MindOrks published a 2020 Android Developer Learning Path. Given that some readers may have difficulty accessing the original content, I am sharing it here combined with my own 2020 learning plan for your reference.
The original article is quite simple, mostly listing knowledge points without much explanation. I have added brief introductions for each point and included some additional topics based on my own understanding. This is for your reference only.
This article is primarily for Android developers. If you are a beginner, it will help you find a learning path. If you are an experienced developer, it can help you identify gaps in your knowledge. If you have any other suggestions, feel free to leave a message.
Version note (reviewed 2026-10-13): The title and personal plan retain their 2020 context. Foundations remain useful; outdated tools, retired services, and learning links are updated below. New learners can start with Android Basics with Compose, build a small working and testable app, then add topics as needed. This is not a list of libraries every project must install.
A current path covers Kotlin, Compose/Material 3, lifecycle and state, Coroutines/Flow, a data layer, and testing. Maintaining existing projects still requires Java, View/XML, and Fragments. Check build tools, performance tooling, and distribution requirements against current versions rather than copying 2020 configuration.
Programming
Java
Java remains important for reading existing Android apps and Framework code, but should no longer be described as the default first choice for a new app. Android follows a Kotlin-first approach while continuing Java support; Framework code also includes Kotlin, C++, and other languages.
For those who want to dive deeper into the Java Virtual Machine, I recommend:
- Zhou Zhiming’s “Understanding the Java Virtual Machine (3rd Edition)”
- Deng Fanping’s “Understanding Android Java VM: ART”
Separate general Java/JVM concepts from ART implementation details. HotSpot collectors, flags, and tuning conclusions do not transfer directly to ART, and old source references need matching OS versions.
Kotlin
Focus on null safety, collections, generics, Java interoperability, and coroutine cancellation and exception propagation. IDE conversion assists migration but does not replace review of nullability and lifecycle behavior.
The previously recommended Converting to Kotlin Codelab is officially Deprecated. Keep it as a historical migration example; use the Compose course above and Android’s Kotlin documentation for current learning.
Flutter
As Google’s “favorite son,” Flutter receives significant official support. The version discussed here was v1.12.13+hotfix.7 in 2020, not a current release. Its commit record includes reportFullyDrawn API-level, Skia-extension, and text-affinity changes. The old hotfix discussion is historical context, not evidence of compatibility with every device today. The original Roadmap URL is a changing page, not a fixed 2020 snapshot.
The following retains my observations and plan from that time:
For the development of Flutter, you can refer to Gityuan’s Flutter Cross-Platform Evolution and Architecture. Currently, several Bytedance apps have integrated Flutter for hybrid development. Personally, I believe it’s no longer a time to wait and see on Flutter in 2020; readers can decide whether to start learning based on their own technical plans.
Updated entry point: At review time, the official stable-release notes include Flutter 3.47.0; check the SDK archive for patch versions. Learn Dart, widgets/state, platform integration, and DevTools. Dart 3 enforces sound null safety, so 1.x tutorials and dependencies cannot be copied unchanged. Flutter is an optional cross-platform direction rather than a requirement for every native Android project.
Android Studio
Android Studio IDE Overview
This was my experience in 2020:
As the default Android development tool, recent updates have resolved many performance issues. It still asks a lot of your hardware, but once you make peace with that, you may find yourself admitting: this is actually pretty great.
Key areas to master:
- AS Shortcuts
- AS Plugins
- AS Profiler: CPU, memory, and supported network/system-tracing capabilities. Not every version has a separate generic “I/O Profiler.”
- Layout Inspector, Compose debugging, Logcat, APK Analyzer, and emulators; entry points vary by Studio version.
Project Structure — Java/Kotlin/Flutter, XML, .gradle files
Understand source/resources, manifests, module boundaries, the Gradle Wrapper, build.gradle / build.gradle.kts, and version catalogs. Java/Kotlin and Flutter have different build layers; Gradle, AGP, Kotlin, and JDK versions are not interchangeable.
Android Basics
Core Components
These remain the component-model foundations; Compose does not replace them:
- Activity — lifecycle, tasks/back stack, configuration changes, and state restoration after process recreation.
- Service — a background component is not a background thread. Services normally run on their hosting process’s main thread; learn background-start and foreground-service restrictions too.
- Broadcast Receiver — registration, export/permission boundaries, and callback execution limits.
- Content Provider — data sharing, URI grants, and cross-process calls.
Intents
- Types of Intent - Implicit, Explicit
- Intent Filter
- Component exports, PendingIntent mutability, and permissions; learn verified Android App Links for web-to-app navigation.
Static User Interface
- View — Button, ImageView, TextView, EditText, and other widgets remain essential for maintenance and interoperability.
- ViewGroup — LinearLayout, RelativeLayout, and FrameLayout are common containers, not an exhaustive set.
- ConstraintLayout — useful for some complex constraints, not a universal replacement or default layout. Use the AndroidX reference.
- For new UI, learn Compose/Material 3, state hoisting, recomposition, View interoperability, accessibility, and resizable windows. Migration need not rewrite all existing screens at once.
Dynamic User Interface
- RecyclerView — recycling, DiffUtil, paging, and binding cost. Its capabilities do not guarantee better performance than ListView in every case. Learn LazyColumn/LazyRow for Compose.
- ViewPager — useful for old code. ViewPager2 1.1.0 is in maintenance mode for critical fixes; new Compose screens can use Pager.
- Spinner — a traditional selection widget; choose controls for the actual interaction and the corresponding Material approach in Compose.
CustomView
When default layouts don’t meet design requirements, you need to customize Views. Master the following:
- Canvas
- Bitmap
- Paint
Also study measurement, layout, touch handling, and accessibility semantics. Compose drawing/layout uses its own Canvas, Modifier, and lifecycle model rather than directly reusing View lifecycle assumptions.
UI Resources
Using resource files instead of hardcoding improves maintainability.
- Drawables
- Strings
- Styles
- Localization, plurals, dark themes, font scaling, and adaptive sizes; Compose still needs resources and themes.
Fragments
Many advocate for a Single Activity + Multiple Fragments architecture. Managing Fragments is an art in itself, and you’ll encounter various “gotchas” in practice.
- Fragment Lifecycle
- Fragment Manager
Distinguish the Fragment lifecycle from its View lifecycle when binding observers, coroutines, and ViewBinding. Single-activity architecture does not require Fragments; Compose screens can use their own navigation/back-stack approach.
Support User Interface
Common functional components:
- ProgressBar
- Dialogs
- Toast & Snackbar
Model loading, empty, failure, retry, and cancellation states. Unknown or not-yet-loaded data should not appear as zero.
Storage
App development inevitably involves file handling.
- SharedPreferences — maintain existing key/value storage; consider DataStore for new needs, without treating it as a relational database replacement.
- File Systems — distinguish private files, shared media, MediaStore, SAF, and Photo Picker. Scoped storage and permissions depend on OS/API and targetSdk; arbitrary external-path access is not a current default.
- Database — Room abstracts SQLite. Learn schemas, queries, transactions, migrations, and migration tests.
RoomDatabaseis its base class, not a separate database product.
Build
Gradle and AGP build most Android projects. Learn dependencies, variants, signing, and caching alongside Debug/Release. Channel packaging and bytecode manipulation are optional advanced topics.
- Gradle / AGP — the official release page at review time is AGP 9.4.0. Match Gradle, JDK, Studio, and SDK to its compatibility table rather than immediately upgrading every old project.
- Debug / Release Configuration — verify optimization, obfuscation, resources, and dependencies under the actual release setup.
- Multi-channel Packaging — distinguish product flavors, distribution channels, and backend environments; do not embed secrets in artifacts.
- ASM — understand bytecode and build APIs first. AGP 8.0 removed Transform API; choose Instrumentation/Artifacts replacements for the use case.
- Baseline Profiles / Startup Profiles — the former helps ART optimize execution; the latter shapes DEX layout at build time. They are distinct and need reproducible startup/interaction measurements.
Threading
Components normally execute on their hosting process’s main thread; a multi-process app can have multiple process main threads. Learn pools, communication, lifecycle, and cancellation rather than just starting workers.
- Threads
- Handler / Looper / Message / MessageQueue
- AIDL / Binder — remote synchronous calls can block callers; Binder does not remove thread-safety requirements.
- Coroutines / Flow — coroutines are not one thread each, and
suspenddoes not automatically move blocking work off the main thread. Learn dispatchers, structured concurrency, cancellation, and lifecycle-aware collection. - WorkManager — persistent scheduling, not a universal mechanism for long-running or exact-time work.
Debugging
These are some basic debugging tools you’ll reach for when problems come up. A few take more time to get comfortable with, and this is far from the whole list:
- Memory profiling — Studio Memory Profiler, heap dumps, and reference paths. MAT can still analyze compatible dumps, but does not cover all native/graphics memory.
- Logging — correlate threads, timestamps, and identifiers without exposing sensitive data. An absent log is not proof that an event never happened.
- System tracing — keep the Systrace series for old traces and mechanisms; learn Perfetto for newer captures. Tool migration does not invalidate every older analysis method.
- Exceptions / Error Handling — distinguish recoverable failures, uncaught exceptions, ANRs, and native crashes; catching every Throwable is not a substitute for fixing errors.
- Macrobenchmark, JankStats, and Android vitals — distinguish benchmark measurements, frame observations, and production aggregates rather than treating one metric as a complete assessment.
Memory Leak
Leaks include retained Java/Kotlin objects, native allocations, and unreleased resources. RSS growth alone is insufficient evidence, and Java leaks are not guaranteed to be easier than native ones.
- Detecting and Fixing Memory Leaks — learn LeakCanary, Matrix, and platform tools while checking their coverage.
- Context — longer-lived objects retaining short-lived Activities/Views are a common cause; Application Context is not a universal fix.
- Native Memory Leaks — allocation ownership, resource cleanup, and native profiling/detection require evidence beyond a Java heap dump.
3rd Party Libraries
Classic libraries save development time, but the old names need current selection criteria:
- Image Loading — Glide remains an option for View projects. Picasso is deprecated with no more public Maven Central releases planned; plan migration for existing use and evaluate options such as Coil for new projects.
- Dependency Injection — Dagger/Hilt; understand constructor injection first rather than forcing a full container into a small project.
- Networking — Retrofit/OkHttp. Fast Android Networking is a wrapper from the original route; inspect its dependencies and maintenance rather than making it a new-project default solely because it appeared here.
- Async — Coroutines/Flow is a common Kotlin path. RxJava projects still require subscription disposal and scheduling knowledge. RxJava 1.x/2.x are end-of-life; keep tutorials aligned with the major version, and do not treat a development branch’s future release plan as an already released stable version.
Data Formats
Common serialization formats:
- JSON — Gson is in maintenance mode and its authors advise against it as a default for new Android work. Check reflection, Kotlin nullability, and R8 rules. Evaluate code-generation-capable kotlinx.serialization or appropriate Moshi configuration, with migration tests rather than blind substitution.
- FlatBuffers — learn schemas and direct access where useful; not every data format needs to become binary.
- Protocol Buffers — learn field-number and compatibility rules. Serialization is not encryption.
Android Jetpack
Jetpack combines libraries, tools, and guidance rather than one framework to install wholesale. AndroidX releases are independent of the OS but retain their own minimum API and compatibility requirements. The old four-category list mixed platform APIs, libraries, and form factors:
- Foundation/UI — AppCompat, KTX, Compose/Material 3. With
minSdk >= 21, native multidex support means the old support library should not be added automatically. - State/data — Lifecycle, ViewModel, Flow/LiveData, Room, Paging, DataStore. Data Binding remains relevant to existing Views; Compose has its own state model.
- Navigation/background work — match navigation to the UI stack (Navigation 3 for Compose is one learning path), and select WorkManager or other mechanisms by workload.
- Media, notifications, and devices — learn Media3 for media and platform rules for notifications, permissions, and sharing. Auto, TV, and Wear OS are device scenarios rather than ordinary widgets. Study old Slices only for a relevant host or existing project, not as a requirement for every new app.
Architecture
Understand the common architectural patterns and choose what fits your project:
- MVVM — Model-View-ViewModel connects UI to a state holder through observable state.
- MVI — Model-View-Intent commonly turns user actions into state changes that render the UI. Intent here is an architectural concept, not necessarily Android’s component-messaging Intent.
- MVP — Model-View-Presenter, where the Presenter coordinates the View and data/business logic.
Focus on responsibilities, unidirectional data flow, state restoration, and testability using the Android architecture recommendations. Adding ViewModel alone does not complete an architecture.
Testing
- Local Unit Testing — verify logic, state, and data on the local JVM; ordinary local tests do not provide a real Android Framework environment.
- Instrumentation Testing — verify Android integration, databases, lifecycle, and UI on devices/emulators; these tests are not limited to clicking screens.
- Compose/View UI, configuration changes, process restoration, and accessibility. Measure performance separately with suitable benchmark conditions, not Debug-test timings presented as release performance.
Firebase
Back in 2020, my advice to developers in China was to take a quick look at Firebase even if they couldn’t use much of it—maybe one day that would change. For current projects, check product-specific device, network, SDK, and data-collection requirements. Do not generalize availability across all Firebase services.
- FCM — verify Google Play services and other device prerequisites, particularly on devices without GMS; it is not guaranteed delivery to every Android device.
- Crashlytics
- Analytics
- Remote Config
- App Indexing — Google Search App no longer uses its indexed local content. Learn Android App Links for web-to-app navigation and AppSearch separately for on-device search.
- Dynamic Links — Obsolete: the official shutdown date was 2025-08-25. Do not add it to new projects. Follow the migration guidance; App Links alone does not replace deferred post-install linking, short-link analytics, and attribution services.
Security
Encryption, decryption, and obfuscation are probably the parts you’ll encounter most often. User data comes first. Ignore that, and the EU will teach you a lesson.
- Encryption / Decryption — standard cryptography, Android Keystore, key management, and transport security. Static strings in client artifacts are not secret storage.
- ProGuard / R8 — R8 became the default with AGP 3.4. Shrinking, optimization, obfuscation, and keep rules are not encryption or substitutes for authentication and access control.
- Permissions, exported components, URI grants, WebView/deep-link input, and logging. Follow Android security guidance and verify the actual release configuration.
App Release
.keystore/ signing — certificates/private keys, backups, and update-signing continuity. With Play App Signing, the upload key can differ from the app signing key.- App Bundle — AAB is a publishing format, not a directly installable package. Generate/test the APK or split APKs delivered to devices.
- Play Store — the target API requirements checked here require ordinary phone/tablet new apps and updates to target Android 16/API 36 or higher from 2026-08-31. Wear/Automotive/TV/XR, existing-app availability, and approved extensions have separate rules. Recheck at release time.
- Multi-channel Packaging — learn it where distribution needs it. For native dependencies, also check ABIs, third-party
.sofiles, and 16 KB page-size compatibility introduced with Android 15. - Pluginization — optional, subject to platform/distribution constraints, not a prerequisite for release. Quality also includes crashes/ANRs, permissions/data declarations, device coverage, and rollback planning.
Keep Learning and Improving
If you want to keep growing as an Android developer, build your own technical strengths and give yourself a plan. The former helps you stay competitive; the latter gives you something specific to work toward. Uninstall Douyin, Weibo, Douyu, and those games for a while, and make a plan for 2020. Keep Learning and Improving! Let’s keep at it.
If time management is giving you trouble, this video is from someone I know and respect, sharing their approach to work and study: How I Make Weekly Plans | Productivity | My Method.
“Plan ahead, or fail.” Annual plans are too long, and daily plans are too short. Managing time by the week is often the most practical way to maintain consistency over the long term.
Other Links
For further discussion, you can also find this article on:
Zhihu - Android Developer Learning Path (2020 Edition)
About Me && Blog
Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”
- Blogger Intro: Includes personal WeChat and WeChat group links.
- Blog Content Navigation: A guide for my blog content.
- Curated Excellent Blog Articles - Android Performance Optimization Must-Knows: Welcome to recommend projects/articles.
- Android Performance Optimization Knowledge Planet: The paid community stopped operating in 2026 and no longer accepts new members; this link preserves its history.
One walks faster alone, but a group walks further together.
