Android Application Components and Activity Lifecycle

Activities represent individual screens or UI interactions in Android apps. They are one of the four fundamental app components. However, Activities themselves do NOT 'subscribe for intents' - that's the role of Broadcast Receivers. Activities can be started by intents (via startActivity()) but they don't actively subscribe to or listen for intent broadcasts.

When an activity is completely obscured by another activity, it is no longer visible to the user, causing it to transition to the Stopped State in the Android Activity lifecycle.

When an activity is paused or stopped, the system can reclaim memory either by calling finish() or by killing the process containing the activity, making both methods valid paths for memory recovery.

The visible lifetime of an activity extends from onStart() to the corresponding onStop() call, not onPause(). The activity is visible to the user in the onStart()-onStop() window, while onPause() indicates partial obscuration (activity is still visible but not in focus). The visible lifecycle can repeat multiple times as the user navigates away and back.

The foreground lifetime of an activity occurs between the call to onResume() and the corresponding call to onPause(), during which the activity is in the foreground and interacting with the user.

In the Android Activity lifecycle, onResume() is called just before the activity starts interacting with the user, bringing it to the top of the activity stack and receiving user input.

Activities in three states are killable by the system: onDestroy() (being destroyed), onStop() (stopped), and onPause() (paused). The system may kill processes in these states to reclaim memory if resources are needed, with onPause() being the safest state (data is saved) but still technically killable in extreme memory pressure.

onPause() is called when the system is about to resume another activity. This method signals that your activity is no longer in the foreground - the user is navigating away, a notification is appearing, or another activity is being launched. It's the last guaranteed callback before the system can kill the process.

True. The onStart() and onStop() methods can be called multiple times during an activity's lifetime. Each time the activity becomes visible to the user, onStart() is called, and when it's no longer visible, onStop() is called. This cycle can repeat many times - for example, when the user navigates to other apps and returns, or when a dialog appears and disappears.

onCreate() is the first method called when an activity is created. It's where you initialize your activity, set up the UI with setContentView(), bind data, and create any objects or resources the activity will need. This method is called once per activity instance, unlike onStart() or onResume() which can be called multiple times.

In Android activity lifecycle, onStart() indicates when the activity becomes visible to the user, and onStop() is called when it's no longer visible. Resources needed to display the activity to the user (such as views and UI elements) should be initialized in onStart() and released in onStop(). onResume() and onPause() are for foreground/interactive state, not visibility.

The onCreate() method receives a savedInstanceState Bundle parameter that contains the activity's previously saved state. This state is captured in onSaveInstanceState() when the activity may be killed by the system. onResume() and onStart() do not receive this Bundle parameter.

In Android's process management, when multiple processes have the same priority level, the system uses additional criteria to decide which to kill first. Generally, processes considered less critical or older are terminated before newer ones. The lowest priority processes are always killed first when memory is needed.

An Android application is not alive when its process is killed. While the application's state and user data may be preserved through onSaveInstanceState() and persistent storage, the application itself is not running or alive after process termination. It must be restarted by the user or system.

Android does not keep all applications running indefinitely. The system actively manages memory by killing background processes when resources are needed for foreground activities. Applications can be terminated even if they're not doing anything wrong - this is normal Android behavior.

Android applications are built using four main component types: Activities (UI screens), Services (background operations), Broadcast Receivers (respond to system-wide broadcasts), and Content Providers (data sharing between apps). These are the fundamental building blocks defined in the Android framework.

The four official Android application components are Activities, Services, Broadcast Receivers, and Content Providers. Options A and D incorrectly include 'Process', which is not an application component but a runtime container. Option B incorrectly includes 'Intent', which is a messaging object, not a component.

The statement is false because while Android applications do have multiple screens, each screen is typically implemented by a single Activity, not multiple activities. An Activity represents a single screen with a user interface. You can have multiple activities in an app, but one activity per screen is the standard pattern.

Android application process lifetime is controlled by the Android system, not by the application itself. The system can kill any process at any time to reclaim resources, following priority rules. Applications can only influence this indirectly through lifecycle methods and service types, but cannot directly control process lifetime.

An Android activity has three main states: Active (running/foreground), Paused (partially visible, like when a dialog is on top), and Stopped (no longer visible but not destroyed). These represent the activity's lifecycle states from creation to destruction.