What is AndroidManifest.xml and what key elements does it declare?

WHAT THIS TESTS: The interviewer wants to know if you understand that AndroidManifest.xml is not just a config file but the declarative contract the Android system reads at install time to learn what your app contains and what it requires. At the senior level even a basic question like this reveals whether you think about the system boundary or only the code inside your app.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, component registration: every activity, service, broadcast receiver, and content provider must be declared so the system can instantiate and route to them. Second, permissions and features: you declare uses-permission for normal and dangerous permissions, uses-feature for hardware like camera or GPS, and permission to define custom permissions for inter-app security. Third, application metadata: the package attribute serves as the unique identifier, along with versionCode, versionName, targetSdkVersion, and application-level themes. Fourth, intent filters: the system uses these to resolve which activity or service can handle a given action, and the MAIN/LAUNCHER filter determines what the user sees in the app drawer.

COMMON WRONG ANSWERS: A red flag is treating the manifest as optional boilerplate or confusing it with build.gradle. Another red flag is listing only activities and permissions without mentioning services, receivers, or providers. Saying permissions are only checked at runtime is also wrong; the manifest is where they are declared, and the system enforces some at install time while dangerous permissions also require runtime grants on modern Android.

LIKELY FOLLOW-UPS: The interviewer may ask how the manifest relates to the Android build process, such as how the package attribute interacts with the applicationId in Gradle. They might ask what happens if you forget to declare an activity, or how intent resolution works when multiple apps declare the same filter. They could also ask about the merger tool when using library manifests, or how targetSdkVersion affects runtime behavior versus compileSdkVersion.

ONE CONCRETE EXAMPLE: Imagine you are building a barcode scanner app. In the manifest you declare an activity with MAIN and LAUNCHER intent filters so it appears on the home screen. You add uses-permission for CAMERA and uses-feature for android.hardware.camera.autofocus so the Play Store filters out devices without autofocus. You declare a service with an intent filter for a custom action so a partner app can bind to it. Finally, you set targetSdkVersion to 34 so the system knows which runtime behavior rules to apply.