I am learning flutter from JustAcademy, They provide very much great environment where people gather and work simultaneously. totally project based training institute.
Awesome Experience. I am a Front-end Web Designer working at Star India for 3 years now. I applied for Full-stack development and my experience has been phenomenal & they really do help with placements exceptionally. Thank you Roshan sir so much.
Preparing for your first Android developer interview is one of the most important steps in launching your mobile development career. Whether you have just completed an android course for beginners, finished your first portfolio projects, or are currently enrolled in android training online with live projects — knowing what interviewers actually ask and how to answer confidently makes the difference between getting hired and going home without an offer.
The good news is that fresher-level Android interviews follow a very clear and predictable structure. Companies hiring entry-level Android developers want to verify that you understand Android fundamentals, can write basic Kotlin code, know how to build UI with XML or Jetpack Compose, understand the Activity lifecycle, and have enough project experience to work on a real team from day one.
This guide gives you the top 50 Android development interview questions and answers for freshers in 2026 — carefully organized from basic concepts through intermediate topics, with answers written in clear, interview-ready language. Every question in this list is drawn from real fresher Android interviews at IT services companies, product startups, and mobile development teams across India.
JustAcademy offers both Online and Offline Android App Development training with live projects, expert mentors, recognized certification, and 100% placement support. 👉 View Complete Android Course | Book FREE Demo | Download Brochure
Before diving into the questions, understanding how Android fresher interviews are typically structured helps you prepare more strategically.
Most companies hiring freshers for Android developer roles conduct two to three rounds:
Round 1 — Written or Online Technical Test. Basic multiple-choice or short-answer questions testing your understanding of Android concepts, Kotlin/Java basics, Activity lifecycle, UI components, and fundamental mobile development concepts. This filters candidates before the face-to-face technical interview.
Round 2 — Technical Interview. The interviewer asks conceptual questions about Android components, lifecycle, architecture patterns, Kotlin features, and common Android libraries. You may be asked to write basic code snippets or explain your portfolio projects in detail.
Round 3 — HR Interview. Standard questions about your background, career goals, why you chose Android development, and your willingness to learn and grow.
The 50 questions in this guide cover exactly what technical rounds test — study them, understand the reasoning behind each answer, and practice explaining concepts in your own words.
Answer:
Android is an open-source mobile operating system developed by Google, based on the Linux kernel. It was first released in 2008 and has since grown to become the most widely used smartphone platform in the world, commanding over 72% of global market share and over 95% in India as of 2026.
Android is designed primarily for touchscreen mobile devices — smartphones, tablets, smartwatches, Android TVs, and Chromebooks. It provides a complete software stack including an operating system, middleware, and key mobile applications.
Key features of Android:
Open-source nature — the Android Open Source Project (AOSP) allows manufacturers to customize the OS for their hardware, which is why Android runs on devices from hundreds of different manufacturers across all price segments.
Multi-tasking — Android allows running multiple apps simultaneously, with a sophisticated task management system that prioritizes foreground apps while pausing background processes to conserve resources.
Google ecosystem integration — tight integration with Google services including Gmail, Maps, Drive, Assistant, Play Store, and Chrome.
Rich notification system — Android's persistent notification shade gives users actionable, expandable notifications without opening individual apps.
Customizability — home screen launchers, widgets, custom ROMs, and sideloading allow users to personalize the experience beyond what most mobile platforms permit.
Hardware diversity — from budget ₹5,000 devices to ₹150,000 flagship phones, Android's ability to run across hardware tiers makes it accessible to the broadest possible user base globally.
Interview tip: Always mention that Android is open-source and Linux-based — these are fundamental facts that every Android developer interview expects you to know.
Answer:
Android applications are built from four fundamental components. Understanding each component — what it does, when to use it, and how the Android system interacts with it — is one of the most commonly tested topics in fresher Android interviews.
Activity is a component that represents a single screen with a user interface. Every screen the user sees is implemented as an Activity. A login screen, a home screen, a settings screen, and a product detail screen are all individual Activities. Activities have a defined lifecycle managed by the Android system.
Service is a component that runs in the background without a user interface. Services are used for long-running operations — playing music while the user browses other apps, downloading files in the background, tracking GPS location, or syncing data. Services allow apps to continue performing operations even when the user navigates away from the app.
Broadcast Receiver is a component that listens for system-wide or app-specific events and responds to them. Examples include receiving a broadcast when the device finishes charging, when the network connectivity changes, when an alarm fires, or when another app sends a custom broadcast. Broadcast Receivers can respond to events even when the app is not running.
Content Provider manages access to a shared set of structured data. Content Providers allow apps to share data securely with other apps using a standardized URI-based interface. The Contacts database, Calendar data, and Media Store are accessed through system Content Providers. Apps can also create their own Content Providers to share data with other applications.
Answer:
The Activity Lifecycle is one of the most fundamental and most frequently asked topics in Android fresher interviews. It describes the sequence of states an Activity passes through from creation to destruction, allowing developers to write code that responds appropriately to system and user events.
onCreate() — Called when the Activity is first created. This is the most important lifecycle method — where you initialize the UI by calling setContentView() to inflate the layout, set up ViewBinding, initialize ViewModel, bind RecyclerView adapters, and perform one-time setup. Receives a Bundle containing previously saved state if the Activity is being recreated.
onStart() — Called immediately after onCreate() or when returning from onStop(). The Activity becomes visible to the user but is not yet in the foreground and cannot receive user input.
onResume() — Called when the Activity comes to the foreground and becomes fully interactive. This is the active running state — the user can interact with the screen. Restart any paused operations here (animations, location updates, camera preview).
onPause() — Called when the Activity is partially obscured — another Activity has moved to the foreground but this Activity is still partially visible. Stop any ongoing operations that should not continue when the Activity is not in focus (animations, GPS updates). Execute only fast, lightweight operations here as the system will not proceed to the next Activity until onPause() returns.
onStop() — Called when the Activity is no longer visible to the user. Another Activity has completely covered it or the user has pressed the home button. Release resources that are not needed when invisible — stop heavy background operations, release camera or sensor resources.
onRestart() — Called after the Activity has been stopped and is about to be started again. Called before onStart() when the user returns to the Activity.
onDestroy() — Called before the Activity is destroyed — either because the user finished it (pressed back) or the system is destroying it to reclaim resources. Release all remaining resources — cancel pending work, close database connections, unregister receivers.
Answer:
This distinction is commonly tested because many beginners confuse the two methods or use them interchangeably.
onPause() is called when the Activity is partially obscured — it is still visible to the user but another Activity is in the foreground. This happens when a dialog Activity appears over the current Activity, when the user enters multi-window mode, or when the notification shade or quick settings panel is pulled down. During onPause(), the Activity is still partially visible, so any operations related to visible content should still be active.
The key rule for onPause(): do only lightweight operations — do not perform heavy processing, database writes, or network calls in onPause() because the system waits for onPause() to complete before showing the next Activity. Long operations in onPause() make the next screen feel slow to appear.
onStop() is called when the Activity is completely invisible — fully covered by another Activity, the user has pressed the home button, or the user has navigated to another app entirely. At this point, the user cannot see the Activity at all. Release resource-intensive operations here — stop location updates, release camera access, pause heavy animations.
The practical difference: onPause() = partially visible or losing focus → be lightweight. onStop() = completely invisible → release heavier resources.
An Activity goes through onPause() before onStop() — they are sequential in the lifecycle, not alternatives.
Answer:
Activity is a fundamental Android component that represents a complete screen with its own lifecycle, managed directly by the Android system. An Activity exists independently — it can be launched by other apps, appear in the recent apps list, and handle back button events directly. In early Android development, each screen was a separate Activity.
Fragment is a reusable portion of UI that lives within an Activity. A Fragment has its own layout, its own lifecycle (which is tied to the host Activity's lifecycle), and its own behavior — but it cannot exist independently without an Activity hosting it. Multiple Fragments can coexist within a single Activity simultaneously.
Why Fragments were introduced:
Fragments were created to support flexible UI design for tablets and large screens. A tablet might show a master list Fragment and a detail Fragment side by side. A phone shows them as separate screens. Using Fragments, the same code handles both layouts with different Fragment arrangement rather than completely different codebases.
The modern recommended approach:
Current Android best practices (since Jetpack Navigation became stable) recommend a single-Activity architecture — one Activity that hosts multiple Fragments (or Composable screens with Jetpack Compose). Each screen is a Fragment, and the Navigation Component manages the back stack and transitions between them. This approach provides better animation support, shared ViewModels across screens, and simpler deep linking.
The key difference for interviews: Activities are independent, system-managed screen containers. Fragments are reusable UI modules that live within Activities and enable flexible, modular screen design.
Answer:
Kotlin is a statically typed, modern programming language developed by JetBrains that runs on the Java Virtual Machine (JVM) and is fully interoperable with Java. Google officially announced Kotlin as the first-class, preferred language for Android development in 2017, and since then, all new Android documentation, samples, and Jetpack library APIs are written in Kotlin.
Why Google chose Kotlin over Java for Android:
Conciseness — Kotlin achieves the same functionality as Java with significantly less code. Data classes, extension functions, lambda expressions, and smart casts eliminate large amounts of Java boilerplate. A Java POJO with five fields might require 50 lines including getters, setters, equals(), hashCode(), and toString(). The Kotlin equivalent is one line with a data class.
Null safety — Kotlin's type system distinguishes between nullable types (String?) and non-nullable types (String). The compiler enforces null safety at compile time rather than runtime — preventing NullPointerExceptions, which are the most common cause of Android app crashes in Java codebases.
Coroutines — Kotlin's built-in coroutine support makes writing asynchronous code dramatically simpler than Java's callback patterns or RxJava chains. Network calls and database operations can be written as sequential-looking code using suspend functions.
Full Java interoperability — Kotlin code can call Java code and vice versa. This means existing Android codebases written in Java could adopt Kotlin incrementally — teams did not need to rewrite everything at once.
Modern language features — Extension functions, sealed classes, data classes, object declarations, destructuring declarations, and other modern features make Kotlin more expressive and safer than Java for Android development.
Answer:
This comparison question appears frequently in fresher Android interviews, particularly for candidates from Java programming backgrounds.
Null safety: Java allows null values for any reference type and throws NullPointerException at runtime when null is dereferenced. Kotlin has nullable (String?) and non-nullable (String) types — the compiler catches null dereference errors at compile time rather than runtime.
Syntax conciseness: Kotlin eliminates significant boilerplate. Data classes replace Java POJOs with getters, setters, equals, hashCode, and toString. Extension functions add methods to existing classes without inheritance. Type inference reduces explicit type declarations.
Coroutines vs threads: Kotlin provides coroutines for asynchronous programming — lightweight, structured concurrency that replaces complex callback chains and thread management. Java uses threads and callback interfaces for async operations — significantly more verbose and error-prone.
Functional programming: Kotlin has first-class support for higher-order functions, lambda expressions, and functional operations on collections (map, filter, reduce, groupBy). Java 8 added some of these but with less clean syntax.
Extension functions: Kotlin allows adding new functions to existing classes without modifying them or using inheritance. This is impossible in Java without utility classes.
No checked exceptions: Kotlin does not have checked exceptions (the exceptions you are forced to declare in method signatures in Java). This reduces boilerplate around exception handling.
Smart casts: After checking an object's type with instanceof-equivalent (is), Kotlin automatically casts the variable to that type within the scope — no explicit casting needed.
For Android in 2026: An android course with kotlin training is the right investment. Java knowledge is valuable for understanding legacy codebases but Kotlin is where all new Android development happens.
Answer:
An Intent is a messaging object that enables communication between Android components — Activities, Services, and Broadcast Receivers. Intents describe an action to be performed and carry data associated with that action. They are the primary mechanism for requesting navigation, starting services, and delivering broadcasts in Android.
Explicit Intents specify the exact component (by class name) that should handle the action. The sender knows exactly which component to start. Explicit Intents are used for communication within your own app — navigating from one Activity to another within the same application.
Example: Starting a DetailActivity from MainActivity uses an explicit Intent specifying the DetailActivity class. val intent = Intent(this, DetailActivity::class.java)
Implicit Intents declare a general action to be performed without specifying which component handles it. The Android system finds appropriate components that can handle the action based on their Intent Filters declared in the AndroidManifest.xml. If multiple apps can handle the action, the system shows the user a chooser dialog.
Example: Opening a URL uses an implicit Intent with ACTION_VIEW and a URL Uri. The system automatically offers the user's installed browsers as options. val intent = Intent(Intent.ACTION_VIEW, Uri.parse("https://www.example.com"))
Common implicit Intent actions include ACTION_SEND (sharing content), ACTION_DIAL (opening the phone dialer), ACTION_PICK (selecting from a gallery), and ACTION_CALL (making a phone call).
Intent Filters are declarations in AndroidManifest.xml that specify which Intents a component can handle — what actions, data types, and categories it accepts. An Activity with an intent filter for ACTION_VIEW and http:// scheme declares itself as a web browser.
Answer:
The AndroidManifest.xml file is a required configuration file that every Android application must have at the root of the project's source set. It provides essential information about the application to the Android build tools, the Android operating system, and the Google Play Store.
What AndroidManifest.xml contains:
Package name — the unique application identifier (e.g., com.company.appname) that identifies the app on the device and in the Play Store.
Component declarations — every Activity, Service, Broadcast Receiver, and Content Provider in the application must be declared in the manifest. Components not declared in the manifest cannot be used by the Android system.
Permissions — the app must declare all permissions it requires to function. User-visible permissions (camera, location, contacts, microphone) are declared with <uses-permission> tags. Since Android 6.0 (Marshmallow), dangerous permissions must also be requested at runtime in addition to being declared in the manifest.
Intent Filters — declarations within component entries that specify which implicit Intents each component can handle. The main Activity entry has an Intent Filter marking it as the app's entry point (MAIN action, LAUNCHER category) — which is what makes it appear in the device's app launcher.
Hardware and software features — <uses-feature> tags declare what hardware (camera, NFC, GPS) the app requires. This allows the Play Store to filter the app from devices that lack required hardware.
Minimum and target SDK versions — declaring the minimum Android version the app supports and the Android version it was designed for.
Answer:
Understanding Android's measurement units is a practical knowledge question that appears in many fresher interviews because incorrect unit usage causes UI to look different across devices — a common beginner mistake.
px (pixels) — Raw screen pixels. The actual dot on the physical display screen. Using px directly in Android UI is almost always wrong for anything other than single-pixel lines, because the same px value produces dramatically different visual sizes on screens with different pixel densities. A 100px button is tiny on a high-density flagship phone and enormous on a low-density budget device.
dp (density-independent pixels) — The correct unit for specifying layout dimensions, margins, padding, and non-text sizes in Android. One dp equals one pixel on a 160dpi (mdpi) screen — on higher density screens, dp values are automatically scaled up proportionally. Using dp ensures that a button declared as 48dp appears approximately the same physical size regardless of screen density. Always use dp for layout measurements.
sp (scale-independent pixels) — The correct unit for text sizes in Android. sp works like dp — it scales for screen density — but additionally scales based on the user's preferred text size setting in Accessibility settings. Users who set larger text sizes in system settings see larger text in any app that uses sp correctly. Always use sp for text sizes and never use dp for text sizes.
The practical rule: All text sizes → sp. All layout dimensions, margins, padding → dp. Never use px for UI measurements.
This distinction is important for accessibility — users with visual impairments set larger text sizes in system settings. Apps that use sp for text respect this preference; apps that use dp or px for text do not scale and are therefore less accessible.
Answer:
RecyclerView is the modern Android component for displaying scrollable lists of data — product listings, message threads, news feeds, contact lists, and virtually any collection of items that extends beyond the screen. It was introduced in Android 5.0 (Lollipop) as a more flexible and efficient replacement for the older ListView.
How RecyclerView works:
RecyclerView gets its name from its core optimization — view recycling. Instead of creating a new View object for every item in the list (which would consume enormous memory for large lists), RecyclerView creates only enough View objects to fill the visible screen plus a few extra. When an item scrolls off screen, its View is not destroyed — it is placed in a pool of recycled Views. When a new item scrolls onto the screen, a recycled View is taken from the pool and filled with the new item's data. This recycling makes RecyclerView extremely efficient even for lists of thousands of items.
RecyclerView requires three main pieces:
Adapter — converts data (a list of objects) into Views for RecyclerView to display. The adapter extends RecyclerView.Adapter and overrides three methods: onCreateViewHolder() (creates a new ViewHolder by inflating the item layout), onBindViewHolder() (fills a ViewHolder with data from a specific position), and getItemCount() (returns the total number of items).
ViewHolder — a class that holds references to the Views within a single item layout, eliminating the need for repeated findViewById() calls during scroll — a significant performance optimization.
LayoutManager — controls how items are arranged. LinearLayoutManager displays items in a vertical or horizontal scrolling list. GridLayoutManager displays items in a grid. StaggeredGridLayoutManager displays items in a staggered grid (like Pinterest).
Why RecyclerView replaced ListView:
ListView required ViewHolder as a convention but did not enforce it. RecyclerView requires ViewHolder as a core structural component. RecyclerView supports horizontal scrolling, grid layout, and staggered layouts natively — ListView only supported vertical lists. RecyclerView provides built-in item animations for add/remove/move operations. RecyclerView uses DiffUtil for efficient list updates that minimize redraws.
Answer:
ViewModel is an Android architecture component from the Jetpack library that is designed to store and manage UI-related data in a lifecycle-conscious way. The critical capability that makes ViewModel essential is that it survives configuration changes — specifically screen rotation.
The problem ViewModel solves:
When a user rotates their Android device, the system destroys and recreates the current Activity. Without ViewModel, all data held in the Activity's member variables is lost — a network response that just arrived, a list of items fetched from an API, the current state of a form the user was filling out — all gone. The user sees a blank screen or the Activity starts refetching data from scratch.
ViewModel survives this destruction-recreation cycle. The ViewModel instance is retained by the system while its associated Activity or Fragment is going through a configuration change. When the Activity is recreated after rotation, it receives the same ViewModel instance containing the same data that existed before rotation.
The single responsibility of ViewModel:
ViewModel holds and exposes UI state to the View (Activity or Fragment). It receives user events from the View, calls the Repository or data layer for data, and exposes the result as observable state (LiveData or StateFlow). ViewModel contains no references to Activity, Fragment, or View objects — it is completely lifecycle-independent.
Why ViewModel must not hold View references:
If a ViewModel held a reference to an Activity and that Activity was destroyed (during rotation or navigation), the ViewModel would prevent the Activity from being garbage collected — causing a memory leak. ViewModel's architecture deliberately prevents this by having the View observe ViewModel rather than ViewModel referencing the View.
Answer:
LiveData is an observable data holder class that is lifecycle-aware. It holds a value and notifies its observers when that value changes — but only when the observer (Activity or Fragment) is in an active lifecycle state (STARTED or RESUMED).
The lifecycle-aware benefit:
Traditional observable patterns (like RxJava or simple callbacks) notify observers regardless of whether those observers are currently visible or even alive. This causes crashes when a callback tries to update a destroyed Activity's UI. LiveData eliminates this entirely — if the observing Activity is stopped or destroyed, LiveData stops sending updates. When the Activity becomes active again (comes to the foreground), LiveData delivers the latest value.
The ViewModel + LiveData pattern:
The ViewModel holds a MutableLiveData field — a LiveData that can have its value changed from within the ViewModel. The ViewModel exposes this as a public LiveData (read-only) property. The Activity or Fragment observes this LiveData in onCreate(). When the ViewModel fetches new data (from an API or database), it posts the new value to the MutableLiveData. LiveData automatically delivers this value to all active observers — the Activity's UI updates.
This pattern ensures that UI always reflects the latest data, survives rotation without data loss, and never crashes due to updates to destroyed Views.
LiveData vs StateFlow:
Kotlin's StateFlow (from Kotlin Coroutines) is increasingly the preferred alternative to LiveData in modern Android development because it integrates more naturally with Kotlin Coroutines and Compose. StateFlow requires collecting in a lifecycle-aware scope (using repeatOnLifecycle) to get the lifecycle safety that LiveData provides automatically.
Answer:
Jetpack Compose is Android's modern, recommended toolkit for building native user interfaces using a declarative programming model. It was released as stable in Android Studio 2021 and is now the primary recommendation for all new Android UI development.
XML-based UI (the traditional approach):
In traditional Android UI development, you describe UI structure in XML layout files — separate files from your Kotlin/Java code. At runtime, the Android framework inflates these XML files into a View hierarchy tree. To update the UI in response to data changes, you imperatively find the View (findViewById), and call methods on it (textView.text = "new value", imageView.visibility = View.GONE).
This approach has several drawbacks: XML and Kotlin code are in separate files and must be kept synchronized, updating UI state requires finding and manipulating individual Views, and creating complex dynamic or animated UIs is verbose and error-prone.
Jetpack Compose (the modern approach):
Compose uses a declarative model — you describe what the UI should look like for a given state, and Compose handles rendering and updates automatically. UI is defined as Composable functions (annotated with @Composable) written entirely in Kotlin. When the state that a Composable depends on changes, Compose automatically re-executes that Composable function and updates only the parts of the UI that need to change.
There are no XML layout files in a pure Compose project — UI and logic coexist in Kotlin files. This eliminates the XML/Kotlin synchronization problem and makes UI code significantly more readable, testable, and maintainable.
Key Compose concepts beginners must know:
@Composable annotation marks functions as Compose UI functions. remember { } stores state that survives recomposition. mutableStateOf() creates observable state that triggers recomposition when changed. LazyColumn is the Compose equivalent of RecyclerView. Column, Row, and Box provide vertical, horizontal, and overlay layouts.
Answer:
Room is Android's recommended library for local data persistence — it provides a SQLite abstraction layer that allows working with the device's local SQLite database using type-safe Kotlin code without writing raw SQL queries for most operations.
Room was introduced as part of Android Jetpack to replace the complex, error-prone boilerplate of using SQLite directly.
The three main Room components:
Database — the main access point to the SQLite database. Annotated with @Database, it declares the entities (tables) it contains and its version number. It is an abstract class that extends RoomDatabase and provides abstract methods returning DAO instances. Room generates the implementation automatically.
Entity — a data class annotated with @Entity that represents a table in the database. Each field in the data class corresponds to a column in the table. The primary key is designated with @PrimaryKey. Column names default to the field name but can be customized with @ColumnInfo.
DAO (Data Access Object) — an interface or abstract class annotated with @Dao that defines the database operations. Methods annotated with @Insert, @Update, @Delete, and @Query perform the corresponding database operations. Room generates the implementation of DAO methods at compile time and verifies that @Query SQL statements are syntactically correct.
Why Room over raw SQLite:
Room verifies SQL queries at compile time — syntax errors are caught before the app runs. Room maps database objects to Kotlin data classes automatically — no manual cursor parsing. Room supports Kotlin Coroutines, LiveData, and Flow natively — queries can return suspend functions, LiveData, or Flow objects that notify the UI when data changes. Room's migration framework manages database schema changes across app versions.
Answer:
Retrofit is the most widely used HTTP client library for Android — it makes REST API calls simple, type-safe, and elegant by turning HTTP APIs into Kotlin interfaces. Developed by Square, Retrofit is used in the vast majority of professional Android applications that consume web services.
How Retrofit works:
You define a Kotlin interface where each method corresponds to one API endpoint. Retrofit annotations on the methods specify the HTTP method (@GET, @POST, @PUT, @DELETE), the endpoint path (@GET("users/{id}")), query parameters (@Query("page") page: Int), request body (@Body user: User), and headers (@Header("Authorization") token: String).
At runtime, you create a Retrofit instance specifying the base URL and a JSON converter (Gson or Moshi for converting JSON to Kotlin objects). You use the Retrofit instance to create an implementation of your API interface. Calling the interface methods sends the corresponding HTTP requests.
The Retrofit setup steps:
Add the Retrofit and Gson (or Moshi) dependencies to the Gradle build file. Create a data class representing the API response JSON structure. Create an API interface with annotated methods for each endpoint. Build a Retrofit instance with the base URL and converter factory. Create an API service implementation from the Retrofit instance. Call the service methods from a ViewModel using Kotlin Coroutines (suspend functions) on a background dispatcher.
Retrofit + Coroutines:
Modern Retrofit usage declares API interface methods as suspend functions — they can be called directly from coroutines without callbacks. The network call is performed on the calling coroutine's dispatcher and the result is returned when complete, making the code read like sequential synchronous code despite being asynchronous.
Answer:
Kotlin Coroutines are a language-level concurrency framework that allows writing asynchronous code that reads like sequential synchronous code — eliminating the callback complexity that previously made Android asynchronous programming difficult.
Why asynchronous code is necessary in Android:
Android's main thread (also called the UI thread) is responsible for rendering frames at 60fps. Any operation that takes longer than 16 milliseconds on the main thread blocks frame rendering — causing visible lag and unresponsiveness called "jank." Network calls (which may take hundreds of milliseconds) and database operations must never be performed on the main thread.
Before Coroutines — the callback problem:
The traditional approach used callbacks — functions passed as parameters to be called when an async operation completes. Multiple async operations chained together produced deeply nested callbacks ("callback hell") that were difficult to read, difficult to maintain, and difficult to handle errors in consistently.
How Coroutines solve this:
Coroutines use suspend functions — functions that can be paused and resumed without blocking the thread. A suspend function can perform a network call, pause while waiting for the response without blocking any thread, and resume execution when the response arrives. From the developer's perspective, the code reads sequentially — but it is genuinely asynchronous.
Coroutine Dispatchers:
Dispatchers.Main — runs on the main UI thread. Use for UI updates. Dispatchers.IO — runs on a thread pool optimized for IO-bound operations (network calls, database reads/writes). Use for Retrofit and Room operations. Dispatchers.Default — runs on a thread pool optimized for CPU-intensive operations (parsing, sorting, computation).
The viewModelScope:
In Android, ViewModels provide a built-in CoroutineScope (viewModelScope) that is automatically cancelled when the ViewModel is cleared. Launching coroutines in viewModelScope means they are automatically cleaned up when the associated screen is destroyed.
Answer:
Both launch and async start new coroutines, but they differ in whether they return a result and how they are used.
launch starts a new coroutine that does not return a result. It returns a Job object that can be used to cancel the coroutine or wait for its completion (using join()). Use launch for operations that produce side effects — making an API call and updating UI, saving data to a database, sending analytics events. The coroutine performs work but does not calculate and return a value.
async starts a new coroutine that returns a result. It returns a Deferred<T> object — a promise of a future result. To retrieve the result, call await() on the Deferred object. await() is a suspend function that suspends until the result is available. Use async when you want to run an operation concurrently with other work and retrieve its result later.
The key use case for async — parallel operations:
If you need to fetch two independent pieces of data simultaneously, launch two async coroutines and then await both results. They run in parallel — the total time is the maximum of the two individual times rather than the sum. This is more efficient than running them sequentially.
For example, fetching user profile data and user feed data simultaneously: val profile = async { api.getUserProfile() } and val feed = async { api.getUserFeed() }, then val result = Pair(profile.await(), feed.await()).
The practical rule for Android: Use launch in viewModelScope for most ViewModel operations. Use async specifically when you need concurrent parallel operations where results will be awaited.
Answer:
MVVM (Model-View-ViewModel) is the recommended architecture pattern for Android applications, officially promoted by Google through Android Jetpack. It separates the application into three distinct layers, each with a clear responsibility.
Model — represents the application's data and business logic. The Model layer includes data classes (entities), Repository classes (which abstract data sources), Room database access objects, Retrofit API service interfaces, and any business logic for processing and transforming data. The Model layer has no knowledge of the UI and no Android framework dependencies in the ideal implementation.
View — the UI layer consisting of Activities, Fragments, and Composable functions. The View's responsibilities are minimal: observe state from the ViewModel and render it, and forward user interactions (button clicks, text input) to the ViewModel. The View contains zero business logic. It does not know how data is fetched or processed — it only knows how to display what the ViewModel provides.
ViewModel — the bridge between View and Model. The ViewModel holds UI state, processes user events received from the View, calls Repository methods to fetch or modify data, and exposes the processed result as observable state (LiveData or StateFlow) that the View subscribes to. The ViewModel has no references to Activities, Fragments, or Views — making it lifecycle-independent and highly testable.
Why MVVM is recommended:
Separation of concerns — each layer has one clear responsibility. Adding a feature does not require touching all layers indiscriminately.
Testability — ViewModels can be unit tested without any Android UI infrastructure, because they have no View dependencies. Repository classes can be tested with mock data sources.
Lifecycle resilience — ViewModel survives configuration changes like screen rotation, preserving data without the View needing to refetch it.
Reactivity — LiveData/StateFlow observables ensure the UI always reflects the latest state without manual synchronization.
Answer:
The Repository Pattern is a design pattern that creates a clean abstraction layer between the data sources (Room database, Retrofit API, Firebase) and the rest of the application (specifically the ViewModel). The ViewModel calls the Repository; the Repository decides where to get the data from and how to combine multiple sources.
Why the Repository Pattern matters:
Without a repository, ViewModels would directly call Retrofit for network data and Room for local data — coupling the presentation layer to specific data source implementations. If the team decides to change from Retrofit to a different HTTP library, or from Room to a different database, all ViewModels that call those data sources would need to be modified.
With a repository, the ViewModel calls repository.getUsers(). The repository implementation decides whether to return cached data from Room, fetch fresh data from the Retrofit API, or some combination of both. If the data source changes, only the Repository changes — ViewModels are unaffected.
The offline-first pattern using Repository:
A common Repository implementation attempts to read from the local Room database first, returning the cached data immediately for a responsive UI. Then it fetches fresh data from the API in the background. When the API response arrives, it writes the new data to Room, which automatically updates any LiveData or Flow observers through Room's reactive query support.
This pattern provides instant UI response (using cached data) and eventual consistency (syncing with the server when possible) — critical for apps used in variable network conditions.
Answer:
This is a recap of Question 8 from a slightly different angle — interviewers sometimes ask this as a direct comparison question.
Explicit Intents target a specific component by its class name. The sender explicitly specifies the class of the Activity, Service, or Broadcast Receiver to start. Used exclusively for intra-app communication — navigating between screens within your own application. Android directly starts the specified component without needing to consult the system.
Implicit Intents describe an action to be performed without specifying which component handles it. Declare an action string (Intent.ACTION_VIEW, Intent.ACTION_SEND, Intent.ACTION_PICK) and optionally a data URI and MIME type. The Android system searches all installed apps for components whose Intent Filters match the declared action and data. If one match is found, it is started directly. If multiple matches exist, the system presents the user with a chooser dialog.
Security consideration: Since Android 12 (API 31), apps targeting Android 12 must specify whether each Service that can be started from other apps is exported or not — explicitly declaring whether external components can start the Service.
The practical interview point: Always use explicit Intents for within-app navigation (it is more efficient and secure). Use implicit Intents when you want the system or other apps to handle an action — opening a URL, sharing content, picking a file from the system gallery.
Answer:
Android's permission system controls which applications can access sensitive user data and device capabilities — protecting user privacy and preventing malicious apps from silently accessing dangerous features.
Normal Permissions are automatically granted by the Android system when the app is installed. They cover low-risk operations that are unlikely to be misused and do not require user approval. Examples include INTERNET (network access), ACCESS_NETWORK_STATE (check network connectivity), RECEIVE_BOOT_COMPLETED (start on device boot), and VIBRATE. These are declared in the manifest and granted automatically.
Dangerous Permissions cover access to sensitive user data or device capabilities that could affect the user's privacy or security. These must be declared in the manifest AND explicitly requested at runtime — the system shows a dialog asking the user to grant or deny the permission when the app first needs it. Examples include READ_CONTACTS, CAMERA, ACCESS_FINE_LOCATION, READ_CALL_LOG, RECORD_AUDIO, READ_EXTERNAL_STORAGE, and SEND_SMS.
Runtime Permission request flow (Android 6.0+):
Before using a dangerous permission-protected feature, check if the permission is already granted using ContextCompat.checkSelfPermission(). If not granted, request it using the ActivityResultContracts.RequestPermission() launcher. Handle the user's response in the result callback — proceed with the feature if granted, show explanation and disabled state if denied.
Signature Permissions are only granted to apps signed with the same certificate as the app that declared the permission — used for system apps and trusted app families that need to share data without user confirmation.
Runtime behavior difference (Android 6.0 Marshmallow and above): On Android 6.0 and later, users can revoke individual dangerous permissions after granting them (through Settings → Apps → Permissions). Apps must check permission status before every use, not just at first launch.
Answer:
Firebase is Google's backend-as-a-service (BaaS) platform designed specifically for mobile and web applications. It provides a comprehensive suite of tools and services that allow developers to build complete, production-quality mobile applications without building or maintaining custom server infrastructure.
For Android developers — particularly beginners — Firebase is transformative because it enables building full-stack applications (with authentication, real-time data, file storage, push notifications, and analytics) using only Android client code.
Firebase Authentication — provides complete user identity management: email/password authentication, Google Sign-In, Facebook Login, phone number (OTP) authentication, Twitter, GitHub, and anonymous authentication. Handles session management, password reset, email verification, and multi-factor authentication. An android course with firebase training covers complete Firebase Authentication integration.
Cloud Firestore — a flexible, scalable, NoSQL cloud database that stores data as documents in collections. Supports real-time synchronization — connected Android devices receive data updates instantly when other users change data. Essential for chat applications, collaborative tools, live dashboards, and social features.
Firebase Realtime Database — an older, JSON-based real-time database. Still used but Firestore is the recommended choice for new projects due to its more powerful query capabilities and better scalability.
Firebase Storage — cloud storage for user-generated files — profile photos, audio recordings, documents, and videos. Provides upload and download with progress monitoring, pause/resume, and access control rules.
Firebase Cloud Messaging (FCM) — send push notifications to individual devices, topic subscribers, or user segments. Free, highly scalable, and deeply integrated with Android's notification system.
Firebase Crashlytics — automatic crash reporting that captures every crash in production with full stack traces, device information, and user session context. Essential for monitoring app quality after release.
Firebase Analytics — automatic user session tracking, event logging, conversion funnel analysis, and audience segmentation.
Answer:
SharedPreferences is Android's built-in mechanism for storing small amounts of primitive data — key-value pairs — that persist across app launches. It stores data in an XML file on the device's internal storage and is accessible only to the app that created it (or apps with the same user ID).
What SharedPreferences stores:
Primitive data types: Boolean, Int, Float, Long, String, and Set<String>. Each value is stored with a String key and retrieved by the same key.
When to use SharedPreferences:
User preferences and settings — dark mode on/off, notification preferences, preferred language, default sort order. Login state — whether the user is logged in (store an authentication flag or session token). First-launch flags — whether to show onboarding screens. Simple user-specific settings that do not belong in a database.
When NOT to use SharedPreferences:
Large amounts of data (use Room database), sensitive data like passwords (use Android Keystore or EncryptedSharedPreferences), structured or relational data (use Room), data shared between apps (use Content Provider).
Modern replacement — DataStore:
Google recommends Jetpack DataStore as the modern replacement for SharedPreferences. DataStore comes in two flavors: Preferences DataStore (key-value, similar to SharedPreferences but using Kotlin Coroutines and Flow) and Proto DataStore (strongly typed, using Protocol Buffers). DataStore solves known SharedPreferences issues — it is asynchronous (runs on a background thread, preventing UI jank from I/O on the main thread), exception-safe, and uses Flow for observable reactive data.
Answer:
Android's file storage system has two main categories — internal storage and external storage — each with different access characteristics, privacy implications, and use cases.
Internal Storage:
Internal storage is private to the application. Files stored in internal storage are accessible only to the app that created them — other apps and users (without root access) cannot read them. Files are automatically deleted when the app is uninstalled. Always available, not removable. Good for private app data that should not be visible to users or other apps: downloaded cache files, user session data, encrypted sensitive files.
Internal storage space is limited on budget devices. Use Context.getFilesDir() for permanent files and Context.getCacheDir() for temporary files (which the system may delete when low on storage).
External Storage:
External storage was historically a removable SD card, but on modern devices "external storage" typically refers to the larger, shared storage space accessible to users through the Files app and visible when connecting to a computer. External storage is shared — other apps and users can access files stored there.
Since Android 10 (Scoped Storage), apps can no longer freely access the external storage filesystem. Each app has its own external storage directory (getExternalFilesDir()) that is exclusive to that app. Accessing other apps' files or the broader media collection requires using MediaStore APIs or the Storage Access Framework, both of which require user interaction or specific permissions.
Scoped Storage (Android 10+):
Scoped Storage restricted broad external storage access to protect user privacy. Apps access their own external files without permissions. Accessing shared media (photos, videos, audio) requires READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, or READ_MEDIA_AUDIO permissions. Accessing arbitrary files requires the Storage Access Framework where the user explicitly picks files through the system file picker.
Answer:
Broadcast Receivers are Android components that allow applications to receive and respond to system-wide or application-specific broadcast messages. Broadcasts are events published by the Android system or by other applications — and Broadcast Receivers subscribe to receive specific broadcasts.
Common system broadcasts:
android.intent.action.BOOT_COMPLETED — device has finished booting. android.net.conn.CONNECTIVITY_CHANGE — network connectivity has changed. android.intent.action.BATTERY_LOW — battery is below the warning level. android.intent.action.SCREEN_ON / SCREEN_OFF — screen turned on or off. android.intent.action.ACTION_POWER_CONNECTED — charger was connected.
Two ways to register a Broadcast Receiver:
Static registration (Manifest-declared): Declare the receiver in AndroidManifest.xml with an intent-filter. The receiver is registered when the app is installed and can receive broadcasts even when the app is not running. Used for receivers that must respond to system events regardless of app state (boot complete, for example).
Note: Since Android 8.0 (Oreo), most implicit broadcast receivers cannot be registered statically in the manifest — they must be registered dynamically. Static registration is still allowed for explicit broadcasts and specific exempt system broadcasts.
Dynamic registration (Code-registered): Create an instance of the BroadcastReceiver in code and register it using context.registerReceiver(receiver, intentFilter). The receiver is active only while the registering component is alive and the receiver is registered. Always unregister in the corresponding lifecycle method (onPause() or onStop()) using context.unregisterReceiver(receiver) to prevent memory leaks. Used for receivers that should only respond while the Activity is visible.
Answer:
Dependency Injection (DI) is a design pattern where an object's dependencies (the objects it needs to function) are provided to it from outside rather than created by the object itself. Instead of a ViewModel creating its own Repository instance directly, the Repository is "injected" into the ViewModel by an external mechanism.
Why Dependency Injection matters:
Without DI, classes create their own dependencies — making them tightly coupled to specific implementations, difficult to test (because you cannot substitute mock implementations), and hard to change (changing a dependency requires changing every class that creates it).
With DI, classes declare what they need and receive those dependencies through their constructor. Testing becomes easy — inject mock implementations in tests. Changing implementations requires only one change at the injection point, not in every class that uses the dependency.
Hilt — Android's Recommended DI Framework:
Hilt is Google's recommended dependency injection library for Android, built on top of Dagger 2. It uses annotations to automatically generate the dependency injection wiring code at compile time.
Key Hilt annotations: @HiltAndroidApp on the Application class (enables Hilt for the entire app). @AndroidEntryPoint on Activities, Fragments, Services, and Views (enables injection in those components). @Inject on constructors (marks a class as injectable and declares its dependencies). @HiltViewModel on ViewModels (enables injection in ViewModels). @Provides and @Binds in @Module classes (for dependencies that require custom construction).
The practical benefit for beginners:
Without Hilt, setting up ViewModel with a Repository that depends on a Room database and a Retrofit service requires a ViewModelFactory, manual object construction, and significant boilerplate. With Hilt, you annotate the classes and Hilt generates all the wiring automatically.
Answer:
The Navigation Component is a Jetpack library that simplifies implementing navigation between screens in Android apps. Before Navigation Component, moving between Activities and Fragments required manual Intent creation, Fragment transactions, back stack management, and argument passing — all of which were verbose, error-prone, and inconsistent across codebases.
What Navigation Component provides:
Navigation Graph — an XML resource file that visually represents all screens (destinations) in the app and the connections (actions) between them. The NavGraph is visible as a visual diagram in Android Studio's Navigation Editor, making the app's navigation structure immediately clear.
NavController — the object that manages navigation within the Navigation Graph. Call navController.navigate(R.id.action_home_to_detail) to navigate to the detail screen. Call navController.navigateUp() to go back. The NavController handles all back stack management automatically.
NavHost — a container in the layout that hosts the Navigation Graph and displays the current destination's Fragment. NavHostFragment is the most common implementation.
Safe Args — a Gradle plugin that generates type-safe Kotlin classes for passing arguments between destinations. Instead of putting arbitrary objects in Bundle with string keys (error-prone), Safe Args generates a typed Directions class and an Args class that enforce correct argument types at compile time.
Deep linking — Navigation Component supports both explicit deep links (programmatic navigation to specific screens from notifications) and implicit deep links (handling URLs that should open specific screens).
Single-Activity architecture enablement:
Navigation Component is the technical foundation that makes single-Activity architecture practical — one Activity hosts a NavHostFragment, and every screen is a Fragment destination in the navigation graph. The NavController manages all transitions, back stack, and argument passing.
Answer:
These three version declarations in the Android module's build.gradle file control different aspects of how the app is compiled and deployed.
compileSdk (also called compileSdkVersion) — the Android API version that the app is compiled against. Setting compileSdk to 35 means the compiler uses Android 15's API definitions. This determines which APIs are available to use during compilation — APIs above the compileSdk version will show compiler errors. The compileSdk should always be set to the latest stable API version to access the newest APIs and compiler checks. Users never see this version — it only affects compilation.
minSdk (also called minSdkVersion) — the minimum Android API version that the app supports. Devices running Android versions below minSdk cannot install the app (the Play Store filters it out). Setting minSdk to 24 means the app supports Android 7.0 and above. Lower minSdk reaches more devices but requires more compatibility code for older API versions. The choice involves a trade-off between broad device support and code complexity.
targetSdk (also called targetSdkVersion) — the Android API version that the app is designed and tested for. Android uses targetSdk to determine which runtime behaviors to apply. When a new Android version introduces behavior changes, devices running that version only apply those changes to apps with targetSdk equal to or above that version — allowing existing apps to continue working until developers update targetSdk after testing. The Play Store requires targeting a recent API level (within one or two major versions of the latest Android).
The practical rule: compileSdk = latest Android version. targetSdk = latest Android version (after testing). minSdk = based on the oldest Android version you want to support.
Answer:
ANR (Application Not Responding) is an Android system error that occurs when an application's main UI thread is blocked for too long. Android shows the ANR dialog when the main thread does not respond to user input for more than 5 seconds, or when a Broadcast Receiver does not finish executing within 10 seconds.
When an ANR occurs, users see a dialog saying the app is not responding with options to "Wait" or "Close App." ANRs severely damage user experience, generate negative Play Store reviews, and are tracked in Android Vitals as a quality metric that affects app visibility in Play Store search.
What causes ANRs:
Performing network calls on the main thread — network operations can take seconds and must never be on the main thread. Database queries on the main thread — reading/writing to SQLite on the main thread blocks UI. Performing heavy computation (parsing, sorting, image processing) on the main thread. Waiting for synchronization locks that other threads hold. Complex layout inflation or custom View drawing that takes too long.
How to prevent ANRs:
Move all non-UI work off the main thread using Kotlin Coroutines with Dispatchers.IO for IO operations and Dispatchers.Default for CPU-intensive work. Room and Retrofit are configured to automatically run on background threads when used with Coroutines — but only if called from a coroutine launched with the appropriate dispatcher.
Use Android's StrictMode during development — it logs warnings when operations like disk reads and network calls are incorrectly performed on the main thread.
Profile with Android Studio's CPU Profiler to identify long-running operations on the main thread and move them to background threads.
Answer:
When passing objects between Android components — between Activities via Intents, between Fragments via arguments — the objects must be serialized (converted to a form that can be transmitted). Android provides two mechanisms for this: Java's built-in Serializable interface and Android's Parcelable interface.
Serializable:
Serializable is Java's built-in serialization interface — simply implement Serializable on your data class and the Java reflection mechanism handles converting the object to bytes automatically. Implementation is trivially simple — just add "implements Serializable" (Java) or the Serializable marker to the class.
The significant drawback is performance — Java serialization uses reflection to inspect the class structure at runtime, which is slow and creates many temporary objects, increasing garbage collection pressure.
Parcelable:
Parcelable is Android's own serialization mechanism, designed specifically for high-performance inter-process communication (IPC). The developer explicitly implements writeToParcel() (writing each field to a Parcel in order) and a CREATOR static object that reads fields from the Parcel in the same order. There is no reflection — Parcelable uses explicit, ordered field reading and writing that is significantly faster than Serializable.
Parcelable is the recommended approach for Android development because of its performance advantage in the IPC scenarios that Android uses it for.
@Parcelize Kotlin extension:
Kotlin provides the @Parcelize annotation (from the kotlin-parcelize plugin) that automatically generates the Parcelable implementation at compile time — giving you Parcelable's performance without manually writing writeToParcel() and CREATOR. Simply annotate your data class with @Parcelize and implement Parcelable as an interface — the plugin generates the rest.
Answer:
ViewBinding is a feature that generates a binding class for each XML layout file in the project. Each generated binding class contains direct references to all Views in the corresponding layout that have IDs — allowing you to access Views directly through the binding object without any casting or null checks.
The problem ViewBinding solves:
The traditional approach used findViewById<T>(R.id.someView) to access Views from code. This approach has two significant problems: it is verbose (especially with many Views) and it is type-unsafe. If you reference the wrong View ID or use the wrong type, the error is not caught until runtime when the app crashes with a ClassCastException or returns null.
How ViewBinding works:
Enable ViewBinding in the module's build.gradle by setting viewBinding { enabled = true }. Android automatically generates a binding class for every layout — a layout named activity_main.xml generates a class called ActivityMainBinding. In the Activity, inflate the binding class in onCreate(): binding = ActivityMainBinding.inflate(layoutInflater). Access Views through the binding: binding.textViewTitle.text = "Hello" — no casting, no null risk, compile-time type safety.
ViewBinding vs DataBinding:
DataBinding is an older, more powerful alternative that also allows binding data directly to XML layouts (two-way data binding, binding expressions). ViewBinding is simpler, faster to compile, and sufficient for most use cases — it provides direct View references without the complexity of DataBinding's XML expression language. ViewBinding is the recommended choice for most projects.
ViewBinding vs Kotlin Synthetics:
Kotlin Synthetics (the kotlin-android-extensions plugin) was previously popular for direct View access but was deprecated by Google. ViewBinding replaces it with proper null safety and support for multi-module projects.
Answer:
A CoroutineScope defines the lifecycle of coroutines launched within it — when the scope is cancelled, all coroutines running in it are cancelled automatically. Scopes are how Android prevents coroutine memory leaks — without proper scoping, a coroutine started by an Activity would continue running even after the Activity is destroyed.
viewModelScope:
viewModelScope is a pre-built CoroutineScope provided by the lifecycle-viewmodel-ktx library that is automatically tied to the ViewModel's lifecycle. Any coroutine launched in viewModelScope is automatically cancelled when the ViewModel's onCleared() is called — which happens when the associated Activity or Fragment is permanently destroyed (not during rotation).
Use viewModelScope for any coroutine launched from a ViewModel — network requests, database operations, any async work initiated by user interactions. This ensures long-running operations are cancelled when the screen is permanently left and there is no active UI to receive their results.
lifecycleScope:
lifecycleScope is a CoroutineScope tied to an Activity or Fragment's lifecycle. Coroutines launched in lifecycleScope are cancelled when the Activity or Fragment is destroyed. Used for coroutines that need to run within the UI layer — collecting StateFlow or Flow in an Activity or Fragment, animating UI based on flow emissions.
repeatOnLifecycle — the correct way to collect Flows in UI:
Simply launching a coroutine with lifecycleScope.launch { flow.collect() } collects the flow even when the Fragment is not visible (in the STOPPED state) — potentially processing data with no visible UI to display it. repeatOnLifecycle(Lifecycle.State.STARTED) wraps collection in a block that is cancelled when the lifecycle drops below STARTED and restarted when it returns to STARTED — ensuring collection only happens when the UI is visible.
Answer:
Navigation Component manages the app's navigation — the path through which users move between screens. The Back Stack is Navigation Component's record of where the user has been — a stack of destinations where the most recently visited screen is at the top.
When a user navigates to a new destination using navController.navigate(), that destination is pushed onto the back stack. When the user presses the back button, Navigation Component pops the current destination off the back stack and the previous destination becomes active again.
Back Stack management options:
popUpTo — navigate to a destination while popping all destinations down to (and optionally including) a specified destination from the back stack. Used to implement "don't go back to login screen after logging in" — navigate to home screen with popUpTo(R.id.loginFragment) { inclusive = true } removes the login screen from the back stack.
launchSingleTop — if the target destination is already at the top of the back stack, do not create a new instance — reuse the existing one. Prevents adding duplicate screens when the user taps the same navigation destination repeatedly.
saveState and restoreState — when navigating between bottom navigation tabs, save the state of each tab's back stack when leaving and restore it when returning. This provides the standard bottom navigation behavior where each tab remembers its navigation state independently.
NavBackStackEntry and result handling:
Passing results back from a popped destination (like returning a selected item from a picker screen) uses the previous destination's NavBackStackEntry's SavedStateHandle — a lifecycle-safe way to communicate results between destinations.
Answer:
Android provides multiple storage options for different types of data and different access requirements.
SharedPreferences / DataStore — key-value storage for small amounts of primitive data (settings, preferences, simple flags). Private to the app. SharedPreferences is the older API; Jetpack DataStore is the modern replacement with coroutine support.
Internal Storage (Files) — private file storage in the app's internal directory. No permissions needed. Deleted on uninstall. Good for private files, cache data, and sensitive information.
External Storage (App-Specific) — files in the app's dedicated external storage directory (getExternalFilesDir()). No permissions needed on Android 4.4+. Accessible to users through the file manager but deleted on uninstall. Good for larger files (downloaded documents, exported reports) that users might want to access directly.
MediaStore (Shared Media) — accessing and storing shared media (photos, videos, audio) in the device's media collection. Requires READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO permissions to read other apps' media. Writing new media to MediaStore does not require permissions.
Room Database — local SQLite database with type-safe Kotlin access. For structured, relational data of any size. Private to the app. Persists through app launches.
Firebase / Remote Database — cloud-hosted data (Firestore, Realtime Database). Accessible from all user devices, synced in real time. Requires internet connectivity and Firebase project setup.
Android Keystore — secure storage specifically for cryptographic keys and sensitive credentials. Keys stored in the Keystore cannot be extracted from the device — operations are performed within the secure hardware or OS security environment.
Answer:
In Retrofit, HTTP method annotations define what type of HTTP request is made when an API interface method is called. The choice of @GET, @POST, @PUT, or @DELETE reflects the semantic intent of the API operation based on REST conventions.
@GET is used for data retrieval operations — requests that read data without modifying server state. GET requests send any parameters in the URL itself — either as path variables (@Path) or query parameters (@Query). GET requests have no request body. Fetching a list of products, getting a user's profile, or retrieving a news feed are GET operations.
@POST is used for creating new resources or submitting data that triggers server-side processing. POST requests carry data in the request body (@Body annotation) — typically a JSON object representing the new resource or the form data being submitted. Creating a new user account, submitting a purchase order, or posting a new comment are POST operations.
@PUT — updates an existing resource by replacing it entirely. Typically sends the complete updated resource as the request body.
@DELETE — deletes a resource identified by the URL.
@PATCH — partially updates an existing resource — sends only the fields that have changed rather than the complete resource.
Practical code example: @GET("users") suspend fun getUsers(@Query("page") page: Int): Response<List<User>> makes a GET request to the "users" endpoint with a "page" query parameter. @POST("users") suspend fun createUser(@Body user: CreateUserRequest): Response<User> makes a POST request with the user object serialized as JSON in the request body.
Answer:
ProGuard and R8 are code optimization and obfuscation tools that process Android app code during the release build process. They perform three main functions: shrinking, obfuscating, and optimizing.
Shrinking (Tree Shaking) — removes unused code and resources from the app. Android apps include many libraries, and most apps use only a fraction of each library's code. Shrinking eliminates the unused portions — reducing the final APK/AAB size significantly. This is particularly important for reducing download size for Play Store distribution.
Obfuscation — renames classes, methods, and fields with short, meaningless names (a, b, c) — making the compiled code significantly harder to reverse-engineer. This protects business logic and algorithms in the app from being easily extracted by decompiling the APK.
Optimization — rewrites code to be more efficient — inlining methods, removing dead code branches, and applying other compiler-level optimizations that improve runtime performance.
R8 vs ProGuard:
R8 is Google's replacement for ProGuard, integrated directly into the Android Gradle plugin since Android Studio 3.4. R8 performs all the same functions as ProGuard but more efficiently — it combines shrinking, desugaring, and dex compilation into a single step, making the build process faster. R8 is the default code shrinker in modern Android builds.
Enabling R8/ProGuard:
Set minifyEnabled = true in the release build type configuration in build.gradle. Provide a proguard-rules.pro file specifying rules that tell R8/ProGuard which classes and methods must be kept (not obfuscated or removed) — particularly classes accessed by reflection, Retrofit model classes, and Room entities.
Answer:
Both Toast and Snackbar display brief messages to users, but they differ in appearance, behavior, and recommended use cases.
Toast is a simple, floating message overlay that appears briefly at the bottom of the screen (by default) and automatically disappears after a short or long duration. Toast is lightweight — created with a single line: Toast.makeText(context, "Message", Toast.LENGTH_SHORT).show(). Toast has no action buttons, cannot be dismissed by the user, and floats above all app content. Toast messages queue up — multiple rapid Toasts cause messages to display one after another in sequence, which can be confusing. Toast appears even if the user has navigated away from the screen.
Snackbar appears at the bottom of the Activity or inside a CoordinatorLayout and provides more user-friendly messaging. Unlike Toast, Snackbar: can include an action button (typically "UNDO" or "DISMISS"), respects CoordinatorLayout animations (the floating action button moves up to avoid being covered), can be dismissed by swiping, and replaces previous Snackbars immediately rather than queuing. Snackbar is the Material Design recommended alternative to Toast for most use cases.
When to use each:
Toast: Simple informational messages that do not require any action — "Message sent", "Downloaded successfully". The simplicity of Toast makes it appropriate for non-critical feedback in contexts where the user does not need to take follow-up action.
Snackbar: Confirmations of potentially reversible actions ("Item deleted" with an "UNDO" action), brief status updates, or any message where user acknowledgment or action is possible. The Material Design guidelines recommend Snackbar over Toast for most in-app messages.
Answer:
AsyncTask was an Android class designed to simplify performing background operations and publishing results on the UI thread. Introduced in the earliest Android versions, it allowed developers to define background work in doInBackground() and UI updates in onPostExecute() without manually managing threads and Handler.
Why AsyncTask was popular:
It solved a real problem — performing work off the main thread — with a simple API that beginners could use immediately. Before Kotlin Coroutines, it was the recommended approach for simple background operations.
Why AsyncTask was deprecated in Android 11 (API 30):
Memory leaks — AsyncTask typically held a reference to the Activity that created it. If the Activity was destroyed (by rotation or navigation) while the AsyncTask was running, the Activity could not be garbage collected, causing a memory leak. The AsyncTask would attempt to update a destroyed Activity's Views in onPostExecute(), causing crashes.
Lifecycle unawareness — AsyncTask had no knowledge of its host component's lifecycle. It could not automatically cancel when the Activity was destroyed or pause when the Activity was stopped.
Concurrency issues — AsyncTask had a confusing history of whether tasks executed in parallel or serially, leading to unpredictable behavior in apps that used multiple AsyncTasks.
The modern replacement:
Kotlin Coroutines with viewModelScope completely replace AsyncTask — they are lifecycle-aware (automatically cancelled when the ViewModel is cleared), exception-safe, and significantly more readable. Any android app development full course online now teaches Coroutines as the standard for background operations rather than AsyncTask.
Answer:
Android Jetpack is a collection of libraries, tools, and guidance from Google that helps Android developers follow best practices, reduce boilerplate code, and write apps that work consistently across Android versions and device configurations.
Jetpack libraries address four categories of Android development needs:
Architecture components — ViewModel, LiveData, Room, DataStore, Paging, WorkManager, and Navigation Component. These libraries help implement MVVM architecture, manage data persistence, handle background work, and implement navigation.
UI components — Jetpack Compose (modern declarative UI toolkit), RecyclerView, ViewPager2, ConstraintLayout, CoordinatorLayout, and various Material Design component implementations.
Behavior libraries — Notifications, Permissions, Sharing, Slices, and the CameraX library for camera integration.
Foundation libraries — AppCompat (backward compatibility for modern features on older Android versions), KTX extensions (Kotlin extension functions that make Android APIs more idiomatic), Test (testing infrastructure for Android), and Multidex (for apps that exceed the 64K method limit).
The most important Jetpack libraries for fresher interviews:
ViewModel and LiveData/StateFlow — for lifecycle-aware state management. Room — for local database persistence. Navigation Component — for screen navigation. WorkManager — for guaranteed background task execution. DataStore — for key-value preferences storage. Hilt — for dependency injection. CameraX — simplified camera integration. Paging 3 — efficient loading of large data sets.
All modern Android development relies heavily on Jetpack libraries — any quality android training online with live projects covers the core Jetpack components comprehensively.
Answer:
WorkManager is a Jetpack library for scheduling deferrable background work that must be guaranteed to execute even if the app exits or the device restarts. It is the recommended solution for any background task that needs to run reliably regardless of app lifecycle.
What makes WorkManager different from coroutines:
Kotlin Coroutines are excellent for background work while the app is running. But coroutines are cancelled when the app process is killed. If a user starts a file upload and then force-closes the app, the coroutine dies and the upload stops.
WorkManager persists work across app restarts and device reboots by storing pending work in an internal database and rescheduling it when the app restarts. Work constraints can ensure it only runs when conditions are met.
WorkManager use cases:
Uploading logs or analytics data to a server. Syncing app data with a backend in the background. Sending queued messages when network connectivity is available. Periodic data refresh tasks that should run even if the app is not open. Applying filters to images before saving.
WorkManager constraints:
Work can be constrained to run only under specific conditions: NetworkType (CONNECTED, METERED, UNMETERED, NOT_REQUIRED), BatteryNotLow (only run when battery is not critically low), RequiresCharging (only run when charging), DeviceIdle (only run when device is not in active use), StorageNotLow (only run when storage is not critically low).
WorkManager chaining:
WorkManager supports chaining work — running tasks sequentially (A must complete before B starts) or in parallel (run A and B simultaneously, then proceed to C when both complete). This enables complex background processing pipelines.
Answer:
This data structure question tests programming knowledge beyond Android-specific concepts — interviewers assess whether candidates have solid programming foundations.
HashMap is an unordered map implementation. The iteration order of entries in a HashMap is not guaranteed — it depends on hash codes and may change as entries are added or removed. HashMap provides O(1) average time complexity for get, put, and remove operations. Use HashMap when you only need key-value lookup and iteration order is unimportant.
LinkedHashMap is a HashMap that additionally maintains a doubly-linked list connecting all entries in insertion order (or optionally in access order). This linked list defines the iteration order — iterating a LinkedHashMap yields entries in the order they were inserted. LinkedHashMap has slightly higher memory overhead than HashMap (due to the linked list) and marginally slower performance, but provides predictable iteration order.
TreeMap — a third related data structure — stores entries in sorted order by key (natural ordering or a custom Comparator). TreeMap has O(log n) operations (slower than HashMap's O(1)) but produces sorted iteration.
Practical Android use cases:
HashMap — caching API response data by ID for fast lookup, storing event listeners by key. LinkedHashMap — implementing LRU (Least Recently Used) cache (override removeEldestEntry()), maintaining insertion order when order matters for display. TreeMap — sorting configuration options, maintaining alphabetically ordered data.
In Kotlin, mapOf() creates an immutable LinkedHashMap (preserving insertion order). hashMapOf() creates a HashMap. You rarely need to specify the implementation explicitly in application code — but knowing the difference is expected in technical interviews.
Answer:
The Application class is the base class for maintaining global application state. Before any Activity, Service, or Broadcast Receiver is created, Android instantiates the Application class. It exists for the entire lifetime of the application process.
When to use a custom Application class:
Initializing third-party libraries and SDKs that must be set up before any other app code runs — Firebase.initializeApp(), Timber.plant() for logging, Hilt's application setup.
Setting up global configuration — analytics initialization, crash reporting setup, global HTTP client configuration.
Managing application-level resources that should persist across the entire app lifetime.
How to create a custom Application class:
Create a class that extends Application and override onCreate(). In AndroidManifest.xml, add android:name=".YourApplicationClass" to the <application> tag. Android will instantiate your class as the Application singleton for the entire process lifetime.
The @HiltAndroidApp annotation:
With Hilt for dependency injection, the Application class must be annotated with @HiltAndroidApp — which triggers Hilt's code generation and sets up the application-level dependency injection component. Without this annotation, Hilt cannot function.
What NOT to do in Application class:
The Application class should not hold references to Activities or UI components — it outlives all UI components and keeping references to them prevents garbage collection. Heavy initialization that could be deferred should be lazy — initialize expensive resources on first use rather than in Application.onCreate(), which runs before the first screen appears.
Answer:
Understanding error types helps developers debug more efficiently and write more reliable code — a foundational programming concept tested in many fresher interviews.
Compile-time errors are detected by the compiler before the app is built and run. The IDE (Android Studio) shows them as red underlines, and attempting to build the project fails. The developer must fix compile-time errors before the app can run.
Examples of compile-time errors in Kotlin/Android: referencing a variable that has not been declared, calling a function with the wrong number or type of arguments, assigning a value of the wrong type, using a null-unsafe operation on a nullable type without null checking, missing required function override in an abstract class.
Runtime errors occur after the app is successfully compiled and is running. They manifest as crashes (exceptions) while the user is using the app. The most common runtime errors in Android are NullPointerException (trying to use a null reference), ClassCastException (incorrectly casting an object to an incompatible type), ArrayIndexOutOfBoundsException (accessing an array index that does not exist), NetworkOnMainThreadException (attempting a network call on the main thread), and OutOfMemoryError (app exhausted available memory).
Why Kotlin reduces runtime errors:
Kotlin's null safety type system converts many NullPointerExceptions from runtime errors to compile-time errors. The compiler refuses to compile code that dereferences a nullable value without a null check — catching these errors before the app runs rather than in production.
Logcat for runtime debugging:
When runtime errors occur, Android logs a stack trace to Logcat — the detailed log viewer in Android Studio. Reading the stack trace identifies exactly which line of code caused the crash, making runtime errors much easier to diagnose than they would be without this information.
Answer:
Sealed classes are a Kotlin feature that restricts class hierarchies — a sealed class can only be subclassed within the same file or package where it is declared. This restriction allows the compiler to know all possible subclasses at compile time, enabling exhaustive when expressions.
Why sealed classes are powerful:
When you use a sealed class in a when expression, Kotlin's compiler enforces that every possible subclass is handled. If you add a new subclass later, every when expression using the sealed class produces a compile-time error until the new case is handled — preventing silent runtime bugs from unhandled cases.
The most common Android use case — UI State representation:
A sealed class with subclasses representing Loading, Success, and Error states is the standard pattern for representing the result of an async operation that a ViewModel exposes to the UI.
sealed class UserState { data class Success(val user: User) : UserState() data class Error(val message: String) : UserState() object Loading : UserState() }
The ViewModel exposes a StateFlow<UserState>. The UI collects this flow and uses a when expression — which the compiler verifies handles all three states. Adding a new state (like Empty) causes a compile-time error in every when expression that handles UserState until Empty is handled.
Sealed class vs Enum:
Enum classes represent a fixed set of constants — each variant is a singleton with no data. Sealed class variants can carry different data (Success carries a user object, Error carries an error message). Sealed classes are more flexible when variants need different associated data.
Results and error handling:
Kotlin's built-in Result<T> sealed type and common patterns like Either<Error, Success> use the same concept for functional error handling in repositories and use cases.
Answer:
Lazy loading (also called lazy initialization or on-demand loading) is the pattern of deferring the creation or loading of an object or resource until it is actually needed — rather than eagerly creating everything at startup.
Kotlin's lazy delegate:
Kotlin provides a built-in lazy delegate for property initialization: val heavyObject: HeavyObject by lazy { HeavyObject() }. The lambda is executed only when heavyObject is first accessed — not when the class is instantiated. Subsequent accesses return the cached instance. By default, lazy is thread-safe.
Why lazy initialization matters in Android:
Activities and Fragments are frequently created and destroyed. Eagerly initializing expensive objects in onCreate() regardless of whether they are needed on this particular screen visit wastes memory and slows screen startup time. Lazy initialization ensures objects are only created when used.
Lazy loading in lists — Paging 3:
The Paging 3 library implements lazy loading for list data. Instead of fetching all items from an API or database at once (which is slow and memory-intensive for large lists), Paging 3 loads data in pages — fetching only the first page initially and loading additional pages as the user scrolls near the end of the currently loaded data. RecyclerView integration with PagingAdapter handles the visual smoothness of this incremental loading transparently.
Image lazy loading:
Loading images from the network or disk for every visible item in a list simultaneously would be extremely slow and memory-intensive. Image loading libraries (Coil, Glide, Picasso) load images lazily — each image is loaded only when its ImageView is about to become visible on screen — and cache loaded images in memory and disk to avoid redundant network requests.
Answer:
Extension functions are a Kotlin feature that allows adding new functions to existing classes without inheriting from them or modifying their source code. You can add a function to String, Context, View, or any other class — even classes from libraries you cannot modify — as if it were a member function of that class.
The syntax:
fun ClassName.newFunctionName(parameters): ReturnType { /* body */ }
Inside the extension function body, this refers to the instance of the class the function is called on.
Android development examples:
Adding a visible() extension function to View:
fun View.visible() { this.visibility = View.VISIBLE } fun View.gone() { this.visibility = View.GONE }
Now any View can call: textView.visible() and imageView.gone() — readable, concise, and reusable.
Adding a showToast extension to Context:
fun Context.showToast(message: String, duration: Int = Toast.LENGTH_SHORT) { Toast.makeText(this, message, duration).show() }
Now inside any Activity or Fragment: showToast("Operation successful") — no need to write Toast.makeText(this, ...) every time.
Adding a formatCurrency extension to Double or Long:
fun Long.formatAsCurrency() = "₹${"%,.0f".format(this)}"
Why extension functions are valuable in Android:
They reduce repetitive boilerplate throughout the codebase. They make APIs more fluent and readable. They allow utility functions to be expressed as methods on the relevant type rather than as static utility class methods. Kotlin Android Extensions used extension functions extensively — ViewBinding and KTX libraries use extension functions to make Android APIs more idiomatic in Kotlin.
Answer:
Coil (Coroutine Image Loader) is a modern, Kotlin-first image loading library for Android that uses Kotlin Coroutines for asynchronous operations. It is the recommended image loading library for new Android projects in 2026, particularly those using Kotlin and Jetpack Compose.
Why dedicated image loading libraries are necessary:
Loading images efficiently in Android lists and grids requires: asynchronous loading off the main thread (to prevent UI lag), memory caching of recently loaded images (to avoid reloading images when scrolling back), disk caching of downloaded images (to avoid re-downloading on each app launch), downsampling images to the display size (to avoid holding 20MB original photos in memory when displaying 100×100px thumbnails), and request cancellation when the ImageView's item scrolls out of view.
Implementing all of this correctly from scratch is complex. Image loading libraries handle all of it transparently.
Why Coil specifically:
Coil was built from scratch with Kotlin and Coroutines — it uses coroutines internally for all async operations and integrates naturally with Kotlin code. Its API is clean and concise. It has first-class Jetpack Compose support through a separate compose artifact. Coil is maintained actively and keeps pace with Android's latest recommendations.
Basic Coil usage:
For ImageView: imageView.load(imageUrl) { crossfade(true); placeholder(R.drawable.placeholder); error(R.drawable.error) }
For Jetpack Compose: AsyncImage(model = imageUrl, contentDescription = "description")
Alternatives: Glide (Google's recommended library, Java-centric but Kotlin-friendly) and Picasso (Square's library, older but reliable) are also widely used in existing Android codebases.
Answer:
Data classes are a Kotlin feature specifically designed for classes whose primary purpose is to hold data. They are extremely common in Android development — used for API response models, database entities, UI state objects, and any class that primarily stores values.
How to declare a data class:
data class User(val id: Int, val name: String, val email: String)
What data classes automatically provide:
equals() and hashCode() — generated based on all properties declared in the primary constructor. Two User objects with the same id, name, and email are considered equal, and collections use this for proper deduplication.
toString() — returns a readable string like "User(id=1, name=John, email=[email protected])" — invaluable for logging and debugging.
copy() — creates a copy of the object with optionally modified properties. val updatedUser = user.copy(email = "[email protected]") — immutable update pattern.
componentN() functions — enable destructuring declarations: val (id, name, email) = user.
Important limitations:
Data classes cannot be abstract, open, sealed, or inner classes (in some contexts). Only the properties declared in the primary constructor are included in equals(), hashCode(), toString(), and copy(). Properties declared in the class body are excluded from these generated functions.
Use in Android:
Retrofit API response models are data classes — Gson/Moshi deserializes JSON into data class instances. Room entities are often data classes. ViewModel state classes are commonly data classes (especially with sealed classes for state representation). ViewHolder data objects in RecyclerView adapters are data classes.
Answer:
This question tests self-awareness, preparation quality, and genuine understanding of what professional Android development requires. A thoughtful, honest answer makes a strong lasting impression.
Build a portfolio of complete, demonstrable Android apps before interviewing.
Conceptual knowledge without project experience is not sufficient at the fresher level. Interviewers want to discuss code you have actually written. A portfolio of 2 to 3 complete Android apps — pushed to GitHub with documentation — demonstrates that you can apply concepts, not just recite them. An e-commerce app, a news/weather app, and a social feature app cover the most important Android skills: REST API integration, local database, Firebase, and MVVM architecture.
Know your projects deeply.
You will be asked why you used MVVM instead of MVC. Why you chose Firebase over a REST backend for a specific feature. How you handled the Activity lifecycle in a specific screen. What would have broken without your wait conditions or error handling. Be prepared to defend every technical decision with specific reasoning.
Master the Activity Lifecycle completely.
Lifecycle questions appear in nearly every Android fresher interview. Know not just what each lifecycle method is called for — but when each method is called, what state the Activity is in during each method, and what operations are appropriate or inappropriate in each method.
Practice writing Android code without IDE autocomplete.
Many technical rounds ask you to write code snippets on paper or whiteboard. Practice writing basic RecyclerView Adapter, Room DAO, Retrofit interface, ViewModel with StateFlow, and basic Coroutine usage from memory.
Learn Kotlin idioms, not just Java syntax in Kotlin.
Kotlin-specific features — data classes, extension functions, sealed classes, coroutines, null safety — should be natural in your code. Using Kotlin in a Java style (writing getters/setters, using callbacks instead of coroutines) signals that you have not genuinely learned the language.
Understand MVVM at the architectural level.
Know not just what MVVM is but why each layer exists — what problem the ViewModel solves (lifecycle), why the Repository exists (data source abstraction), why the View contains no logic. Explaining the reasoning demonstrates understanding rather than memorization.
Your GitHub portfolio is your resume. Before applying, ensure every Android project has a meaningful README with screenshots, a description of features, the technologies used, and setup instructions. Interviewers who review your GitHub profile before the interview already know your skill level when you walk in.
Know the full Jetpack ecosystem. Room, ViewModel, LiveData, Navigation Component, WorkManager, DataStore — these are not optional advanced topics. They are the standard building blocks of modern Android apps and are expected in fresher interviews in 2026.
Practice Kotlin beyond Android. Solid Kotlin knowledge — coroutines, sealed classes, extension functions, data classes, null safety, collections API — is tested alongside Android knowledge. Weak Kotlin skills are immediately apparent and consistently eliminate candidates.
Be honest about what you do not know. "I have not worked with that specific library, but I understand the concept and here is how I would approach learning it" is a more impressive answer than a vague guess. Intellectual honesty combined with clear reasoning impresses interviewers.
Understand why, not just what. The most impressive fresher answers explain the reasoning behind Android design decisions — why Activities have a lifecycle, why ViewModel is lifecycle-independent, why RecyclerView recycles views, why Kotlin's null safety prevents crashes. Understanding the reasoning demonstrates depth that memorized definitions do not.
At JustAcademy, the android app development course is specifically designed to make freshers genuinely interview-ready — with real project experience, deep conceptual training, and dedicated placement support.
Complete Android Stack Training JustAcademy covers everything tested in fresher interviews: Kotlin fundamentals, Activity/Fragment lifecycle, RecyclerView, MVVM architecture, Jetpack libraries (Room, ViewModel, Navigation, WorkManager), Retrofit, Firebase integration, Jetpack Compose, and Play Store publishing.
Live Projects That Interviewers Ask About You build complete Android applications from scratch — not tutorial copies. Every concept is immediately applied in a working app. Portfolio apps include e-commerce, social media, and news/weather applications that demonstrate the full professional Android development stack.
Android Certification with Industry Recognition JustAcademy's android certification course online with projects is recognized by 650+ hiring partner companies — documented project competency that differentiates graduates in competitive job applications.
Mock Technical Interviews Dedicated mock interview sessions simulating real fresher Android interview conditions — conceptual questions, code writing exercises, and project walkthrough practice.
Active Placement Until Hired JustAcademy's placement team actively refers students to job openings at hiring partner companies, prepares them for specific company interviews, and provides ongoing support until the first Android developer role is secured. 95% placement rate.
Online and Offline — Both Available Whether you prefer android online classes with flexible scheduling and live sessions, or structured offline classroom training with direct mentorship — JustAcademy provides both formats with identical curriculum quality.
👉 View Complete Android Course 👉 Book FREE Demo 👉 Download Brochure
📖 Android vs iOS App Development — Which Platform Should You Learn First?
📖 Android App Development for Beginners — Complete Guide 2026
📖 What is Flutter and How Does It Work? A Beginner's Guide
📖 Flutter vs React Native — Which is Better for Mobile App Development in 2026?
What Android topics are most important for a fresher interview? The most frequently tested topics are the Activity Lifecycle (especially the order of methods and what to do in each), Android components (Activity, Service, Broadcast Receiver, Content Provider), MVVM architecture (ViewModel, LiveData/StateFlow, Repository pattern), RecyclerView (Adapter, ViewHolder, LayoutManager), Kotlin coroutines basics, Room database, Retrofit for API calls, Firebase basics, and Intent types. These cover approximately 75-80% of fresher interview questions.
Do I need to know Jetpack Compose for a fresher Android interview? Basic Jetpack Compose knowledge is increasingly expected in 2026 — particularly at product companies and startups. Understanding @Composable functions, State management in Compose, and basic layout composables (Column, Row, LazyColumn) is the minimum. Companies with existing XML-based codebases may not test Compose heavily at the fresher level, but knowing it demonstrates initiative and forward-thinking. Any quality android app development full course online teaches both XML and Compose.
How many Android projects should I have before my first interview? Aim for 2 to 3 complete, well-documented projects on GitHub. Quality is more important than quantity — two complete apps with MVVM architecture, API integration, Firebase, and clean code impress interviewers more than five incomplete or poorly structured projects. At least one project should demonstrate real-world functionality rather than tutorial-level features.
Is Java or Kotlin better for Android fresher interviews? Kotlin is definitively better in 2026. All new Android development uses Kotlin, Google's official guidance recommends Kotlin, and interviewers expect Kotlin fluency from freshers. An android course with kotlin training prepares you for exactly what employers test. Java knowledge is helpful for understanding legacy code but should not be your primary Android language.
What is the salary of an Android fresher developer in India in 2026? Android fresher developers in India typically earn ₹3.5 to 7 LPA depending on company type, location, and project portfolio quality. Freshers with strong MVVM knowledge, Firebase experience, and a polished GitHub portfolio consistently land at the higher end of this range. IT services companies typically offer ₹3.5 to 5 LPA for freshers while product companies offer ₹5 to 7+ LPA.
Where can I take Android training with placement support in India? JustAcademy offers comprehensive android course with placement assistance in both online and offline formats across India — covering the complete modern Android stack with live projects, recognized certification, mock technical interviews, and active placement support through 650+ hiring partners. Visit justacademy.co/course-detail/android-app-development or book a free demo.
These top 50 Android development interview questions and answers for freshers cover every concept that entry-level Android developer interviews test in 2026 — from Android fundamentals and Activity lifecycle through Kotlin features, Jetpack libraries, MVVM architecture, Room, Retrofit, Firebase, Coroutines, and practical development best practices.
The freshers who crack their first Android interview are not always the ones who have studied the longest — they are the ones who understand concepts deeply enough to explain them clearly, have built real projects they can discuss confidently, and practice their answers enough to deliver them naturally under interview pressure.
Study these 50 questions. Build real Android apps and push them to GitHub. Practice explaining your code and architecture decisions out loud. Walk into your first Android developer interview knowing you have covered everything that experienced Android interviewers test at the fresher level.
JustAcademy is here to accelerate that journey — with expert-led android training online with live projects, recognized android certification course credentials, real portfolio development, dedicated mock interview preparation, and active placement support in both online and offline formats across India.
Enroll in JustAcademy's Android App Development Course — Online or Offline 📞 Call: +91 99871 84296 🌐 www.justacademy.co 🎓 View Android Course 🎯 Book FREE Demo 📥 Download Brochure
Selenium WebDriver Interview Questions and Answers for Freshers and Experienced Testers in 2026
UI UX Interview Questions and Answers for Freshers and Beginners Covering Design Thinking, Figma, Wireframing, and UX Research in 2026
Figma Interview Questions and Answers for UI UX Designers, Freshers, and Experienced Designers in 2026
SQL, ORM, and Database Interview Questions and Answers for Python Backend Developers and Freshers in
OOP Concepts, Python Classes Interview Questions and Answers for Beginners and Freshers in 2026
REST API, FastAPI, and Django REST Framework Interview Questions and Answers for Python Freshers and Developers in 2026
Flask API, Python Backend Interview Questions and Answers for Beginners and Freshers in 2026
Django Interview, Python Backend Questions and Answers for Freshers and Beginners in 2026
Python DSA, Coding Interview Questions and Answers for Freshers and Beginners in 2026
Version Control, GitHub Interview Questions and Answers for Python Developers and Freshers in 2026
