Activities

Question 1

What is Activity in Android?

Answer 1

An activity is the entry point for interacting with the user. It represents a single screen with a user interface. For example, an email app might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experience in the email app, each one is independent of the other

Question 2

Key concepts of Activities?

Answer 2

• All activities can be entry point for an app
• One activity implements one screen in an app (Generally)
• Each activity is only loosely bound to the other activities
• Activities must be registered in app Manifest
• Must manage activity lifecycles appropriately

Question 3

Different ways of starting activities

Answer 3

• Implicit Intent
• Explicit Intent
• By navigation controller (Android Jetpack Navigation Component)

Question 4

Difference between implicit and explicit Intents

Answer 4

For example, an explicit request might tell the system to “Start the Send Email activity in the Gmail app”. By contrast, an implicit request tells the system to “Start a Send Email screen in any activity that can do the job.”

Question 5

What is Intent Filters?

Answer 5

Intent filters are a very powerful feature of the Android platform. They provide the ability to launch an activity based not only on an explicit request, but also an implicit one.
So you can use activities from other app which are able to do things that you want.

Question 6

Activity lifecycle callbacks and when system invokes them

Answer 6

• onCreate() - fires when the system creates activity
• onStart() - starts when onCreate() exits, activity becomes visible to the user.
• onResume() - system invokes this just before the activity starts interacting with the user.
• onPause() - system call this when loses focus from activity. Activity may be partially visible
• onStop() - system invoke this whet the activity is no longer visible to the user.
• onRestart() - the system invokes this callback when an activity in stopped state is about to restart.
• onDestroy() - system invokes this callback before an activity is destroyed.

Question 7

For what is lifecycle callback?

Answer 7

Within the lifecycle callback methods, you can declare how your activity behaves when the user leaves and re-enters the activity.

For example, if you’re building a streaming video player, you might pause the video and terminate the network connection when the user switches to another app. When the user returns, you can reconnect to the network and allow the user to resume the video from the same spot.

In other words, each callback allows you to perform specific work that’s appropriate to a given change of state. Doing the right work at the right time and handling transitions properly make your app more robust and performant.

Question 8

What can ensure good implementation of the lifecycle callbacks?

Answer 8

For example, good implementation of the lifecycle callbacks can help ensure that your app avoids:

• Crashing if the user receives a phone call or switches to another app while using your app.
• Consuming valuable system resources when the user is not actively using it.
• Losing the user’s progress if they leave your app and return to it at a later time.
• Crashing or losing the user’s progress when the screen rotates between landscape and portrait orientation

Question 9

onCreate() lifecycle callback

Answer 9

You must implement this callback. On activity creation, the activity enters the Created state. In the onCreate() method, you perform basic application startup logic that should happen only once for the entire life of the activity.

For example, your implementation of onCreate() might bind data to lists, associate the activity with a ViewModel, and instantiate some class-scope variables.

This method receives the parameter savedInstanceState, which is a Bundle object containing the activity’s previously saved state. If the activity has never existed before, the value of the Bundle object is null.

Your activity does not reside in the Created state. After the onCreate() method finishes execution, the activity enters the Started state, and the system calls the onStart() and onResume() methods in quick succession

Question 10

onStart() lifecycle callback

Answer 10

When the activity enters the Started state, the system invokes this callback. The onStart() call makes the activity visible to the user, as the app prepares for the activity to enter the foreground and become interactive. For example, this method is where the app initializes the code that maintains the UI.

The onStart() method completes very quickly and, as with the Created state, the activity does not stay resident in the Started state. Once this callback finishes, the activity enters the Resumed state, and the system invokes the onResume() method.

Question 11

onResume() lifecycle callback

Answer 11

When the activity enters the Resumed state, it comes to the foreground, and then the system invokes the onResume() callback. This is the state in which the app interacts with the user. The app stays in this state until something happens to take focus away from the app. Such an event might be, for instance, receiving a phone call, the user’s navigating to another activity, or the device screen’s turning off.

When an interruptive event occurs, the activity enters the Paused state, and the system invokes the onPause() callback.

If the activity returns to the Resumed state from the Paused state, the system once again calls onResume() method. For this reason, you should implement onResume() to initialize components that you release during onPause(), and perform any other initializations that must occur each time the activity enters the Resumed state.

Question 12

Why use lifecycle components?

Answer 12

By using lifecycle-aware components, you can move the code of dependent components out of the lifecycle methods and into the components themselves.

Adding this logic into an independent, lifecycle-aware component allows you to reuse the component across multiple activities without having to duplicate code.

Question 13

What is lifecycle component?

Answer 13

Lifecycle-aware components perform actions in response to a change in the lifecycle status of another component, such as activities and fragments. These components help you produce better-organized, and often lighter-weight code, that is easier to maintain.

Question 14

onPause() lifecycle callback

Answer 14

The system calls this method as the first indication that the user is leaving your activity (though it does not always mean the activity is being destroyed); it indicates that the activity is no longer in the foreground (though it may still be visible if the user is in multi-window mode). Use the onPause() method to pause or adjust operations that should not continue (or should continue in moderation) while the Activity is in the Paused state, and that you expect to resume shortly.

You can also use the onPause() method to release system resources, handles to sensors (like GPS), or any resources that may affect battery life while your activity is paused and the user does not need them. However, a Paused activity may still be fully visible if in multi-window mode. As such, you should consider using onStop() instead of onPause() to fully release or adjust UI-related resources and operations to better support multi-window mode.

Completion of the onPause() method does not mean that the activity leaves the Paused state. Rather, the activity remains in this state until either the activity resumes or becomes completely invisible to the user. If the activity resumes, the system once again invokes the onResume() callback. If the activity returns from the Paused state to the Resumed state, the system keeps the Activity instance resident in memory, recalling that instance when the system invokes onResume(). In this scenario, you don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state. If the activity becomes completely invisible, the system calls onStop()

Question 15

The reasons for system to invoke onPause() callback

Answer 15

• Some event interrupts app execution. For instance, receiving a phone call, the user’s navigating to another activity, or the device screen’s turning off.
• In Android 7.0 (API level 24) or higher, multiple apps run in multi-window mode. Because only one of the apps (windows) has focus at any time, the system pauses all of the other apps.
• A new, semi-transparent activity (such as a dialog) opens. As long as the activity is still partially visible but not in focus, it remains paused.

Question 16

Should we use onPause() to save appliaction or user data?

Answer 16

onPause() execution is very brief, and does not necessarily afford enough time to perform save operations. For this reason, you should not use onPause() to save application or user data, make network calls, or execute database transactions; such work may not complete before the method completes. Instead, you should perform heavy-load shutdown operations during onStop()

Question 17

onStop() lifecycle callback

Answer 17

When your activity is no longer visible to the user, it has entered the Stopped state, and the system invokes the onStop() callback. This may occur, for example, when a newly launched activity covers the entire screen. The system may also call onStop() when the activity has finished running, and is about to be terminated.

In the onStop() method, the app should release or adjust resources that are not needed while the app is not visible to the user. For example, your app might pause animations or switch from fine-grained to coarse-grained location updates. Using onStop() instead of onPause() ensures that UI-related work continues, even when the user is viewing your activity in multi-window mode.

You should also use onStop() to perform relatively CPU-intensive shutdown operations. For example, if you can’t find a more opportune time to save information to a database, you might do so during onStop()

From the Stopped state, the activity either comes back to interact with the user, or the activity is finished running and goes away. If the activity comes back, the system invokes onRestart(). If the Activity is finished running, the system calls onDestroy()

Question 18

Is the Activity object kept in memory when it’s in Stopped state?

Answer 18

When your activity enters the Stopped state, the Activity object is kept resident in memory: It maintains all state and member information, but is not attached to the window manager. When the activity resumes, the activity recalls this information. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state. The system also keeps track of the current state for each View object in the layout, so if the user entered text into an EditText widget, that content is retained so you don’t need to save and restore it.

Question 19

onDestroy() lifecycle callback

Answer 19

onDestroy() is called before the activity is destroyed. The system invokes this callback either because:

• the activity is finishing (due to the user completely dismissing the activity or due to finish() being called on the activity), or
• the system is temporarily destroying the activity due to a configuration change (such as device rotation or multi-window mode)

You can distinguish between these two scenarios with the isFinishing() method.

If the activity is finishing, onDestroy() is the final lifecycle callback the activity receives. If onDestroy() is called as the result of a configuration change, the system immediately creates a new activity instance and then calls onCreate() on that new instance in the new configuration.

The onDestroy() callback should release all resources that have not yet been released by earlier callbacks such as onStop().

Question 20

Should you put your logic to determine why activity is being destroyed in Activity?

Answer 20

Instead of putting logic in your Activity to determine why it is being destroyed you should use a ViewModel object to contain the relevant view data for your Activity. If the Activity is going to be recreated due to a configuration change the ViewModel does not have to do anything since it will be preserved and given to the next Activity instance. If the Activity is not going to be recreated then the ViewModel will have the onCleared() method called where it can clean up any data it needs to before being destroyed.

Question 21

What is instance state?

Answer 21

Instance state it is the saved data that the system uses to restore the previous state and is a collection of key-value pairs stored in a Bundle object. By default, the system uses the Bundle instance state to save information about each View object in your activity layout (such as the text value entered into an EditText widget). So, if your activity instance is destroyed and recreated, the state of the layout is restored to its previous state with no code required by you. However, your activity might have more state information that you’d like to restore, such as member variables that track the user’s progress in the activity.

Question 22

Is a Bundle appropriate for preserving more than a trival amount of data?

Answer 22

A Bundle object isn’t appropriate for preserving more than a trivial amount of data because it requires serialization on the main thread and consumes system-process memory. To preserve more than a very small amount of data, you should take a combined approach to preserving data, using persistent local storage, the onSaveInstanceState() method, and the ViewModel class.

Question 23

What is going with the activity destroyed due to system constraints (configuration change or memory pressure)?

Answer 23

if the system destroys the activity due to system constraints (such as a configuration change or memory pressure), then although the actual Activity instance is gone, the system remembers that it existed. If the user attempts to navigate back to the activity, the system creates a new instance of that activity using a set of saved data that describes the state of the activity when it was destroyed.

Question 24

When does the system calls the onSaveInstanceState() method and what for?

Answer 24

As your activity begins to stop, the system calls the onSaveInstanceState() method so your activity can save state information to an instance state bundle. The default implementation of this method saves transient information about the state of the activity’s view hierarchy, such as the text in an EditText widget or the scroll position of a ListView widget.

To save additional instance state information for your activity, you must override onSaveInstanceState() and add key-value pairs to the Bundle object that is saved in the event that your activity is destroyed unexpectedly. If you override onSaveInstanceState(), you must call the superclass implementation if you want the default implementation to save the state of the view hierarchy.

To save persistent data, such as user preferences or data for a database, you should take appropriate opportunities when your activity is in the foreground. If no such opportunity arises, you should save such data during the onStop() method.

Question 25

When can you retrieve saved instance state?

Answer 25

When your activity is recreated after it was previously destroyed, you can recover your saved instance state from the Bundle that the system passes to your activity. Both the onCreate() and onRestoreInstanceState() callback methods receive the same Bundle that contains the instance state information.

Because the onCreate() method is called whether the system is creating a new instance of your activity or recreating a previous one, you must check whether the state Bundle is null before you attempt to read it. If it is null, then the system is creating a new instance of the activity, instead of restoring a previous one that was destroyed.

Instead of restoring the state during onCreate() you may choose to implement onRestoreInstanceState(), which the system calls after the onStart() method. The system calls onRestoreInstanceState() only if there is a saved state to restore, so you do not need to check whether the Bundle is null:

Question 26

How to start one activity from another

Answer 26

Generally:

• by Intents (explicit, implicit)
• by navigation component (nav controller)
• methods - startActivity(), startActivityForResult()

Methods:
Depending on whether your activity wants a result back from the new activity it’s about to start, you start the new activity using either the startActivity() or the startActivityForResult() method. In either case, you pass in an Intent object.

The Intent object specifies either the exact activity you want to start or describes the type of action you want to perform (and the system selects the appropriate activity for you, which can even be from a different application). An Intent object can also carry small amounts of data to be used by the activity that is started.

Question 27

The way of working startActivityForResult()

Answer 27

Sometimes you want to get a result back from an activity when it ends. For example, you may start an activity that lets the user pick a person in a list of contacts; when it ends, it returns the person that was selected. To do this, you call the startActivityForResult(Intent, int) method, where the integer parameter identifies the call. This identifier is meant to disambiguate between multiple calls to startActivityForResult(Intent, int) from the same activity. It’s not global identifier and is not at risk of conflicting with other apps or activities.The result comes back through your onActivityResult(int, int, Intent) method.

When a child activity exits, it can call setResult(int) to return data to its parent. The child activity must always supply a result code, which can be the standard results RESULT_CANCELED, RESULT_OK, or any custom values starting at RESULT_FIRST_USER. In addition, the child activity can optionally return an Intent object containing any additional data it wants. The parent activity uses the onActivityResult(int, int, Intent) method, along with the integer identifier the parent activity originally supplied, to receive the information.

If a child activity fails for any reason, such as crashing, the parent activity receives a result with the code RESULT_CANCELED.

Question 28

Coordination of activities and starting them. Does the first one is stopped before second one starts?

Answer 28

When one activity starts another, they both experience lifecycle transitions. The first activity stops operating and enters the Paused or Stopped state, while the other activity is created. In case these activities share data saved to disc or elsewhere, it’s important to understand that the first activity is not completely stopped before the second one is created. Rather, the process of starting the second one overlaps with the process of stopping the first one.

The order of lifecycle callbacks is well defined, particularly when the two activities are in the same process (app) and one is starting the other. Here’s the order of operations that occur when Activity A starts Activity B:

• Activity A’s onPause() method executes.
• Activity B’s onCreate(), onStart(), and onResume() methods execute in sequence. (Activity B now has user focus.)
• Then, if Activity A is no longer visible on screen, its onStop() method executes.

Question 29

Configuration change occurs, what is going on with activity?

Answer 29

When a configuration change occurs, the activity is destroyed and recreated. The original activity instance will have the onPause(), onStop(), and onDestroy() callbacks triggered. A new instance of the activity will be created and have the onCreate(), onStart(), and onResume() callbacks triggered.

Question 30

Events that can trigger configuration change

Answer 30

• change between portrait and landscape orientations
• changes to language or input device
• app enters into multi-window mode

Question 31

Lifecycle of activities in multi-window mode

Answer 31

In multi-window mode, although there are two apps that are visible to the user, only the one with which the user is interacting is in the foreground and has focus. That activity is in the Resumed state, while the app in the other window is in the Paused state.

When the user switches from app A to app B, the system calls onPause() on app A, and onResume() on app B. It switches between these two methods each time the user toggles between apps.

Question 32

Changes of activity state when new activity or dialog appears in foreground

Answer 32

If a new activity or dialog appears in the foreground, taking focus and partially covering the activity in progress, the covered activity loses focus and enters the Paused state. Then, the system calls onPause() on it.

When the covered activity returns to the foreground and regains focus, it calls onResume().

If a new activity or dialog appears in the foreground, taking focus and completely covering the activity in progress, the covered activity loses focus and enters the Stopped state. The system then, in rapid succession, calls onPause() and onStop().

When the same instance of the covered activity comes back to the foreground, the system calls onRestart(), onStart(), and onResume() on the activity. If it is a new instance of the covered activity that comes to the background, the system does not call onRestart(), only calling onStart() and onResume().

Question 33

What is going on with activity state when user taps back button?

Answer 33

If an activity is in the foreground, and the user taps the Back button, the activity transitions through the onPause(), onStop(), and onDestroy() callbacks. In addition to being destroyed, the activity is also removed from the back stack.

It is important to note that, by default, the onSaveInstanceState() callback does not fire in this case. This behavior is based on the assumption that the user tapped the Back button with no expectation of returning to the same instance of the activity. However, you can override the onBackPressed() method to implement some custom behavior, for example a “confirm-quit” dialog.

If you override the onBackPressed() method, we still highly recommend that you invoke super.onBackPressed() from your overridden method. Otherwise the Back button behavior may be jarring to the user.

Question 34

What is task and a back stack in Android?

Answer 34

A task is a collection of activities that users interact with when performing a certain job.
The activities are arranged in a stack—the back stack)—in the order in which each activity is opened.

For example, an email app might have one activity to show a list of new messages. When the user selects a message, a new activity opens to view that message. This new activity is added to the back stack. If the user presses the Back button, that new activity is finished and popped off the stack.

Question 35

How the back stack works?

Answer 35

When the current activity starts another, the new activity is pushed on the top of the stack and takes focus. The previous activity remains in the stack, but is stopped. When an activity stops, the system retains the current state of its user interface. When the user presses the Back button, the current activity is popped from the top of the stack (the activity is destroyed) and the previous activity resumes (the previous state of its UI is restored). Activities in the stack are never rearranged, only pushed and popped from the stack—pushed onto the stack when started by the current activity and popped off when the user leaves it using the Back button. As such, the back stack operates as a “last in, first out” object structure.

Question 36

How the tasks works?

Answer 36

A task is a cohesive unit that can move to the “background” when users begin a new task or go to the Home screen, via the Home button. While in the background, all the activities in the task are stopped, but the back stack for the task remains intact—the task has simply lost focus while another task takes place. A task can then return to the “foreground” so users can pick up where they left off.

Suppose, for example, that the current task (Task A) has three activities in its stack—two under the current activity. The user presses the Home button, then starts a new app from the app launcher. When the Home screen appears, Task A goes into the background. When the new app starts, the system starts a task for that app (Task B) with its own stack of activities. After interacting with that app, the user returns Home again and selects the app that originally started Task A. Now, Task A comes to the foreground—all three activities in its stack are intact and the activity at the top of the stack resumes. At this point, the user can also switch back to Task B by going Home and selecting the app icon that started that task (or by selecting the app’s task from the Recents screen). This is an example of multitasking on Android.

Question 37

Default behavior for activities and tasks:

Answer 37

• When Activity A starts Activity B, Activity A is stopped, but the system retains its state (such as scroll position and text entered into forms). If the user presses the Back button while in Activity B, Activity A resumes with its state restored.
• When the user leaves a task by pressing the Home button, the current activity is stopped and its task goes into the background. The system retains the state of every activity in the task. If the user later resumes the task by selecting the launcher icon that began the task, the task comes to the foreground and resumes the activity at the top of the stack.
• If the user presses the Back button, the current activity is popped from the stack and destroyed. The previous activity in the stack is resumed. When an activity is destroyed, the system does not retain the activity’s state.
• Activities can be instantiated multiple times, even from other tasks.

Question 38

How to change default behavior for navigation around task/back stack/activities?

Answer 38

By adding particular attributes in tag in Manifest.

In this regard, the principal  attributes you can use are:
taskAffinity
launchMode
allowTaskReparenting
clearTaskOnLaunch
alwaysRetainTaskState
finishOnTaskLaunch

And the principal intent flags you can use are:
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_SINGLE_TOP

Question 39

How to define launch modes?

Answer 39

Launch modes allow you to define how a new instance of an activity is associated with the current task. You can define different launch modes in two ways:

Using the manifest file
When you declare an activity in your manifest file, you can specify how the activity should associate with tasks when it starts.

Using Intent flags
When you call startActivity(), you can include a flag in the Intent that declares how (or whether) the new activity should associate with the current task.

Question 40

Types of launchMode attribute

Answer 40

-“standard” (the default mode)
Default. The system creates a new instance of the activity in the task from which it was started and routes the intent to it. The activity can be instantiated multiple times, each instance can belong to different tasks, and one task can have multiple instances.

-“singleTop”
If an instance of the activity already exists at the top of the current task, the system routes the intent to that instance through a call to its onNewIntent() method, rather than creating a new instance of the activity. The activity can be instantiated multiple times, each instance can belong to different tasks, and one task can have multiple instances (but only if the activity at the top of the back stack is not an existing instance of the activity).

-“singleTask”
The system creates a new task and instantiates the activity at the root of the new task. However, if an instance of the activity already exists in a separate task, the system routes the intent to the existing instance through a call to its onNewIntent() method, rather than creating a new instance. Only one instance of the activity can exist at a time.

-“singleInstance”.
Same as “singleTask”, except that the system doesn’t launch any other activities into the task holding the instance. The activity is always the single and only member of its task; any activities started by this one open in a separate task.

Question 41

Types of Intent flags for launch mode.

Answer 41

When starting an activity, you can modify the default association of an activity to its task by including flags in the intent that you deliver to startActivity(). The flags you can use to modify the default behavior are:

FLAG_ACTIVITY_NEW_TASK
Start the activity in a new task. If a task is already running for the activity you are now starting, that task is brought to the foreground with its last state restored and the activity receives the new intent in onNewIntent().
This produces the same behavior as the “singleTask” launchMode value, discussed in the previous section.

FLAG_ACTIVITY_SINGLE_TOP
If the activity being started is the current activity (at the top of the back stack), then the existing instance receives a call to onNewIntent(), instead of creating a new instance of the activity.
This produces the same behavior as the “singleTop” launchMode value, discussed in the previous section.

FLAG_ACTIVITY_CLEAR_TOP
If the activity being started is already running in the current task, then instead of launching a new instance of that activity, all of the other activities on top of it are destroyed and this intent is delivered to the resumed instance of the activity (now on top), through onNewIntent()).
There is no value for the launchMode attribute that produces this behavior.

FLAG_ACTIVITY_CLEAR_TOP is most often used in conjunction with FLAG_ACTIVITY_NEW_TASK. When used together, these flags are a way of locating an existing activity in another task and putting it in a position where it can respond to the intent.

Question 42

What is affinity in android activities?

Answer 42

The affinity indicates which task an activity prefers to belong to. By default, all the activities from the same app have an affinity for each other. So, by default, all activities in the same app prefer to be in the same task. However, you can modify the default affinity for an activity. Activities defined in different apps can share an affinity, or activities defined in the same app can be assigned different task affinities.

You can modify the affinity for any given activity with the taskAffinity attribute of the element.

The taskAffinity attribute takes a string value, which must be unique from the default package name declared in the element, because the system uses that name to identify the default task affinity for the app.

Question 43

When affinity comes into play?

Answer 43

When the intent that launches an activity contains the FLAG_ACTIVITY_NEW_TASK flag.
A new activity is, by default, launched into the task of the activity that called startActivity(). It’s pushed onto the same back stack as the caller. However, if the intent passed to startActivity() contains the FLAG_ACTIVITY_NEW_TASK flag, the system looks for a different task to house the new activity. Often, it’s a new task. However, it doesn’t have to be. If there’s already an existing task with the same affinity as the new activity, the activity is launched into that task. If not, it begins a new task.

If this flag causes an activity to begin a new task and the user presses the Home button to leave it, there must be some way for the user to navigate back to the task. Some entities (such as the notification manager) always start activities in an external task, never as part of their own, so they always put FLAG_ACTIVITY_NEW_TASK in the intents they pass to startActivity(). If you have an activity that can be invoked by an external entity that might use this flag, take care that the user has a independent way to get back to the task that’s started, such as with a launcher icon (the root activity of the task has a CATEGORY_LAUNCHER intent filter; see the Starting a task section below).

When an activity has its allowTaskReparenting attribute set to “true”.
In this case, the activity can move from the task it starts to the task it has an affinity for, when that task comes to the foreground.

For example, suppose that an activity that reports weather conditions in selected cities is defined as part of a travel app. It has the same affinity as other activities in the same app (the default app affinity) and it allows re-parenting with this attribute. When one of your activities starts the weather reporter activity, it initially belongs to the same task as your activity. However, when the travel app’s task comes to the foreground, the weather reporter activity is reassigned to that task and displayed within it.

Question 44

Default behavior of system clearing the back stack

Answer 44

If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, only the root activity is restored. The system behaves this way, because, after an extended amount of time, users likely have abandoned what they were doing before and are returning to the task to begin something new.

Question 45

Attributes that can modify default behavior of clearing the back stack.

Answer 45

There are some activity attributes that you can use to modify this behavior:

alwaysRetainTaskState
If this attribute is set to “true” in the root activity of a task, the default behavior just described does not happen. The task retains all activities in its stack even after a long period.

clearTaskOnLaunch
If this attribute is set to “true” in the root activity of a task, the stack is cleared down to the root activity whenever the user leaves the task and returns to it. In other words, it’s the opposite of alwaysRetainTaskState. The user always returns to the task in its initial state, even after a leaving the task for only a moment.

finishOnTaskLaunch
This attribute is like clearTaskOnLaunch, but it operates on a single activity, not an entire task. It can also cause any activity to go away, including the root activity. When it’s set to “true”, the activity remains part of the task only for the current session. If the user leaves and then returns to the task, it is no longer present.

Question 46

What is Recents Screen?

Answer 46

The Recents screen (also referred to as the Overview screen, recent task list, or recent apps) is a system-level UI that lists recently accessed activities and tasks. The user can navigate through the list and select a task to resume, or the user can remove a task from the list by swiping it away. Android 5.0 (API level 21) introduces a document-centric model, in which multiple instances of the same activity containing different documents may appear as tasks in the Recents screen. For example, Google Drive may have a task for each of several Google documents. Each document appears as a task in the Recents screen.

Question 47

Can you change how and when activities appear in the Recents screen?

Answer 47

Normally you should allow the system to define how your tasks and activities are represented in the Recents screen, and you don’t need to modify this behavior. However, your app can determine how and when activities appear in the Recents screen. The ActivityManager.AppTask class lets you manage tasks, and the activity flags of the Intent class let you specify when an activity is added or removed from the Recents screen. Also, the attributes let you set the behavior in the manifest.

Question 48

How task is removed from the Recents screen?

Answer 48

By default a document task is automatically removed from the Recents screen when its activity finishes. You can override this behavior with the ActivityManager.AppTask class, with an Intent flag, or with an attribute.

You can always exclude a task from the Recents screen entirely by setting the attribute, android:excludeFromRecents to true.