I have a fullscreen, immersive-sticky activity A, which works fine due to: https://developer.android.com/training/system-ui/immersive.html.
From there I want to take a picture using startActivityForResult() as in: https://developer.android.com/training/camera/photobasics.html
However, before leaving A into the system camera app, the system bar appears shortly in my app, which is considerably irritating. How can I prevent this?
Best would be to prevent the system bar in the camery app as well, but I think this is futile.
Related
I am trying different options to disable system bar permanently for my android app. Now, the most successfully solution is stop the android systemui service.
service call activity 42 s16 com.android.systemui
But, this cause serious issues in my app. I have 3 android UI components on screen, 2 webviews and one videoView. Upon disabling the UI service, my webviews will show on screen for a second and then turn completely black(maybe disappeared). Only videoview is playing. Because I am refreshing the webview every 10seconds, the webview will shown up another second upon each refresh and gone. In addition, all my buttons are gone as well. Any suggestions? Thanks
How could you consider to stop system services?
You shouldn't mess with your users' devices!
Why didn't you just try to hide the Status bar and/or the Navigation Bar
Edit:
Another solution is to implement the Kiosk mode as in this tutorial or Screen pinning if devices are running Lollipop
In my application I have two Activities A and B. In Activity A, i disable the notification bar in manifest but in Activity B notification bar is enabled. While navigating from Activity A to Activity B there is some jerk in User Interface. Can any body help me in this.
I think jerk is happening because the phone/tablet on which you are testing either:
has a weak GPU and thus cannot render the transition fluidly, or
the version of Android does not support it.
This is not a problem with your app. Ideally there should be a smooth slide-in, like on my Nexus 7.
A nice way to solve it is by either having the notification-bar on in both Activities or off in both. No jerk :)
Have you tried performance testing your app? Your UI could be causing the problem. Do you see the same Jerk if you temporarily disable the notification bar? Have you tried using the Hierarchy Viewer on Activity B?
So I'm making an app for my company, for a android tablet to be used like a "kiosk". Users should only be able to use this one app, and be able to do nothing else on the tablet.
I've found a solution by using WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED on the activities. However, when I switch to another activity in my app, the leaving activity fades out, shows the lock screen quickly and then the next activity appears.
I'm guessing that this is because the FLAG_SHOW_WHEN_LOCKED is in onCreate(), as opposed to earlier in the Activity creation process.
Is there anywhere else I can put this flag, or any other way to prevent the lockscreen to be shown between activities? It's not a huge issue, but it is a poor user experience.
It is a Samsung Galaxy Tab 10.1 Running ICS 4.0.3.
I was able to best fix this by using Fragments and using FragmentManager to swap out the fragments in the activity, so the lockscreen was never shown, since I never left the activity. The android developer guide has a good example for this.
http://developer.android.com/reference/android/app/Fragment.html
I have an app which has an activity A, that lets the user click on a thumbnail and go to another activity B which shows the thumbnail full screen. On activity B, if the user clicks anywhere on the screen, it closes the activity.
Both activities are defined as portrait in the manifest, and both have the onConfigChange value to contain the orientation flag.
It works perfectly on all versions of Android and all devices that I've tested, except one - Motorola Xoom, with Android 3.1. On the Xoom, if the user navigates quickly between the activities (back and forth), it has a chance to show activity A in landscape mode for a very short time, as if it planned to switch to it.
Not only that, but if it remove the flag of the onConfigChange in the manifest, activity A might re-create itself from scratch on this special case.
What could cause this weird thing? Is it some weird bug on android 3.1 or the Xoom? Is there anyway i can fix this issue? I could have something that blocks the touch on activity B for a few ms on the beginning, but that's just a workaround.
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.