With the Android 2.2 update came a new car dock app. If my app is in the foreground when I dock my phone, my app gets killed or paused or something, and when I try to re-open my app, it's all messed up. It has lost its state information.
Does anybody know what the car dock app is doing? At very least, it seems to be force killing all running applications or some other destructive behavior.
I guess once we identify what it is doing, I'll be able to go about coding around it.
Going into a car dock is a configuration change (so apps can present a car-specific UI if they want to, for example). This means your activity will go through its normal process of being destroyed and later recreated.
If you are abusing android:configChanges to not have to deal with this, then the answer is to NOT do this. As we've always said, this is there for certain specific cases where you want that optimization. It is not an excuse to avoid dealing with configuration changes. If your app doesn't deal correctly with configuration changes, there will always be various ways it can be broken. The new car dock feature is just making that a little more obvious.
In fact I very much recommend that developers do not use android:configChanges. Keeping the normal behavior is a very good way to test this part of your app to ensure that you are doing it correctly, and will behave correctly when it happens to you for other reasons (because it most certainly will). Turning off config changes for the orientation switch makes it a lot harder to test this part of your app. Except for very unusual situations, you really should keep the normal behavior here and make it work correctly.
All apps lose their state when they're killed. In fact, they lose their information when you change the orientation, unless you specifically save it (say, in onSaveInstanceState).
If you want your information to be so persistent that it can survive an app switch (or system reset), you can save your state in the SharedPreferences instead of the bundle you get in onSaveInstanceState.
How do you currently save your state? Do you do that at all?
Btw, you can also add a broadcast receiver to listen for ACTION_DOCK_EVENT and check the state for EXTRA_DOCK_STATE_CAR and save your instance data, in case you don't like the general SharedPreferences idea.
Related
I want to know if there's some way to maintain an Android activity always on top regardless of any other apps present in the phone device that might put on top on it, except for home screen via home button, which cannot be helped.
I've checked that if a whatsapp popup displays over my activity, that activity starts showing a strange behavior.
Maybe this can be controlled by some events, but I think it's much easier to avoid anything that might put on top of app, so no strange behavior appears.
Is there any way to do that?
It depends on the level of control that you have over the device. If your app is going to be publicly available you cannot (and should not) do much to prevent other components from coming on top of the stack.
Apart from that, one thing you can do is check for UI changes through this: https://developer.android.com/reference/android/view/View.OnSystemUiVisibilityChangeListener or/and activity lifecycle events (like onPause) and prevent whatever this "strange behaviour" is.
The inverse way to deal with this is to prevent any app from having the "Draw Over Other Apps" permission, but as I said it depends on the environment of your deployment.
The title is pretty self-explanatory. I understand what this developer option does.
What I don't understand are the following points:
Why was that option introduced, in the first place?
After all the changes that the framework has seen throughout the years, is it still useful?
I am eager to know the reasons behind this option.
I believe it's a feature used for debugging purpose.
From the Titanium doc:
Don't keep activities under the Developer Options menu. When this
option is enabled, the Android OS will destroy an activity as soon as
it is stopped. It is intended to help developers debug their apps. For
example, it can simulate the case that Android will kill an activity
in the background due to memory pressure. In normal use, it is not
recommended to turn this option on because this may lead to unexpected
issues on the apps, such as freezes, force closes and reboots.
It sounds like it basically helps testing deterministically how your app behaves when the OS shuts it down due to any reason (out of memory and so on).
So, this replied to point 1. Point 2 is: Yes, I guess :)
EDIT: further references
On SO How to know "Don't keep activities" is enabled in ICS?
an interesting thread about that on androidcentral (reply from MagouyaWare)
The Android framework may destroy your activity any time it's in the background or backstack, and you should write your activities so they behave correctly when this happens. Exactly what that entails varies depending on what the activity does, but it generally includes implementing onSaveInstanceState(...) and restoring any previous state in onCreate(...).
The "don't keep activities" developer option simply changes the framework's behavior so it will always destroy your activity when it goes into the background or backstack. This allows you to test how your activity responds to what is normally a rare occurrence.
A link cited in another answer says:
In normal use, it is not recommended to turn this option on because this may lead to unexpected issues on the apps, such as freezes, force closes and reboots.
This is incorrect. If your activities are written properly, the only effect of having "don't keep activities" turned on should be (possibly) slightly higher battery and CPU usage from constantly saving and restoring persistent state. Any apps that exhibit "unexpected issues" or force closes when this option is on are broken and need to be fixed. As a developer, I habitually leave "don't keep activities" turned on all the time. I've seen a lot of buggy apps, even some of Google's own. But it's never caused a reboot, and I don't think there's any way it could.
I had at least two issues when this was enabled:
1) I was getting an error "Unable to complete previous operation due to low memory" that prevented uploading of any attachment to a website using Chrome, but not with Firefox. I found elsewhere that enabling the "Don't keep activities open" option could have been the problem - it was.
2) I was unable to move files to the SD card. Disabling the "Don't keep activities open" option got round this problem.
Also found elsewhere it can slow things up generally because caching is compromised.
Sometimes apps that I had moved to the SD card suddenly 'greyed out' and became inaccessible. Rebooting solved this, but was becoming an irritation. Too soon to tell if that was another problem caused by this 'feature'.
These problems (and issues with the microphone in Zoom) all started within the last month. I don't know how DKAO ever got enabled, but it's a no-no as far as I'm concerned.
I was hoping to make an app which dimmed the soft buttons to dots on the Galaxy Nexus, using the code from this answer. For completeness, this is the code:
getWindow().getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_LOW_PROFILE);
Here's the question, is it possible for the app to make this setting system-wide rather than just while the app has focus? So ideally the app would run in the background and would keep View.SYSTEM_UI_FLAG_LOW_PROFILE as the default as long as it's running, for any and every app that you open (unless that app specifically overrides it, I suppose). Is this possible or does this fall outside the realm of what an Android app has permission to do?
A sample use case is this: I use the "Screen Filter" app to reduce brightness a lot for nighttime ebook reading or misc app usage, but the soft buttons are still very bright and distracting, so I wanted to make an app that would dim the soft buttons system-wide while running (like how "Screen Brightness" reduces screen brightness system-wide while running) so this wouldn't be a problem.
As CommonsWare states, it's not possible for an application to change this setting. It's an Activity based setting, that must be set for every single Activity, if you want to make it fullscreen, hide the soft keys, etc.
It's also worth pointing out that you should probably refrain from using it in all your application activities. It's really only meant for games, video players and other applications that need to enter this "low profile" state.
Feel free to accept CommonsWare's answer - I just thought I'd give you a bit of background info on the subject.
is it possible for the app to make this setting system-wide rather than just while the app has focus?
No.
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.
HI ,
I need to keep track of installed applications which are used most and least in android device... can anyone help me how to do this programmatically in android...??
My question some thing like , I need to capture the event/Intent which will/may happen when the apllication is launched every time...(like BOOT_COMPLETED will be brodcasted when device booted).
This does not seem possible (unless the launcher/home screen or applications cooperate, e.g. through instrumentation: but that would be strange in production code!). See also this related question.
Edited to add: indiscriminate capture of application launch intents is not AFAIK permitted. Were Android to add such functionality, the security implications would be significant (particularly if interception or modification were allowed!). What you are describing could be (partially) achieved by replacing the home screen.
Some degree of usage information is collected already - from the launcher go to settings - about phone - battery use.
I think this resets every time you go on a charger, and don't know if its visible to ordinary apps.