I am using 'sdktools' for calculating routes and navigation. Meanwhile i am getting this issue in design, I tried with 'preserveGLContext' to true in the mapView. How can i solve this issue?
Without knowing your app architecture I can't provide a lot of feedback - can you replicate this behaviour in the demo project? (your map seems corrupted but I can't tell what is happening behind the scenes to arrive at this scenario).
When using multiple map views make sure that the GLSurfaceView is notified when the activity is paused and resumed. GLSurfaceView clients are required to call onPause() when the activity pauses and onResume() when the activity resumes. These calls allow GLSurfaceView to pause and resume the rendering thread, and also allow GLSurfaceView to release and recreate the OpenGL display.
Related
I'm running into an issue and I would appreciate some guidance. I'm writing a small Android program in Android Studio that uses MediaProjection to grab a screenshot of the whole screen and then I want to pass that screenshot as a Bitmap to my System Overlay (based on the chatheads example). When the MediaProjection runs and the Imagereader creates the bitmaps, I'm passing the bitmap into a class global variable so I can pass it into my System Overlay service and display it. The problem I'm running into is if I "tab out" to a different app, my methods stop working from the MainActivity. When my app is in focus, everything works well, when a different app is focused, the system overlay contracts and expands like it should, but the screenshots are not being taken anymore. My understand is its because my app becomes "asleep" since it's not in focus. Could anyone recommend a solution? Can I momentarily awake my mainActivity so it can take a screenshot? Can I keep my activity from falling asleep on app switch? Can I bring focus to my app, take the screenshot and then switch focus to the previous app? Any other ways?
My code can be found here: https://github.com/asheron21/FacebookLikeChathead
MainActivity:https://github.com/asheron21/FacebookLikeChathead/blob/master/app/src/main/java/com/example/chatheads/MainActivity.java
Service: https://github.com/asheron21/FacebookLikeChathead/blob/master/app/src/main/java/com/example/chatheads/ChatHeadService.java
Global Variables:https://github.com/asheron21/FacebookLikeChathead/blob/master/app/src/main/java/com/example/chatheads/Globals.java
Thanks!
I have a simple Android application that renders data with our OpenGL rendering SDK to an Android GLSurfaceView. Since we provide and SDK for others to use we need to support all use cases for the GLSurfaceViews. Currently we need to be able to rotate the device while recreating all the Android views and keeping the OpenGL context alive. This originates from a customer needing different layouts in landscape and horizontal mode.
The normal way of going about this would be:
1. Add android:configChanges="orientation|screenSize" to your Activity in AndroidManifest.xml and you will be fine.
This will not work in this case as this does not recreate the views on rotation. Thus by doing this we cannot have different layouts in landscape and horizontal mode.
2. Call GLSurfaceView.onPause() and GLSurfaceView.onResume() from the Activity.
While this is considered good practice it is not enough in this use case as the OpenGL context is destroyed when doing this. Note that we are still doing this, it just doesn't solve our issue.
3. Use an EGLContextFactory to preserve the OpenGL context while rotating.
This is possible and useful as described in, for example, this answer. It feels like a hack, but it definitely works. The idea is simply to create an EGLContext when you don't have one and reuse the one you have if it exists.
The main problem we face when using this hack is that the render thread is destroyed and recreated when the GLSurfaceView is detached and reattached to the view hierarchy. This seems to be by design by looking at the GLSurfaceView implementation.
In our SDK we have some Thread Local Store connected to the thread, so suddenly getting a new render thread is not really desirable. We could probably change some state when the render thread has changed, but we want to investigate if there are better ways of doing this.
So my questions are:
A. Is using the EGLContextFactory the "proper" way to be able to manually save the OpenGL context on rotation?
B. Are there any ways to not destroy and recreate the render thread on rotation (without modifying the source)?
C. Are there any better/simpler alternatives to achieving rotation with views destruction/recreation while keeping the OpenGL context and the rendering thread?
Extra info:
We always call setPreserveEGLContextOnPause(true);.
There are no issues with the rendering itself, it is simply the described related issues that are problematic.
I was trying to use SurfaceView and MediaPlayer to Display video on Android.
I got a bug now that if I press the power button to lock the screen and then unlock it, The Video displayed on the MediaPlayer is gone and there is only sound. Normally for this situation the surfaceView would be somehow freeze to the last frame of the video before I lock the phone.
It works fine when I hide the screen(such as go to home and open another application) But it just does not work when I lock the phone. I think they both pass the onPause and onResume so I do not understand why would there be different logic.
I'd like to know if there is a solution to solve my problem.
Thanks!
I'm not sure exactly what's going on, but there's a general class of problem that is likely the cause of your trouble.
If your lockscreen is orientation-independent, or wants to be oriented the same way the device is, then the Activity won't be restarted to change orientation. In this case, turning the display off and back on with the power button won't cause the SurfaceView's surface to be destroyed. So if your app is relying on the surfaceCreated and surfaceChanged callbacks to fire to make things happen, then things won't happen.
If you leave the Activity and come back, the Surface does get destroyed and re-created.
The relationship between the Activity lifecycle and the Surface lifecycle is a bit complicated; you can find some notes about it in this article, including two basic patterns for structuring an app. Examples of both "styles" of SurfaceView management can be found in Grafika.
I can't make specific recommendations without knowing how your app works, but mainly you just need to look at what your app does with the idea that Activity and Surface lifetimes are not tightly coupled.
OK, I fix this in a weird way, I think it is probably a bug of Android. Don't have time to do enough testing on this.
First surely as #fadden says you need to have a mMediaPlayer.setDisplay(myHolder) elsewhere not in the surfaceChanged or surfaceCreated since they may not be called while resume from locked screen.
For me the problem still persist after I changed it this way. Here is what I changed that solved the problem: Instead of mMediaPlayer = new MediaPlayer(), we should use mMediaPlayer = MediaPlayer.create(MediaActivity.this, fileUri)
I want to have a single video playing in the background of my application, so that when any new activity is pushed on the stack, it will have a transparent background so that the application background video is all the time visible.
How would I accomplish this, without any risk of the activity containing the video gets destroyed at any stage?
What you want is not possible.
You will have to implement this as a single activity, possibly using fragments to handle your changing content. Even then, the user can always exit this activity.
Bear in mind that this will not work well except on devices offering 2D graphic hardware acceleration. That is possible on Android 3.0+ devices when you request hardware acceleration in the manifest. On Android 1.x and 2.x devices, this will likely perform very poorly.
For our game on Android OS we have been using the ndk mainly, to write our game and a thin Java wrapper so than we can support all devices with gles 2.0 hardware.
Our implementation is pretty standard, using the overrides of GLSurfaceView we:
* create/resume the c++ part of the game onSurfaceChanged(),
* render onDrawFrame(),
* inform the engine about lost gl Context at destroyContex() which usually occurs when the app pauses or gets destructed.
When the gl context gets recreated (when resuming - onSurfaceChanged()) we pass back the information to the game and reload all gl resources back in. During the time between onSurfaceChanged() and the first onDrawFrame though the screen is black but I have noticed quite a few 3D games that dont have this kind of a problem (i.e Gun Bros), they also dont seem to reload their resources (unless they have everything memory and quickly load them back in).
Any info on why is this happening?
Just an idea, but if you dump the screen with glReadPixels or similar on destroyContext(), and then the first thing you do on onSurfaceChanged() is to upload that and draw, you will show the user a valid image before your first onDrawFrame.