Does rooting an android device effect its activity life cycle

Question

I wrote a test application for testing the life cycle methods. The application starting an activity 'B' from an activity 'A'. From what I learned in the developer's manual , 'A' should stop and then 'B' gets created, but my device has a different behavior, 'A' pauses and 'B' gets created when 'B' is popped of the back stack onResume() method of 'A' is getting called. Now I ran the same application on my dad's device and it gives the expected result. My question is does rooting alter the life cycle of the device, if so is there a way I can make it "normal" without un-rooting my device. Thanks in advance.

The screen shot of log file is here

EDIT: MY device , moto x first generation(xt1052) runs on android 4.4.4, my dad's device, moto g first generation runs on android 5.0,2

Answer 1

Your question talks about two distinct life cycle events.

1. Activity A starts Activity B. Here is what the manual says:

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.

2. From Activity B, user presses back popping Activity A from the back 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.

It is unclear which one of these you are saying does not seem to operate correctly on a rooted device. However, I suspect you are conflating the two and things work correctly.

EDIT:

Your comment indicates confusion about language used in the manual versus the names of lifecycle methods. When the manual says (in case 1) that the activity is stopped, that doesn't mean onStop(). The context of that description indicates that onPause() would be called - if the user presses the back button, the activity resumes suggesting onResume() will be called. To transition to onStop() and thus require transition back to onRestart() in order to resume the application, the back stack would need to lose more context - as in the user completely exits the running application (and so it no longer makes sense to keep it's back stack) and starts another.

Answer 2

Tell us the 2 cenarios where the application is running:

The device you have, the version/build number, and the Manufacturer

The other device, the version/build number and the Manufacturer.

From my experience so far, the same device, when assembled by different manufacturers come with the Operational System altered, sometimes in major ways. I had an application that used the SMS system, that was unable to start in an specific system, due to the manufacturer overriding the user permissions.

Likewise, there can be the following cenarios that change the behavior:

• Device has less memory than what it needs available, and kills the Activities to release memory
• Device has hidden user that can change the flow of your apps
• Device has a "written" version of the Android, but runs another or is not complete
• Device has different compiled libraries, whose function are out of order (or have been replaced)

To bypass those issues, I suggest looking at onPause() and onResume(), as those seem to behave closer on different devices, and different operational systems, check this for additional aid . If you need a separate onPause from an onStop(), you might need to "branch" your application, making subtle changes in code, for each version