How to avoid Android startup stack trap

I. Problem and Background

The mutual linkage and jumping between applications is an important means to achieve system integrity and experience consistency, and it is also the simplest method.

When we use the most common method to start an Activity, we may also encounter failures. In real business, we encountered such an exception: when a user clicks a button and wants to "simply" jump to another application, there is no response.

As an experienced person, do you have all kinds of guesses in your mind: Is the target Activity or even the target App not available? Is the target Activty not open to the public? Is there a permission restriction or the redirected action/uri is wrong?

The real reason is hidden by flag, launchMode, Intent and other features, which may be beyond your thinking at this time.

This article will start from the source code, explore the causes and consequences, and elaborate on what "hardships" need to be experienced before startActivity() is truly ready to start an Activity, and how to solve startup exceptions caused by stack problems in a reliable manner.

1.1 Problems encountered in business

The business scenario is as follows: there are three applications: A, B, and C.

(1) Jump from application A-Activity1 to application B-Activity2;

(2) Application B-Activity2 continues to jump to application C-Activity3;

(3) A button in C will jump to B-Activity2 again, but there is no response after clicking it. It is possible for C to jump directly to B without going through the previous jump from A to B.

1.2 Problem code

The Androidmanifest configurations of the three Activities are as follows. They can all be launched through their respective actions, and the launchMode is the standard mode.

 <!-- Application A -->
 < activity
 android : name = ".Activity1"
 android : exported = "true" >
 < intent - filter >
 < action android : name = "com.zkp.task.ACTION_TO_A_PAGE1" />
 < category android : name = "android.intent.category.DEFAULT" />
 </ intent - filter >
 </ activity >
 <!-- Application B -->
 < activity
 android : name = ".Activity2"
 android : exported = "true" >
 < intent - filter >
 < action android : name = "com.zkp.task.ACTION_TO_B_PAGE2" />
 < category android : name = "android.intent.category.DEFAULT" />
 </ intent - filter >
 </ activity >
 <!-- Application C -->
 < activity
 android : name = ".Activity3"
 android : exported = "true" >
 < intent - filter >
 < action android : name = "com.zkp.task.ACTION_TO_C_PAGE3" />
 < category android : name = "android.intent.category.DEFAULT" />
 </ intent - filter >
 </ activity >

Codes from A-1 to B-2, specify flag as

FLAG_ACTIVITY_NEW_TASK

 private void jumpTo_B_Activity2_ByAction_NewTask ( ) {
 Intent intent = new Intent ( ) ;
 intent .setAction ( "com.zkp.task.ACTION_TO_B_PAGE2" ) ;
 intent .setFlags ( Intent .FLAG_ACTIVITY_NEW_TASK ) ;
 startActivity ( intent ) ;
 }

Codes from B-2 to C-3, no flag specified

 private void jumpTo_C_Activity3_ByAction_NoTask ( ) {
 Intent intent = new Intent ( ) ;
 intent .setAction ( "com.zkp.task.ACTION_TO_C_PAGE3" ) ;
 startActivity ( intent ) ;
 }

The code from C-3 to B-2 is exactly the same as that from A-1 to B-2, and the flag is specified as FLAG_ACTIVITY_NEW_TASK

 private void jumpTo_B_Activity2_ByAction_NewTask ( ) {
 Intent intent = new Intent ( ) ;
 intent .setAction ( "com.zkp.task.ACTION_TO_B_PAGE2" ) ;
 intent .setFlags ( Intent .FLAG_ACTIVITY_NEW_TASK ) ;
 startActivity ( intent ) ;
 }

1.3 Preliminary code analysis

Looking closely at the problem code, it is very simple in implementation and has two features:

(1) If you jump directly from C-3 to B-2, there will be no problem. However, since A-1 has already jumped over B-2, C-3 will fail.

(2) When A-1 and C-3 jump to B-2, the flag is set to FLAG_ACTIVITY_NEW_TASK.

Based on experience, we speculate that it is related to the stack, and try to print out the state of the stack before the jump, as shown in the following figure.

Since FLAG_ACTIVITY_NEW_TASK is set when A-1 jumps to B-2, but not when B-2 jumps to C-3, 1 is in an independent stack, and 2 and 3 are in another stack. See the figure below.

There are generally three possible expectations for C-3 to jump to B-2, as shown in the following figure: Scenario 1, create a new Task and start B-2 in the new Task; Scenario 2, reuse the existing B-2; Scenario 3, create a new instance B-2 in the existing Task.

But in fact, none of the three expectations were realized. The declaration cycle of all activities did not change, and the interface always stayed at C-3.

Take a look at the official comments and code comments of FLAG_ACTIVITY_NEW_TASK, as shown below:

Focus on this paragraph:

When using this flag, if a task is already running for the activity you are now starting, then a new activity will not be started; instead, the current task will simply be brought to the front of the screen with the state it was last in.

When using this flag, if the Activity you are launching is already running in a Task, a new Activity will not be started; instead, the current Task will simply be displayed in the front of the interface and show its last state.

——Obviously, the descriptions in the official documentation and code comments are consistent with our abnormal phenomenon. If the target Activity2 already exists in the Task, it will not be started; the Task is directly displayed in the front and shows the last status. Since the target Activty3 is the source Activity3, there is no change on the page.

It seems that the official version is still very reliable, but can the actual effect really always be consistent with the official description? Let's take a look at it through several scenarios.

2. Scenario Expansion and Verification

2.1 Scenario Expansion

In the process of adjusting and reproducing according to the official description, I found several interesting scenes.

PS: In the above business case, B-2 and C-3 are in different applications and in the same task, but whether they are actually the same application does not have a big impact on the results. In order to avoid reading confusion caused by different applications and different tasks, we perform the jump of the same stack in this application, so the scenario in the business is equivalent to the following [Scenario 0]

[Scenario 0] Change the inter-application jump from B-2 to C-3 in the business to an intra-application jump from B-2 to B-3

 // B - 2 jumps to B - 3
 public static void jumpTo_B_3_ByAction_Null ( Context context ) {
 Intent intent = new Intent ( ) ;
 intent .setAction ( "com.zkp.task.ACTION_TO_B_PAGE3" ) ;
 context .startActivity ( intent ) ;
 }

As shown in the figure below, A-1 sets NEW_TASK to jump to B-2, then jump to B-3, and finally sets NEW_TASK to jump to B-2. Although jumping to C-3 is changed to jumping to B-3, the performance is consistent with the previous problem, there is no response and it stays at B-3.

Some readers may point out that if NEW_TASK is used to jump to the same application without specifying the target's taskAffinity attribute, it cannot actually be started in the new task. Please ignore this issue and assume that the author's operation has already added taskAffinity, which has no effect on the final result.

[Scenario 1] If the target task and the source task are not the same, will the situation be as described in the official documentation to reuse the existing task and display the latest status? We change B-3 to start a new activity C-4 of a new task, and then jump back to B-2 through C-4.

 // B - 3 jumps to C - 4
 public static void jumpTo_C_4_ByAction_New ( Context context ) {
 Intent intent = new Intent ( "com.zkp.task.ACTION_TO_C_PAGE4" ) ;
 intent .setFlags ( Intent .FLAG_ACTIVITY_NEW_TASK ) ;
 context .startActivity ( intent ) ;
 }
 // C - 4 jumps to B - 2
 public static void jumpTo_B_2_ByAction_New ( Context context ) {
 Intent intent = new Intent ( ) ;
 intent .setAction ( "com.zkp.task.ACTION_TO_B_PAGE2" ) ;
 intent .setFlags ( Intent .FLAG_ACTIVITY_NEW_TASK ) ;
 context .startActivity ( intent ) ;
 }

As shown in the figure below, A-1 sets NEW_TASK to jump to B-2, then jumps to B-3, then sets NEW_TASK to jump to C-4, and finally sets NEW_TASK to jump to B-2.

The expected result is: it will not jump to B-2, but jump to the top level B-3 of its task.

The actual result is: as expected, it did jump to B-3.

[Scene 2] Slightly modify Scene 1: When jumping from C-4 to B-2, we do not jump through action, but jump through setClassName instead.

 // C - 4 jumps to B - 2
 public static void jumpTo_B_2_ByPath_New ( Context context ) {
 Intent intent = new Intent ( ) ;
 intent .setClassName ( "com.zkp.b" , "com.zkp.b.Activity2" ) ; // Set classname directly without passing action
 intent .setFlags ( Intent .FLAG_ACTIVITY_NEW_TASK ) ;
 context .startActivity ( intent ) ;
 }

As shown in the figure below, A-1 sets NEW_TASK to jump to B-2, then jumps to B-3, then sets NEW_TASK to jump to C-4, and finally sets NEW_TASK to jump to B-2.

The expected result is: consistent with scenario 0, it will jump to the existing top-level B-3 of the task where B-2 is located.

The actual result is: a new B-2 instance is generated in the existing Task2.

Just changing the way to re-jump to B-2 has a completely different effect! This is inconsistent with the behavior of the flag and the "singleTask" launchMode value mentioned in the official documentation!

[Scenario 3] Modify scenario 1 again: this time C-4 does not jump to B-2 at the bottom of the stack, but instead jumps to B-3 , still through action.

 // C - 4 jumps to B - 3
 public static void jumpTo_B_3_ByAction_New ( Context context ) {
 Intent intent = new Intent ( ) ;
 intent .setAction ( "com.zkp.task.ACTION_TO_B_PAGE3" ) ;
 intent .setFlags ( Intent .FLAG_ACTIVITY_NEW_TASK ) ;
 context .startActivity ( intent ) ;
 }

As shown in the figure below, A-1 sets NEW_TASK to jump to B-2, then jumps to B-3, then sets NEW_TASK to jump to C-4, and finally sets NEW_TASK to jump to B-3.

The expected result is: consistent with scenario 0, it will jump to the top level B-3 of the task where B-2 is located.

The actual result is: a new B-3 instance is generated in the existing Task2.

Isn't it agreed that when an Activity already exists, the latest status of the Task in which it is located should be displayed? Obviously, B-3 already exists in Task2, but it is not displayed directly, but a new B-3 instance is generated.

[Scenario 4] Since the Activity is not reused, will the Task be reused? Slightly modify scenario 3 and directly assign a separate affinity to B-3.

 < activity
 android : name = ".Activity3"
 android : exported = "true"
 android : taskAffinity = "b3.task" ><!-- Specifies the affinity identifier -->
 < intent - filter >
 < action android : name = "com.zkp.task.ACTION_TO_B_PAGE3" />
 < category android : name = "android.intent.category.DEFAULT" />
 </ intent - filter >
 </ activity >

As shown in the figure below, A-1 sets NEW_TASK to jump to B-2, then jumps to B-3, then sets NEW_TASK to jump to C-4, and finally sets NEW_TASK to jump to B-3.

——This time, even Task will not be reused...Activity3 is instantiated in a new stack.

Looking back at the official comments, they are very inaccurate and can even cause developers to have serious misunderstandings about this part! Slightly changing an unrelated property in the process (such as the jump target, jump method, etc.) can make a big difference.

When reading the flag-related comments, we must establish a consciousness: the actual effect of Task and Activity jump is the result of the combined effect of launchMode, taskAffinity, jump method, Activity hierarchy in Task and other attributes. Don't believe in "one-sided words".

Back to the question itself, what are the reasons for the different effects above? Only the source code is the most trustworthy.

3. Scenario Analysis and Source Code Exploration

This article is based on the Android 12.0 source code for exploration. The above scenarios are consistent on different Android versions.

3.1 Notes on source code debugging

Many articles have detailed instructions on how to debug source code, so this article will not go into details. Here we will only briefly summarize the things that need to be paid attention to :

1. When downloading the emulator, do not use the Google Play version, which is similar to the user version and cannot select the system_process process for breakpoints.
2. Even for Google's official simulator and source code, there will be serious mismatches in line numbers when using breakpoints (for example, the simulator will actually run to method A, but when setting a breakpoint in the source code, the corresponding line of method A cannot be located). There is no good way to deal with this problem, and you can only try to avoid it, such as making the simulator version consistent with the source code version and setting more breakpoints to increase the chances of locating the key lines.

3.2 Preliminary breakpoints, clear start-up results

Taking [Scene 0] as an example, let's preliminarily confirm why there is no response when B-3 jumps to B-2, and whether the system tells the reason.

3.2.1 Clarify the launch results and their sources

In breakpoint debugging of Android source code, there are two common types of processes: application process and system_process process.

In the application process, we can get the status code result of the application startup result, which tells us whether the startup is successful. The involved stack is shown in the following figure (marked 1):

Activity class:: startActivity()

→ startActivityForResult()

→ Instrumentation class:: execStartActivity(),

The return value result is ATMS

The result of (ActivityTaskManagerService) execution.

As shown in the figure above (marker 2), the ATMS class:: startActivity() method returns result=3.

In the system_process process, let's see how result = 3 is assigned. The detailed breakpoint steps are omitted, and the actual stack is shown in the following figure (marked 1):

ATMS class:: startActivity() → startActivityAsUser()

→ ActivityStarter class:: execute()

→ executeRequest()

→ startActivityUnchecked()

→ startActivityInner()

→ recycleTask(), in which the result is returned.

As shown in the figure above (mark 2), result is assigned when mMovedToFrnotallow=false, that is, result=START_DELIVERED_TO_TOP=3, and START_SUCCESS=0 indicates successful creation.

Take a look at the description of START_DELIVERED_TO_TOP in the source code, as shown below:

Result for IActivityManaqer.startActivity: activity wasn't really started, but the given Intent was given to the existing top activity.

(Result of IActivityManaqer.startActivityActivity: The Activity is not actually started, but the given Intent is provided to the existing top-level Activity.)

"Activity is not actually started" - Yes, because it can be reused

"The given Intent has been provided to the existing top-level Activity" - Actually, no, the top-level Activity3 did not receive any callback, onNewIntent() was not executed, and even when trying to pass new parameters through Intent:: putExtra(), Activity3 did not receive it. The official document brings us another question? Let's record this question and analyze it later.

What conditions will cause

What is the result of START_DELIVERED_TO_TOP? The author's idea is to find the difference by comparing it with the normal startup process.

3.3 Process breakpoints, explore the startup process

Generally speaking, when locating a problem, we are accustomed to inferring the cause from the result, but the process of inferring can only focus on the code branches that are strongly related to the problem, and cannot enable us to understand the whole picture well.

Therefore, in this section, we will introduce the logic of the startActivity process that is strongly related to the above [Scene 01234] through sequential reading. Let's briefly describe it again:

1. [Scene 0] In the same task, jump from top B-3 to B-2 and stay at B-3
2. [Scenario 1] From C-4 in another Task, jump to B-2 - jump to B-3
3. [Scenario 2] Change the way C-4 jumps to B-2 in scenario 1 to setClassName() - create a new B-2 instance
4. [Scenario 3] Change C-4 jump to B-2 in scenario 1 to jump to B-3 - create a new B-3 instance
5. [Scenario 4] Assign taskAffinity to B-3 in scenario 3 - create a new Task and a new B-3 instance

3.3.1 Overview of process source code

In the source code, the entire startup process is very long, involving many methods and logics. In order to help everyone clarify the method calling order and facilitate the reading of subsequent content, the author organizes the key classes and method calling relationships involved in this article as follows.

If you are not clear about the calling relationship in subsequent reading, you can return here to check:

 // ActivityStarter .java

 ActivityStarter :: execute ( ) {
 executeRequest ( intent ) {
 startActivityUnchecked ( ) {
 startActivityInner ( ) ;
 }
 }
 ActivityStarter :: startActivityInner ( ) {
 setInitialState ( ) ;
 computeLaunchingTaskFlags ( ) ;
 Task targetTask = getReusableTask ( ) {
 findTask ( ) ;
 }
 ActivityRecord targetTaskTop = targetTask .getTopNonFinishingActivity ( ) ;
 if ( targetTaskTop != null ) {
 startResult = recycleTask ( ) {
 setTargetRootTaskIfNeeded ( ) ;
 complyActivityFlags ( ) ;
 if ( mAddingToTask ) {
 return START_SUCCESS ; // [Scenario 2] [Scenario 3] Return from recycleTask ( )
 }
 resumeFocusedTasksTopActivities ( )
 return mMovedToFront ? START_TASK_TO_FRONT : START_DELIVERED_TO_TOP ; // [Scenario 1] [Scenario 0] Return from recycleTask ( )
 }
 } else {
 mAddingToTask = true ;
 }
 if ( startResult != START_SUCCESS ) {
 return startResult ; // [Scene 1] [Scene 0] Return from startActivityInner ( )
 }
 deliverToCurrentTopIfNeeded ( ) ;
 resumeFocusedTasksTopActivities ( ) ;
 return startResult ;
 }

3.3.2 Key Process Analysis

(1) Initialization

startActivityInner() is the most important method. As shown in the following figures, this method will first call setInitialState() to initialize various global variables, and call reset() to reset various states in ActivityStarter.

In the process, we note two key variables mMovedToFront and mAddingToTask, both of which are reset to false here.

Among them, mMovedToFront represents whether the target Task needs to be moved to the foreground when the Task is reusable; mAddingToTask represents whether the Activity needs to be added to the Task.

(2) Calculate and confirm the flag at startup

This step uses the computeLaunchingTaskFlags() method to perform preliminary calculations based on launchMode, properties of the source Activity, and other factors to confirm LaunchFlags.

The focus here is on various scenarios where the source Activity is empty, which is irrelevant to the scenarios mentioned above, so I will not explain it in detail.

(3) Obtaining a reusable Task

This step is implemented by calling getReusableTask() to find out whether there is a reusable Task.

Let me first state the conclusion: In scenarios 0123, reusable Tasks can be obtained, but in scenario 4, no reusable Tasks are obtained.

Why can't scenario 4 be reused? Let's take a look at the key implementation of getReusableTask().

In the figure above (mark 1), putIntoExistingTask indicates whether an existing Task can be put in. When the flag contains NEW_TASK and does not contain MULTIPLE_TASK, or when launchMode of singleInstance or singleTask is specified, and no Task is specified or a result is required to be returned, scenarios 01234 all meet the conditions.

Then, the figure above (annotation 2) uses findTask() to find a reusable Task and assigns the top Activity found in the process to intentActivity. Finally, the figure above (annotation 3) takes the Task corresponding to intentActivity as the result.

How does findTask() find which Task can be reused?

The main thing is to confirm the two results mIdealRecord - "ideal ActivityRecord" and mCandidateRecord - "candidate ActivityRecord" as intentActivity, and take the Task corresponding to intentActivity as the reused Task.

What ActivityRecord is the ideal or candidate ActivityRecord?

Confirmed in mTmpFindTaskResult.process().

The program will traverse all the tasks in the current system, and in each task, perform the work shown in the figure above - compare the bottom Activity realActivity of the Task with the target Activity cls.

In scene 012, we want to jump to Activity2, that is, cls is Activity2, which is the same as realActivity2 at the bottom of Task, so we take Activity3 r at the top of Task as the "ideal Activity";

In scenario 3, we want to jump to Activity3, that is, cls is Activity3, which is different from realActivity2 at the bottom of Task. Then we further determine the stack affinity between Activity2 at the bottom of Task and target Activity3. If they have the same affinity, we will take Activity3 at the top of Task as the "candidate Activity".

In scenario 4, all conditions are not met and no reusable Task is found. After executing getReusableTask(), mAddingToTask is assigned to true.

This explains why a new Task was created in [Scenario 4].

(4) Determine whether the target Task needs to be moved to the foreground

If there is a reusable Task, scene 0123 will execute recycleTask(), which will perform several operations in succession: setTargetRootTaskIfNeeded(),

complyActivityFlags().

First, the program executes

setTargetRootTaskIfNeeded() is used to determine whether the target Task needs to be moved to the foreground, using mMovedToFront as the identifier.

In [Scenario 123], the source Task and the target Task are different, differentTopTask is true, and after a series of Task attribute comparisons, it can be concluded that mMovedToFront is true;

In scenario 0, the source Task and the target Task are the same, differentTopTask is false, and mMovedToFront remains false.

Therefore, we can explain the phenomenon that Task does not switch in [Scenario 0].

(5) Confirm whether to add the Activity to the Task by comparing flags, Intent, Component, etc.

Still in [Scene 0123], recycleTask() will continue to execute complyActivityFlags() to confirm whether to add the Activity to the Task, using mAddingToTask as the identifier.

This method will be FLAG_ACTIVITY_NEW_TASK,

FLAG_ACTIVITY_CLEAR_TASK,

A series of judgments are made based on many flags and Intent information such as FLAG_ACTIVITY_CLEAR_TOP.

In the above figure (marked 1), it will first determine whether the task needs to be reset later, resetTask, and the judgment condition is FLAG_ACTIVITY_RESET_TASK_IF_NEEDED. Obviously, the resetTask of scene 0123 is false. Continue execution.

Next, multiple conditional judgments will be executed in sequence.

In [Scenario 3], the target Component (mActivityComponent) is B-3, and the realActivity of the target Task is B-2. The two are different, and the resetTask-related judgment is entered (mark 2).

Because resetTask was already false before, mAddingToTask in [Scene 3] is set to true instead of its original value.

In [Scene 012], the two compared Activities are both B-2 (marked 3), and you can proceed to the next level of judgment - isSameIntentFilter().

The content of this step is very obvious. The existing Intent of the target Activity2 is compared with the new Intent. Obviously, in scenario 2, the Intent is different because it is changed to setClassName jump.

Therefore, the mAddingToTask in [Scenario 2] is separated from the original value and is set to true.

Let’s summarize:

The mMovedToFront of [Scene 123] is first set to true, while [Scene 0] goes through many tests and maintains the initial value of false.

——This means that when there is a reusable Task, [Scene 0] does not need to switch the Task to the front; [Scene 123] needs to switch to the target Task.

In [Scene 234], mAddingToTask is set to true at different stages, while in [Scene 01], it always maintains the initial value of false.

——This means that [Scene 234] needs to add the Activity to the Task, but [Scene 01] no longer does.

(6) Actually start the Activity or directly return the result

Each Activity that is started will start the actual startup and life cycle calls through a series of operations such as resumeFocusedTasksTopActivities().

Our exploration of the above scenarios has already yielded answers, so we will no longer focus on the subsequent processes.

4. Problem repair and answers to outstanding questions

4.1 Bug fixes

Since we have summarized so many necessary conditions above, we only need to destroy some of them to fix the problems encountered in the business. Here are a few simple solutions.

• Solution 1: Modify the flag. When B-3 jumps to B-2, add FLAG_ACTIVITY_CLEAR_TASK or FLAG_ACTIVITY_CLEAR_TOP, or simply do not set the flag. This has been proven to be feasible.
• Solution 2: Modify the intent attribute, that is, [Scenario 2]. A-1 implicitly jumps to B-2 through action, then B-3 can jump to B-2 through setClassName or modifying the attribute in action. It has been verified to be feasible.
• Solution 3: Remove B-2 in advance. When B-2 jumps to B-3, finish B-2. It should be noted that finish() should be executed before startActivity() to avoid the influence of the remaining ActivityRecord and Intent information on subsequent jumps. This is especially true when you use B-2 as a deeplink distribution activity of your own application.

4.2 Remaining Issues

Remember the doubt we had at the beginning of the article, why there is no callback onNewIntent()?

onNewIntent() is triggered by deliverNewIntent(), and deliverNewIntent() is only called by the following two methods.

complyActivityFlags() is the method we focused on in 3.3.1.5 above. It can be found that all possible conditions for calling deliverNewIntent() in complyActivityFlags() are perfectly avoided.

The deliverToCurrentTopIfNeeded() method is shown in the figure below.

mLaunchFlags and mLaunchMode cannot meet the conditions, resulting in dontStart being false and no chance to start

deliverNewIntent().

At this point, the question of onNewIntent() is answered.

V. Conclusion

Through a series of scenario assumptions, we found many unexpected phenomena:

1. The document mentions that FLAG_ACTIVITY_NEW_TASK is equivalent to singleTask, which is not entirely true. Only when combined with other flags can similar effects be achieved. The annotation of this flag is very one-sided and may even cause misunderstanding. A single factor cannot determine the overall performance.
2. The official documentation mentions
   START_DELIVERED_TO_TOP will pass the new Intent to the top-level Activity, but in fact, not every START_DELIVERED_TO_TOP will redistribute the new Intent.
3. When the same bottom-of-stack Activity is jumped to twice through action or setClassName, the second jump will fail, but it will succeed when jumped twice in different ways.
4. When using FLAG_ACTIVITY_NEW_TASK alone, the effect of jumping to the bottom Activity of the stack and jumping to other Activities in the same stack is very different.

The problems encountered in business are ultimately caused by insufficient understanding of the Android stack mechanism.

When facing stack-related coding, developers must think clearly about the mission of the Activty that takes on the newly opened application stack in the global application. They must comprehensively evaluate the Task history, flag attributes, launchMode attributes, Intent content, etc., and carefully refer to official documents to avoid stack traps and achieve ideal and reliable results.