I want to test the state of my app when it's left in the backstack for too long.
When I open like 20 apps one after the other my last used app (which is the app I'm testing) eventually terminates and a savedInstanceState occurs. Is there a way to simulate this behaviour for the app I'm testing without having to open another 20 apps in order to burry my app in backstack?
Yes, there's a simple way to do it. Just enable Do not keep activities under Developer options. Your activity will then be immediately destroyed as soon you leave it and onRestoreInstanceState() will be invoked when you return.
Alternatively, you can force a configuration change (like orientation) and that will recreate your activity too. One issue with this approach is that there's a bug with some JellyBean/KitKat versions where the emulators fail to rotate. (This works fine on a device though.)
The workaround is to install the RotateScreenOrientation.apk which can force the emulator to be in portrait or landscape but this quickly becomes tedious if you have the option to Wipe user data on emulator start enabled.
Related
We have designed an hybrid app which is a bit heavy (9 MB). Problem is that at times, minimizing this app (home button) makes the app reset in background i.e. its app cache is lost and app reloads from splash screen. After minimizing we worked with other apps in tablet (Galaxy 800).
We saw this problem only if we tried to launch app from the icon in launcher. This problem did not happen when we tried to launch it from the minimized list(recent apps button).
This problem is not specific to the tab. It also happened in Galaxy 3 and Droid Razr also.
Any guidance?
Problem is that at times, minimizing this app (home button) makes the app reset in background i.e. its app cache is lost and app reloads from splash screen.
This is perfectly normal.
Computers, phones, and tablets do not have infinite RAM. Android's approach to this problem is to keep your process around for a while after the user has left it, but eventually Android will terminate your process to free up RAM for other applications and their processes. You can read more about the Android process model in the documentation.
It can be possible that ‘deep clean' option is enabled by mistake on your phone. What deep clean does is, whenever you minimize an app , it releases all the memory associated with that app, and hence when you again open that app, it will start as if it is new. To check the 'deep clean' option,
go to the
Developer options -> 'Don't keep activities' -> disable it
If it is not disable please disable it.
There are api calls to activity.setRequestedOrientation(orientation) which perform a "soft" rotate, which is not a "hardware" rotate. In other words, it is different from manually pressing Ctrl+F11/F12 to rotate the screen.
In testing of some applications, the behavior of the app could in fact differ due to this subtle difference. For example, ConnectBot crashes when I use the api call to rotate back and forth multiple times.
My question: how can we send host key events to the host emulator process?
UPDATE: I added calls to instrumentation.waitForIdleSync();, but it doesn't help.
I have been seeing errors come back from my application that it's force closing after the system stop's it and the user bring it back to the front at a later time.
I have some idea's as to what is causing this but I would like to be able to reproduce this error before attempting to fix it.
Does anyone know a way to get the android system to behave like it needs the memory my application is using and close it so I can easily and continually reproduce this error?
Using the Dev Tools app on your emulator, you can have the OS destroy an application as soon as it's stopped.
From the documentation:
Immediately destroy activities
Tells the system to destroy an activity as soon as it is stopped (as if Android had to reclaim memory). This is very useful for
testing the onSaveInstanceState(Bundle) / onCreate(android.os.Bundle)
code path, which would otherwise be difficult to force. Choosing this
option will probably reveal a number of problems in your application
due to not saving state. For more information about saving an
activity's state, see the Activities document.
You can find this under Development Settings once you're in the Dev Tools app. So, when running your application, you could just switch to another application (like clicking on the emulator's hard phone button), and return to yours to test the destroy/create process.
If you are using Eclipse or DDMS you can select your app in the process list and hit the stop button. This should close your app.
It is a common behavior in Android that when an app is minimized, it will resume it's state when it becomes active again. This is the default behavior and you don't have to code for this.
I observed that with Monodroid, this is not the case, the app always restarts, losing any state it has before.
Is this a bug? And what is the work around for this behavior in Monodroid?
How to replicate the behavior:
Create a new Mono droid project
Run the app it generated. (A counter app, that increments per click of button)
Click the button, it will increment a counter
Minimize the app, that is, go to other apps in the phone.
Go back to the Monodroid app. It should have restarted with the counter being reset.
Any solution for this weird default behavior of Monodroid?
http://bugzilla.xamarin.com/show_bug.cgi?id=1919
I developed a pretty simple game that uses a custom view for drawing to the screen. On my phone (Android 2.2), I can press the home button on the device and do other tasks. When returning to the game, it is restored to the exact state that it was before. The thing is, I didn't have to override any methods or really do anything for this behavior to occur. However, on Honeycomb, it resets everything like I would expect.
It's very puzzling... I was wondering if there was a way to make Honeycomb behave like 2.2 in this regard. I'm not too familiar with saving view states, but since I have a LOT of variables (hundreds, depending on how custom objects are saved), I imagine it being unpleasant to manually do.
I was able to solve it. Kind of.
Basically, the problem was caused by the way that Android handles the screen being fixed to portrait mode in my activity. In 2.2, Android would open the activity in portrait mode and not restart the activity. However, in Android 3.0, it opens the activity, and THEN rotates the screen, causing it to restart the activity (since that happens when a rotate happens).
To fix this, I added the following to my activity in the manifest:
android:configChanges="keyboardHidden|orientation"
This tells Android that you will handle config changes yourself. In my case, I do nothing, since my application is locked in portrait mode.
The reason the state isn't cleared when the application is paused is because onCreate() doesn't get called. I am aware that Android can kill the application though, which would call onCreate(), so I will still have to handle that situation by saving the Activity variables and recreating the View with them.