If my NDK based app is running, and I swipe up from bottom, to get the Task Switcher, my Native Window is destroyed.
Is this normal behaviour? I see this on Android9, and I could have sworn that going to the task switcher in older Android OS versions would not destroy the window?
So bringing up the task switcher causes onNativeWindowDestroyed() being triggered, which leads to a APP_CMD_TERM_WINDOW to be posted and handled by my app by destroying all its OpenGL resources.
It seems wasteful to completely destroy everything, and rebuild everything, merely because the user brought up the task switcher, even if the same task is foregrounded again?
Is this according to spec? Can it be avoided?
My app uses android_native_app_glue.c and properly implements the Android app life-cycle.
Related
Since I upgraded my Android Studio installation to Bumblebee, the emulator has become unusable. It either crashes during startup or gets itself stuck so that the UI is unresponsive and the debugger either cannot install or cannot launch an app. The way in which it fails varies from time to time for no reason that I can understand. although different virtual devices seem to behave differently. I tried deleting my old virtual devices and creating new ones, but that didn't help.
I can't debug my code on a real phone because of a different problem, see my recent answer to Source code does not match the bytecode for Android's View.java.
When it crashes I send a crash report to Google, but they don't seem to be fixing it. The problems started with the first official Bumblebee release 2021.1.1, which seemed to have a complete new version of the emulator, and I'm now on the latest stable version 2021.1.1 Patch 2.
My environment is a Dell Precision M4800 with 16GB of RAM and an 8-core Intel processor, using an external 4K monitor and an external full-size keyboard, running Linux openSUSE Leap 15.3 with all recommended patches installed.
Does anyone have any suggestion short of throwing away my entire Android Studio installation and reverting back to Arctic Fox? Has anyone else seen similar problems?
Tintin's answer didn't work for me: Device Frame wasn't enabled anyway because I had noticed that it had caused problems before.
However the following sequence rather surprisingly, at least to me, did fix the problem.
First make sure that the toolbar is visible at the top of the emulator window: if it isn't, click on the gear settings icon at the top right of the emulator window and enable Show Toolbar.
Start up an emulated virtual device, and before it crashes click on the three dots at the right hand end of the toolbar: this will bring up the extended controls window.
Choose Settings from the list at the left of the extended controls list.
Set the OpenGL ES renderer to Desktop native OpenGL, and the OpenGL ES API to Compatibility (OpenGL ES 1.1/2.0).
Close the extended controls window and then close the Android Emulator window.
Check if there are any zombie emulator or qemu processes still running. If there are, kill them: you'll need kill -9 on Linux.
Try to cold boot an emulated virtual device: it will probably crash before it even gets started up properly.
Close the Android Emulator window and repeat step 6
Try to cold boot an emulated virtual device again, but click on the three dots quickly before it crashes.
When the extended controls list comes up, choose Settings from the list at the left.
Set the OpenGL ES renderer back to SwiftShader, and the OpenGL ES API back to Renderer maximum (up to OpenGL ES 3.1).
Repeat steps 5 and 6.
Now try to boot up an emulated virtual device again. It should work: at least it does for me.
If it doesn't work on your configuration, try all possible combinations of the OpenGL ES settings: you may find one that works.
Logically, changing the OpenGL ES settings and then changing them back again shouldn't do anything, but it does. My guess is that perhaps some needed bit of initialisation for the OpenGL isn't being done by the installer, but it gets done when you change the configuration.
I also faced this problem in both updates in 2021.1.1 it was not working at all. Updated to patch 2 again faced problems turned off Enabled Device Frame it is working OK now
I am trying to develop android and iOS application using xamarin.forms. And already completed the main part that includes Canvas drawing. For that, I have used Skiasharp, to perform operations on bitmap images.
Now, in android,
1. If I try to dispose bitmaps that I initialized before I get SIGSEGV fatal error. (I think this issue is not OS specific)
2. When I continuously run my app for 20-22 minutes, app crashes suddenly.
And in iOS,
my iphone gets hanged when I run my app for long time. And it doesn't start until I uninstall app from iFunBox in my pc.
I wanted to ask if there are ways in xamarin.forms or in native projects to find out where my memory is leaking.
How can I know how much memory of RAM is actually being used at the moment ?
Thank you
For Android, you can use the Android Debug Monitor tool. This is a tool that is installed as part of the Android SDK.
Below is the URL for more information:
https://www.codeproject.com/Articles/798462/Diagnosing-Memory-Usage-in-a-Xamarin-Android-Appli
For iOS, you can try to use the native XCode Instrument.
Below is the URL for more information:
https://developer.xamarin.com/guides/ios/deployment,_testing,_and_metrics/using_instruments_to_detect_native_leaks_using_markheap/
Also, Below is a useful article that talk about Xamarin.Forms Memory management.
Hopefully it will be helpful.
https://igorelikblog.wordpress.com/2016/07/08/xamarin-form-memory-management/
Is there a way to repaint the screen of a JavaFX application when a user returns to the machine and unlocks the computer.
Reason I ask this is that after a user launches the JavaFX application I developed and then locks the desktop and comes back after a few minutes, the JavaFX application screen is blackened out. If the application window is resized, the normal behavior is restored.
I think if the application screen is repainted on desktop unlock that might solve this problem. But the problem at hand is how to capture the desktop unlock event.
Any pointers?
P.S.- I experience this behavior in all javafx applications. Not sure if this is a bug with the current javafx release.
I am running one .NET binary using mono on my Linux platform PC and it is working fine on process startup.
But when i moved my running GUI window to another window and get back to that windows at that time , My GUI Application goes into the hang state because i can not press any button on My GUI window.
I have also used all the optimization option step by step while running .NET binary using mono but still causes the GUI hang issue.
I have debug my .NET binary with some debugging options and found that whenever GUI window application goes into stuck condition at that GDIplus library code is running. so, it seems that there is something is going wrong into the GDIplus library.
does any one have idea what is happening here or any one have faced this issue before?
Please let me know if anyone need any more information and give valuable feedback as sson as possible.
I just pushed my app to the App Store after building release/AppStore build using xamarin's Studio...
Everything was green lighted and ready to go, I only had one person who had not installed the release version.... They installed it and it takes 17 seconds to try to start and is killed (I presume). it does NOT create a crash log on the device.
In the Settings there is a "Debug Settings" section under the app - that I didn't put there, including an option for Xamarin Studio Host which is set to automatic but appears to be able to be set to some other string.. (Another message on what the heck this is, and how come it shows up in the first place, and how to get rid of it)
I'm at a loss how to debug this. I just downloaded and upgraded XCode to the latest, in hopes that will help.. (Although, I'm not using the XCode interface to build, but I expect that under the hood it is using that for parts of this, maybe the libraries or something.) Still, unless the iOS writers are nuts, it should be backward compatible with apps written for iOS 4.0 and later... (Mine is a 4.0 targeted app)
Also, on her phone (which has always been 6.x for all the testing she has done), my app has always taken a LONG time to start up.. but on 5.1 it is very fast.. (I.E. 1-2 seconds vs 10+ seconds on her phone)
Anyone got a clue, I sure could use one right now.. I expect that I'll have to reject the binary, and submit another one...
-Chert
Figured it out.... The issue was with the TestFlightApp SDK...
I removed it and now the app starts up OK... Resubmitted to App Store for approval.