Android Interview Questions & Answer
The Application class in Android is the base class within an Android app that contains all other components such as activities and services. The Application class, or any subclass of the Application class, is instantiated before any other class when the process for your application/package is created.
A Context is a handle to the system; it provides services like resolving resources, obtaining access to databases and preferences, and so on. An Android app has activities. Context is like a handle to the environment your application is currently running in.
Application Context: This context is tied to the lifecycle of an application. The application context can be used where you need a context whose lifecycle is separate from the current context or when you are passing a context beyond the scope of an activity.
Activity Context: This context is available in an activity. This context is tied to the lifecycle of an activity. The activity context should be used when you are passing the context in the scope of an activity or you need the context whose lifecycle is attached to the current context.
Different Android devices use different CPUs, which in turn support different instruction sets. Each combination of CPU and instruction set has its own Application Binary Interface (ABI). An ABI includes the following information:
- The CPU instruction set (and extensions) that can be used.
- The endianness of memory stores and loads at runtime. Android is always little-endian.
- Conventions for passing data between applications and the system, including alignment constraints, and how the system uses the stack and registers when it calls functions.
- The format of executable binaries, such as programs and shared libraries, and the types of content they support. Android always uses ELF.
- How C++ names are mangled.
Android uses DVM (Dalvik Virtual Machine ) rather using JVM(Java Virtual Machine).
- Build types define properties that Gradle uses when building and packaging your Android app.
- A build type defines how a module is built, for example whether ProGuard is run.
- A product flavor defines what is built, such as which resources are included in the build.
- Gradle creates a build variant for every possible combination of your project’s product flavors and build types.
- First step involves compiling the resources folder (/res) using the aapt (android asset packaging tool) tool. These are compiled to a single class file called R.java. This is a class that just contains constants.
- Second step involves the java source code being compiled to .class files by javac, and then the class files are converted to Dalvik bytecode by the "dx" tool, which is included in the sdk 'tools'. The output is classes.dex.
- The final step involves the android apkbuilder which takes all the input and builds the apk (android packaging key) file.
Android application architecture has the following components:
- Activities - Provides the window in which the app draws its UI
- Services − It will perform background functionalities
- Intent − It will perform the inter connection between activities and the data passing mechanism
- Resource Externalization − strings and graphics
- Notification − light,sound,icon,notification,dialog box,and toast
- Content Providers − It will share the data between applications
Manifest: Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application's code. It contains information of your package, including components of the application such as activities, services, broadcast receivers, content providers etc.
R.Java: It is an auto-generated file by aapt (Android Asset Packaging Tool) that contains resource IDs for all the resources of res/ directory.
Activities are basically containers or windows to the user interface.
- OnCreate(): This is when the view is first created. This is normally where we create views, get data from bundles etc.
- OnStart(): Called when the activity is becoming visible to the user. Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.
- OnResume(): Called when the activity will start interacting with the user. At this point your activity is at the top of the activity stack, with user input going to it.
- OnPause(): Called as part of the activity lifecycle when an activity is going into the background, but has not (yet) been killed.
- OnStop(): Called when you are no longer visible to the user.
- OnDestroy(): Called when the activity is finishing
- OnRestart(): Called after your activity has been stopped, prior to it being started again