12 Essential Android Interview Questions

A service is an application component that lacks a user interface and can carry out lengthy tasks in the background. Even when the user isn't interacting with your application, it can continue to run in the background. The three different service categories are as follows:

• Foreground Services: A foreground service carries out actions that the user can notice. For instance, we can play an audio track using a foreground service.
• Background Services: A background service runs in the background without the user being aware. It is advised to use WorkManager in these circumstances because using background services is restricted in Android API levels 26 and higher.
• Bound Service: When an application component calls the bindService() method, the service becomes a bound service. A bound service provides a client-server interface so that other components can communicate with it, make requests, and get responses. Only while another application component is bound to a bound service will it continue to function.

In the code example above, a TextView widget is located and bound to the userName property of the ViewModel variable using findViewById().

The Data Binding Library is a support library that enables declarative rather than programmatic binding of UI elements in your layouts to data sources in your app. Activities frequently contain code that calls UI framework methods to define layouts.

The example demonstrates how to assign text directly to the widget in the layout file using the Data Binding Library. By doing this, none of the Java code from the previous example is necessary:

<TextView
    android:text="@{viewmodel.userName}" />

Here are some of the advantages of using Android Data Binding:

• Reduces boilerplate code, which in turn brings
• Less coupling
• Stronger readability
• Powerful, easy-to-implement custom attribute and a custom view
• Even faster than findViewById - The binding does a single pass on the View hierarchy, extracting the Views with IDs. This mechanism can be faster than calling findViewById for several Views.

Note: Commonly asked Android interview question for senior developers.

The correct answer is snippet 1, the version that uses PackageManager.

The Android Sensor Framework's SensorManager and Sensor are used to directly access and acquire raw sensor data. Therefore, there is no method similar to hasSystemFeature() provided by these classes, which assesses system capabilities.

For every hardware or software feature accessible on a device, Android defines feature IDs in the form of ENUMs. For instance, FEATURE_SENSOR_COMPASS is the feature ID for the compass sensor.

Moreover, users can be prevented from installing your app by specifying a non-negotiable dependency with an <uses-feature> element in your app's manifest file if your application depends on a specific feature in the system function.

However, you can use the PackageManager class to disable only a few parts of your application when a feature is absent. For obtaining different data about the application packages currently installed on the device, use PackageManager.

An implicit intent specifies an action that any app can perform on the device. When your app cannot take action but other apps probably can, using an implicit intent is useful. The user can choose which application to use if more than one has been registered to handle this request.

There might not, however, be any programs that can handle your intention. In this scenario, startingActivity() will cause your application to crash. To prevent this, ensure that at least one application is registered in the system that can handle the intent before calling startActivity(). We can use resolveActivity() on the intent object to achieve this:

   // Here we verify that there are applications registered to handle this intent
    // (If none are registered, resolveActivity returns null )
    if (sendIntent.resolveActivity(getPackageManager()) != null) {
        startActivity(sendIntent);
    } 

If any Android application is crashing frequently, check the following aspects:

• Free Memory: Since mobile devices typically have a limited amount of memory, you can free up some memory so that the application runs smoothly.
• Compatibility Check: There may be a software issue rather than a hardware one. Testing an Android app across all hardware and operating systems is not practical. The likelihood that the application won't work with your OS may be very high. You can check the compatibility on the Google Play Store page for the application to fix this.
• Memory management: Some mobile applications work flawlessly on one device but crash on another. Processing power, memory management, and CPU speed are all used in this area. If the application crashes frequently, you should look into its memory needs.
• Application Data Usage: If an application keeps crashing, you should delete the application's data. This frees up some space on your device, clears the app's cache memory, and eventually improves performance.

Note: Commonly asked Android interview question for senior developers.

The Android Activity Life Cycle refers to the various states an application goes through while running on the Android operating system.

There are seven methods that the lifecycle of activity consists of:

• onCreate() - Whenever a usr opens an activity that acts the same as a class constructor, the function onCreate() is called.
• onStart() - After onCreate, the function onStart() is called whenever an activity becomes visible to the user.
• onResume() - Just before the user begins using the application, the function onResume() is called.
• onPause() - When the user can only see a portion of the app on their phone's screen, the function onPause() is called.
• onStop() - When an activity has finished running and is no longer visible to the user or on the activity stack, the function onStop() is called.
• onRestart() - when the activity in the stopped state is about to restart, the function onRestart() is called.
• onDestroy() - when the activity is removed from the application stack, the function onDestroy() is called.

If from within the onCreate() method finish() is called, neither onPause() nor onStop() will be executed. This might happen, for instance, if you call finish() after calling onCreate() and discover an error. However, in this situation, any cleanup you anticipated being carried out in onPause() and onStop() will not be done.

Although onDestroy() is an activity's final callback, it is important to note that it might not always be used and that resource destruction should not be relied upon. It is preferable to create the resources in the onStart() and onResume() functions, and to destroy them in the onStop() and onPause() functions, respectively.

Responses from a remote service over the Internet can frequently take some time due to networking latency, load on the remote server, or the time it takes for the remote service to process and respond to the request.

If there is a delay, the animation of the activity (or, worse, the entire UI thread) may be blocked, giving the user the impression that everything is "frozen" while the client waits for a response from the service. This is because the service is launched on the main application thread of the activity (or UI thread).

By assigning remote requests to a background thread or, when practical, making use of an asynchronous response mechanism, the issue can (and should) be avoided.

Note: Commonly asked Android interview question for senior developers.

• Normal: A lower-risk permission with little risk to other applications, the system, or the user that grants requesting applications access to isolated application-level features. Without explicitly requesting the user's consent, the system automatically grants this kind of permission to a requesting application at installation.
• Dangerous: A higher-risk permission is dangerous. To prevent the user from automatically approving the use of such facilities, any risky permissions may be displayed to the user and necessitate their confirmation before proceeding.
• Signature: Only if the seeking application is signed with the same certificate as the application that announced the permission will the system allow it. Without informing the user or requesting their express consent, the system automatically provides the authorization if the certificates match.
• SignatureOrSystem: A permission that the system only allows to programs that are either signed with the same certificate as the application that requested the permission or that are in the Android system image.

The activity's life cycle that contains an AsyncTask is unrelated to its activity. Thus, if an AsyncTask is initiated inside an Activity and the user rotates the device, the activity will be deleted (and a new activity instance will be generated). Still, the AsyncTask will continue to run until it is finished.

When the AsyncTask is finished, it updates the previous instance of the activity (the one that was created but is no longer visible!) rather than the UI of the new Activity. This can result in a java.lang.IllegalArgumentException Exception.

Since the AsyncTask keeps a reference to the activity, which prevents the activity from being garbage collected as long as the AsyncTask is active, there is also a chance that this will cause a memory leak.

For these reasons, it is typically not a good idea to use AsyncTasks for lengthy background work. Instead, a different method (like a service) should be used for lengthy background operations.

The intent object is a popular method for beginning new activities and transferring data from one activity to another. However, using an Intent will not allow you to launch a ContentProvider.

Instead of using the ContentProvider object in your application's Context to interact with the provider as a client when you want to access data in a ContentProvider, you must use the ContentResolver object.

The provider object, an instance of a class that implements ContentProvider, and the ContentResolver object exchange information back and forth. Clients submit requests for data, which the provider object receives, processes, and then returns the results.

Note: Commonly asked Android interview question for senior developers.

A typical activity is a single, focused action a user can take. Nothing is stopping a developer from creating an activity that is arbitrarily complex, though, at the same time.

The Fragment class is an optional component that activity implementations can use to produce more modular code, create more complex user interfaces for larger screens, scale applications between small and large screens, and other things.

The same fragment can frequently be used across different activities, and multiple fragments can be combined within a single activity. The main goals of this structure are to encourage code reuse and promote economies of scale.

A fragment is a modular portion of an activity with its own input events and lifecycle and can be added or removed as needed. But it's important to keep in mind that the lifecycle of its host activity directly impacts a fragment's lifecycle; in other words, when the activity is paused, all of its fragments are paused as well, and when the activity is destroyed, all of its fragments are destroyed as well.