Android Interview Questions and Answers for 2027 - Updated

Beginner-level Android Interview Questions

Let's break down the 17 concepts you actually need to know to survive Android development right now. No fluff. Just the reality of the stack.

1. What is Android, and what version are we building for?

Android is an open-source beast now. I’m seeing my code run on smartwatches, TVs, cars running Android Auto, and Chromebooks. As of right now, if you're not maintaining legacy code, you're targeting Android 17. That's API level 37, codenamed Cinnamon Bun. It dropped in June 2026. (If you're still cleaning up last year's code, we might be working for Android 16, API 36).

2. Break down the OS stack. What are we actually building on?

I see the Android OS stack like a five-layer cake.

1. At the bottom is the Linux kernel. Without having to code the hardware power states, the kernel takes care of everything. 
2. Above that is the HAL (Hardware Abstraction Layer). This is like a bridge to high-level Kotlin code. This helps communicate with the camera or the Bluetooth chip.
3. Then we have the Android Runtime (ART) & Core Libraries. This is where everything is compiled and executed. It is a high memory-consuming layer, needing planned memory optimization. 
4. The next level is the Native C/C++ Libraries handling raw performance. We have WebKit for rendering, OpenGL for graphics, and SQLite for the local databases. 
5. Finally, at the very top, is the Java API Framework. This is where you and I live. It's the UI components, the activity manager, and the stuff we touch daily.

3. What happens under the hood between hitting "Build" and the app actually running?

You write your Kotlin. You hit build. Gradle spins up (and hopefully doesn't throw a cryptic caching error), chewing your code, XML, and resources into an AAB (Android App Bundle) or an older APK.

Your human-readable logic becomes bytecode. When a user taps your app icon, ART fires up. Here’s the brilliant part of the OS: Android treats every single app as a completely separate user. It hands your app a unique ID and throws it into an isolated sandbox. If my app hard-crashes because of a botched network request, it dies alone in its sandbox. It doesn't take down the user's entire phone.

4. What's the deal with Activities? Why no main() function?

Forget what you learned in CS 101. We don't have a main() function here. The entry point for the user is an Activity. Every app needs at least one. The OS wakes your app up by calling specific lifecycle methods based on what the user is doing. It’s the literal starting line for user interaction.

5. Why do I see juniors constantly messing up setContentView() in onCreate()?

Because they don't realize onCreate() just builds an empty shell. When the activity boots up in onCreate, there is zero user interface. If you stop there, this could result in a black screen.

To solve this, you would have to call setContentView(R.layout.activity_main). It inflates your XML layout and adds the styles to the buttons and text. This lets the user actually tap on them.

6. Walk me through the Activity Lifecycle without sounding like a textbook.

You have to master this. It's not optional.

• onCreate():
  Ground zero. You initialize variables and set up the UI.
• onStart():
  The app is visible on screen, but they can't touch it yet.
• onResume():
  We are in the foreground. Full interaction.
• onPause():
  The user gets a phone call, or a system dialog pops up. You lost focus. Save your state here, fast.
• onStop():
  The app is officially off-screen.
• onDestroy():
  The OS needs memory, or the user swiped your app away. It's dead.

7. What is a Fragment and why do we complicate things with them?

Fragments as modular sub-activities. We needed them when tablets got popular and used a completely new layout. We had to show a list on the left and details on the right without writing two different apps.

They parasitize off a host activity. They have their own lifecycle, they receive their own inputs, but they are entirely dependent on the host to exist.

8. How does the Fragment lifecycle differ from other?

Fragment lifecycle is tied to the host activity. But it also has extra steps for UI rendering. It is very tricky. 

• You get onAttach() when it links to the host, then onCreate(). 
• Then, onCreateView() creates the UI XML, and onViewCreated() follows. 
• Next, it syncs with the host from onStart(), onResume(), onPause(), onStop(). 
• Finally, onDestroyView() kills the UI, onDestroy() kills the fragment, and onDetach() unlinks it from the host.

9. Why is putting UI logic in onCreateView() a massive red flag?

onCreateView() has just one job. It elevates the XML and returns the View object.

If you try to find a button and set a click listener there, you're begging for a NullPointerException because the layout might not be fully baked. Do all your UI logic inside onViewCreated(). It fires immediately after, guaranteeing the UI components are fully initialized and safe in memory.

10. Bottom line: Activity vs. Fragment.

• Dependency:
  An Activity stands alone. A Fragment must be embedded in an Activity.
• Lifecycle Control:
  Android OS manages the Activity. The host's FragmentManager manages the Fragment.
• Weight:
  Activities are heavy and handle full-window transitions. Fragments are modular, letting you build dynamic, multi-pane UIs.

11. What exactly is a View?

Everything you see is a View. It's just a rectangle on the screen. A Button, an EditText, an ImageView. It draws the pixels and listens for your thumbs.

12. Then what is a ViewGroup?

A ViewGroup is an invisible container. Technically, a ViewGroup is just a subclass of a View. It holds Views (or other ViewGroups) and tells them where to sit. ConstraintLayout, LinearLayout, FrameLayout are ViewGroups. 

13. Why are we still writing front-end in XML?

Because it works. XML describes data so both humans and machines can read it fast. It’s lightweight, meaning faster UI rendering. It forces a hard separation between your visual design and your Kotlin business logic. It’s highly readable, and it handles deeply nested layouts while keeping the code perfectly structured.

14. What are the five pillars of an Android App?

An Android app is a five-layer coupled piece, wired together in the AndroidManifest.xml file. The OS cant imagine its existence unless they are declared in the manifest file. 

1. Activities
2. Services
3. Broadcast Receivers
4. Content Providers
5. Intents

15. What is a Toast?

Toast is a non-blocking bubble of text that pops up. It's generally used in designs for quick feedback and fades away automatically. Since it's non-blocking, the user can keep tapping things behind it.

16. Explain Context, and specifically, the memory leak trap.

If there's one concept that will save your career, it's understanding Context. It's your app's environment. It's how you access resources or inflate layouts.

But passing the wrong one will crash your app. Activity Context is tied to the Activity. Use it for UI stuff, like showing a Toast or a Dialog. When the Activity dies, this context dies. Application Context is tied to the whole app. Use this for background tasks or singleton databases.

Passing an activity context to a singleton database instance creates a new activity when users rotate their phone. But this database is still holding onto the old activity in memory. This causes a massive memory leak.

17. What do you hate the most about Android development?

I love this platform, but I won't lie about the pain points.

• Fragmentation:
  It's brutal. You are building for thousands of different screen sizes, aspect ratios, and cheap hardware configurations. Testing is a nightmare.
• Performance Variability:
  What runs buttery smooth on a flagship Pixel might stutter violently on a budget phone because the Java Garbage Collector decided to pause the main thread.
• Security:
  It's open-source. Users can sideload third-party APKs from anywhere. If they aren't careful, the risk of malware is just statistically higher here.

We deal with these constraints daily. We write better code, we test on terrible devices, and we plug the memory leaks. That's the job.

Intermediate-Level Android Interview Questions

So you survived the basics. You know your activities from your fragments, and you aren't leaking memory every time a user turns their screen. Good. Now we need to talk about how the pieces actually communicate, how we render complex data without burning through RAM, and how we handle the background execution restrictions that Google aggressively pushes every year.

Here are the intermediate-level questions and answers that separate the juniors from the devs. I actually trust to push code to production.

18. What's the Android Manifest file, and why do we care?

The AndroidManifest.xml file is like a checklist for the app. If a component isn't listed in the file, the OS will never know about its existence. It provides such details to the Android system before running the Kotlin code. 

You declare your activities and services in the same file. You ask for user permissions here (camera, location, and network access). You define which screen is the main entry point. Then you set up your Intent Filters. 

If the app runs without registering an activity, it crashes with an ActivityNotFoundException error. 

19. Break down the different layout types. Which ones do we actually use?

A layout is just the invisible scaffolding that holds your UI together.

• ConstraintLayout:
  This is the gold standard. Use this 95% of the time. It lets you anchor UI elements to each other, creating completely flat view hierarchies. Deeply nested layouts destroy rendering performance, and ConstraintLayout fixes that.
• LinearLayout:
  Stacks things in a single row or column. Great for dead-simple, static UI components.
• FrameLayout:
  Literally just stacks views on top of each other like a deck of cards. I use this constantly as a container for injecting Fragments.
• GridLayout:
  Exactly what it sounds like. Good for a rigid table of items.
• RelativeLayout:
  This is legacy garbage. We used to use it to position views relative to each other, but ConstraintLayout does it better, faster, and cleaner. Stop using it.

20. What is a RecyclerView, and why does the ViewHolder pattern matter?

For example. If you try to display a list of 1,000 items and you create a new View object for each, the phone will run out of memory and kill the app.

RecyclerView is how we display massive datasets. It works with the ViewHolder pattern. Instead of listing all 1,000 views, the system only creates the 10 or 12 views. This will fill the physical screen matching the layout and add a couple of extras at the end.

Wth this, when you scroll down the item that disappears from the top but it's not destroyed. It gets recycled instead. The OS hands that exact same view back to the bottom of the list. 

The onBindViewHolder() method swaps out the old data for the new. This literally recycles pixels. It reduces CPU overhead and keeps the frame rate buttery smooth.

21. What are the four Android-supported dialog boxes?

You'll need to interrupt the user eventually. We generally reach for these four:

• Alert Dialog:
  The classic popup. Usually has a title, a message, and a couple of buttons (like "Accept" or "Cancel").
• Date Picker Dialog:
  A standardized calendar popup.
• Time Picker Dialog:
  A standardized clock popup.
• Progress Dialog:
  Officially deprecated. Stop using this. It locks up the UI and creates a terrible user experience. If you need to show loading states, embed a ProgressBar directly inside your layout.

22. What's an Intent? Give me the two types.

An Intent is a message you send to the OS declaring your intention to do something. You want to open a camera? Start a background service? Move to another screen? You need an Intent.

• Explicit Intents:
  It’s commonly used within the same application when you know the exact class you want to start. For example, moving from FirstActivity to SecondActivity in your app requires an explicit intent.
• Implicit Intents:
  They declare a general action to perform, allowing any app capable of handling that action to respond. For instance, if you want to open a webpage or show a location on a map, you can use an implicit intent.

23. So what is a PendingIntent, and when do I use it?

A PendingIntent is essentially a VIP backstage pass you hand to a foreign application.

Normally, an Intent executes right now, inside your app. But what if you want the Android Notification Manager to open your app when the user taps a push notification three hours from now, long after your app has been swiped away and killed?

You wrap your Intent in a PendingIntent and hand it to the OS. Because you created it, it retains your app's security context. The OS can execute it later, on your behalf, with your exact permissions. We use these constantly for Notifications, Alarms, and Home Screen Widgets.

24. What actually makes up the Android SDK?

The Software Development Kit of Android is the toolbox we use to build, debug, and package these apps. Some components from these SDKs are 

• Android Emulator:
  It's a virtual phone that runs on the desktop, which provides an Android environment for testing the app.
• Android Debug Bridge (ADB):
  This is a command-line lifeline. This is how the IDE connects with the physical device over USB or Wi-Fi. It helps install builds or pull crash logs.
• Android Profiler:
  It's used to monitor memory leaks and CPU spikes and track delayed network requests.
• AAPT (Android Asset Packaging Tool): The silent hero that compiles all your raw XML and images into the final binary.

25. Let's talk Jetpack. What is it, and what nightmare did it fix?

Android Jetpack is Google's massive suite of libraries and architectural guidelines.

Before Jetpack, Android development was the Wild West. You had to write hundreds of lines of boilerplate code to handle simple local databases, and managing lifecycles was a total nightmare. If a user rotated their phone, your Activity died, your background network request lost its callback, and the app crashed.

Jetpack brought sanity to the stack. It gave us Architecture Components (ViewModel, Room), modern UI toolkits (Jetpack Compose), and standard components for backward compatibility (AndroidX). We don't build modern apps without it.

26. Explain ViewModel. How does it survive a screen rotation?

This is a critical Jetpack component. ViewModel stores and manages UI data in a way that actively respects lifecycles.

When the user rotates their phone from portrait to landscape, the OS ruthlessly destroys and recreates the Activity. If you stored your user's form data in the Activity's variables, it's gone.

The ViewModel lives outside the Activity's immediate lifecycle. It sits safely in memory managed by the ViewModelStore. When the Activity gets destroyed and rebuilt during that rotation, it simply reconnects to the existing ViewModel. Your data is instantly recovered without needing another expensive network call.

27. Why do we use Room Database instead of raw SQLite?

Room is the official Jetpack persistence library. It's a clean abstraction layer over the legacy SQLiteOpenHelper.

Writing raw SQLite in Android was miserable. You had to manually map database cursors to your objects, which was highly error-prone. Room fixes this. First, it handles the object-relational mapping (ORM) automatically. Second, it provides compile-time verification. If you have a typo in your SQL query, the app simply refuses to build. You catch the bug in your IDE, not as a runtime crash in production. Finally, it integrates flawlessly with Kotlin Coroutines and LiveData, automatically pushing database changes to your UI.

28. What are Services? Break down the restrictions.

A Service runs long operations in the background without a UI. But you have to be careful—Google has severely restricted them to stop lazy developers from draining user batteries.

• Foreground Services:
  Use this for tasks the user actually knows about, like a music player or a GPS run tracker. You are legally required by the OS to show a persistent notification. Because the user is aware of it, the system gives it high priority and rarely kills it.
• Background Services:
  Used for silent operations like data syncing. Honestly, these are basically dead. Modern Android versions will ruthlessly hunt down and kill background services shortly after the user leaves your app to save battery.
• Bound Services:
  Think of this as a client-server relationship. Your Activity "binds" to the service to send data back and forth (IPC). The service only stays alive as long as something is actively bound to it.

29. If Background Services are dead, what is WorkManager?

WorkManager is the Jetpack solution for the battery-saving massacre I just mentioned.

If you have a quick task that needs to happen right now on the current screen (like fetching a user profile), use a Kotlin Coroutine.

But if you have deferrable, guaranteed background work—like uploading heavy analytics logs, compressing an image, or syncing a local database—you use WorkManager. It survives app exits and device reboots. You can hand it constraints, like "Only run this heavy upload when the phone is connected to Wi-Fi and plugged into a charger." WorkManager catches the request, respects the device's battery limits, and guarantees the job gets done eventually.

Advanced-Level Android Interview Questions

Alright, you’ve survived the basics and the intermediate hurdles. If you're interviewing for a Senior or Lead position, nobody cares if you know how to center a button in XML anymore. They want to know if you can architect a highly concurrent, reactive application without tanking the frame rate or leaking megabytes of memory.

Here is the advanced stuff that separates the code monkeys from the true engineers. Welcome to the final boss.

30. How do you go about creating custom views in Android?

Sometimes the out-of-the-box UI widgets just don't cut it. When the design team hands you a complex, animated, entirely non-standard graph, you have to build it yourself.

Here is the blueprint for creating a custom view from scratch:

• Extend the View class:
  You create a new subclass (or extend an existing one). To actually take control of the pixels on the screen, you override the onDraw(canvas: Canvas) method.
• Handle user interaction:
  A view isn't much good if it doesn't react. You override onTouchEvent() to intercept raw screen taps, swipes, and pinches.
• Define custom attributes:
  You don't want to hardcode colors and sizes. You create custom XML attributes in res/values/attrs.xml so you (or other devs) can easily configure the view directly in the layout files.
• Inflate it:
  Finally, you drop your fully qualified class name into your XML layout, or invoke it directly via Jetpack Compose interoperability.

31. DVM vs. ART. What’s the difference and why does it matter?

If you don't know how your code is being executed, you can't optimize it.

DVM (Dalvik Virtual Machine) is the ghost of Android past. It relied on Just-In-Time (JIT) compilation, meaning it compiled your app's bytecode into machine code on the fly as the user was running the app. It was designed for ancient phones with zero storage space, but it chewed up battery life and CPU cycles like crazy.

ART (Android Runtime) is the modern standard. It introduced Ahead-Of-Time (AOT) compilation (and now a hybrid AOT/JIT model). Now, when the user downloads your app, ART immediately compiles your bytecode into native machine code during installation.

The tradeoff? Apps take up slightly more disk space and take a few seconds longer to install.

The benefit? Massive performance boosts, buttery smooth UI rendering, and significantly better battery life because the CPU isn't constantly translating code on the fly.

32. How do you actually hunt down and fix performance problems?

"The app is slow" is a developer's worst nightmare because it could mean anything. Here is my standard diagnostic playbook for keeping users happy:

• UI Thread Blocking:
  The golden rule of Android—never block the Main thread. If you are doing network calls or database queries on the UI thread, the app will stutter and crash (ANR). Offload everything heavy to Kotlin Coroutines or WorkManager.
• Memory Leaks:
  If a user uses your app for 20 minutes and it crashes, you likely have a leak. I immediately hook up LeakCanary in debug builds and use the Android Studio Memory Profiler to ensure rogue Context references or massive Bitmaps are actually being deallocated.
• Inefficient Layouts:
  Deeply nested LinearLayouts require the OS to measure the screen multiple times per frame. Flatten your view hierarchy using ConstraintLayout, or better yet, just migrate to Jetpack Compose.
• Network Bloat:
  Stop downloading 4MB payloads for a simple list. Use caching strategies, implement pagination, and compress your data.

33. How do you handle third-party dependencies without breaking the app?

Adding a library is easy. Managing dependencies when a project hits a million lines of code is a nightmare if you don't have a strict system.

• Gradle is King:
  We declare all our third-party libraries via Gradle in the module-level build.gradle.kts file.
• Repositories:
  Gradle pulls these pre-compiled binaries from remote servers like Maven Central or Google's Maven repository. (If you still see JCenter in a codebase, delete it. It's officially dead).
• Version Catalogs:
  The modern standard for avoiding version conflicts across multi-module projects is using a libs.versions.toml file. It centralizes all your dependency versions in one place.
• Dependency Injection:
  We don't just instantiate library objects willy-nilly. We use robust DI frameworks like Hilt or Dagger to inject these dependencies systematically and manage how long they live in memory.

34. What are Kotlin Coroutines, and why did we ditch standard JVM Threads?

If you suggest using standard JVM threads in a modern Android interview, you will fail.

Traditional JVM threads are incredibly heavy. They map directly to OS-level threads. If you spin up 1,000 of them, you will crash the app with an OutOfMemoryError.

Coroutines are lightweight, virtual threads managed by the Kotlin runtime, not the OS. I can launch 100,000 coroutines concurrently on a single background thread without breaking a sweat. They use suspend functions to pause their execution and yield the thread to another coroutine while waiting for a network response, completely eliminating thread-blocking. They are the absolute standard for modern async work.

35. Explain the exact difference between launch and async in Coroutines.

Both are builders that start concurrent work, but they handle the aftermath entirely differently.

• launch:
  This is "fire-and-forget." It returns a Job object that doesn't carry a resulting value. Use this when you don't need a return result—like firing off an analytics event to a server or writing a quick log to a local database.
• async:
  This is when you expect a specific answer back. It returns a Deferred object (think of it as a lightweight, non-blocking Future). You fire off the task, do some other stuff, and eventually call .await() on it to grab the final result once the background work completes.

36. What is Kotlin Flow, and how do StateFlow and SharedFlow differ?

RxJava is largely a thing of the past. Kotlin Flow is our modern, native reactive data stream. It emits values sequentially over time.

• StateFlow:
  This is for UI State. It always holds exactly one value (it requires an initial state), and it conflates updates. If your background sync pushes 50 state updates a second, but the UI can only render 10, StateFlow drops the intermediate ones and only gives the UI the latest, most relevant data. It is the modern replacement for LiveData.
• SharedFlow:
  This is for events. Navigation triggers, Snackbar messages, or error popups. It doesn't require an initial state, it doesn't inherently hold state, and it can be configured to replay past events to new subscribers.

37. How does "Recomposition" actually work in Jetpack Compose?

Jetpack Compose fundamentally changes how we build UIs. It's a declarative toolkit.

In the old XML days, if data changed, you manually updated the widget: myTextView.text = "New Text".

In Compose, you bind your UI directly to a State object. When that state changes, Compose triggers Recomposition. The framework is highly intelligent—it scans your UI tree, identifies only the specific composable functions that read that exact piece of state, and re-executes them to draw the new data. The rest of the UI is completely ignored and left untouched. It's brutally efficient and eliminates manual UI bugs.

38. MVVM vs. MVI. What’s happening to app architecture?

• MVVM (Model-View-ViewModel):
  The current industry standard. The View observes state from the ViewModel. The ViewModel talks to repositories. Data flows down, and events (like button clicks) trigger explicit method calls on the ViewModel.
• MVI (Model-View-Intent):
  This is the future, rising rapidly alongside Jetpack Compose. MVI enforces strict Unidirectional Data Flow (UDF). Instead of calling 15 different methods on a ViewModel, the View fires a single "Intent" (a sealed class representing an action, like LoadUser). The ViewModel processes this and spits out a single, immutable UiState object representing the entire screen. It makes state consistency absolute.

Frequently Asked Questions On Android Interviews

What's the best way to get ready for an Android interview?

Focus entirely on the modern stack. Master Activity/Fragment lifecycles, UI rendering, concurrency (Kotlin Coroutines), and local databases (Room). Don't ignore core computer science—you will still need to practice algorithmic coding questions and defend your architectural choices (like MVVM).

What exactly is an Android lifecycle?

It’s the series of states a component goes through. It goes from creation (onCreate), to visibility (onStart, onResume), to backgrounding (onPause, onStop), to total destruction (onDestroy). Understanding this is non-negotiable if you want to prevent crashes and memory leaks.

What is Gradle in Android?

Gradle is the automated build toolkit. It takes your Kotlin code, XML files, and third-party libraries, compiles them all together, and packages them into the executable AAB (Android App Bundle) or APK that users actually install.

What is Maven on Android?

Maven refers to the repository ecosystem. We use Maven Central or Google's Maven repository—massive online servers where thousands of developers host third-party libraries (like Retrofit or Glide) so you can easily pull them into your project via Gradle.

What kind of coding questions are asked?

Expect standard Data Structures and Algorithms (Arrays, HashMaps, Strings). However, Android interviews heavily feature domain-specific tests: expect to be asked to build a complex UI list, handle multi-threading scenarios, or debug a fake crash log.

How should I structure my preparation?

Review core Modern Android Development (MAD) and Jetpack concepts first. Then grind core algorithmic problems. Finally, build real-world projects so you can confidently explain the architectural decisions you made in past apps.

What programming languages do I need to know?

Kotlin. Period. While some legacy enterprise apps still use Java, Kotlin has been Google's official preferred language since 2019. Expect over 90% of modern interviews to mandate Kotlin.

Where are the best places to practice?

LeetCode, HackerRank, and CodeSignal are standard for algorithm practice. For architecture, stop reading basic tutorials and go look at Google's official open-source sample repositories on GitHub to see how enterprise code is actually structured.

Where can I find good practice questions?

Medium, Stack Overflow, and tech blogs are great resources, but your primary source of truth should always be the official Android Developer Documentation.

Why did Google kill AsyncTask?

AsyncTask was historically used for background threading, but it was deprecated in API 30 because it was fundamentally broken. It caused massive memory leaks on screen rotation, swallowed exceptions silently, and missed UI updates. It has been entirely replaced by Kotlin Coroutines for standard async work and WorkManager for guaranteed background jobs.

Conclusion

Preparing for Android interview needs a strong understanding of fundamental concepts. Professionals should also get used to practicin advanced development practices. This article was designed keeping in mind that professional of all status like fresher and experienced professionals. This content will boost your confidence and help you ace your interviews.