My app requires OpenGL-ES3, and states this in the Manifest.
Yet, somehow, it frequently gets launched on ES2 devices, judging from the crash logs. I don't understand how the user managed to install it on an incompatible device, but here we are.
I want to add detection for ES2-only devices. Once detected, I need the app to warn the customer and then completely shut down.
There does not seem to be a proper manner in which an android app (its process) is ended. Android will just keep it alive, even if you call something like finish().
How can I force a REAL exit of an incompatible app?
To get the openGL ES version take a look at: Is there a way to check if Android device supports openGL ES 2.0?
To exit from the app, have you try this?:
getActivity().finish();
System.exit(0);
Related
I upgraded a react native project recently from expo SDK 36 to 38. It compiles now, but anytime I click on "Debug Remote JS", it causes the UI to become slow and unresponsive, only occasionally picking up the on click events. I created a bare bones project to duplicate it. To verify, either run expo init from cli or here's a project https://github.com/seniordevops/tab-application.git. Click the tabs without the debugger on, then turn on debug remote JS and watch the slow down. Happens on both Mac and PC. Any ideas on the root cause?
This is mostly due to the fact that the clock on your PC and mobile are not synchronized.
You either have to synchronize them or have the phone clock one second earlier than your PC/Mac.
I suspect the reason could be an upstream problem of react-native. Please check this expo-cli issue:
https://github.com/expo/expo-cli/issues/2405
a maintainer reports:
when you are debugging on your device, the javascript is being
executed in your browser on your computer :(
I've a Titanium application that works on Android. Now, I want to make the Blackberry version.
I've tried to create a bar file in Titanium, but I use a lot of Titanium properties that are only for Android and iOS. So, the app crash.
I know you can repackage an apk to bar using command line tools. I've used it and it works. It converts the apk to bar, and I able to load it in a device (Q5). My problem is when I use apk2bar command, I receive a lot of warnings with different levels (a lot of severe warnings).
Severe warnings is because Titanium use native access.
I don't understand why the result of the conversion is succeed with these warnings, and why I can install it on device without any problem/error/crash.
Is there a way to remove something from Titanium and remove these warnings?
If I upload this .bar to Blackberry word, will it work?
Thanks!
Vila,
Those levels of warnings are there to let the developer know about potential issues. This does not mean that your application will not work.
Native libraries are supported in latest BlackBerry Android Runtime so you should not have issues, but don't forget to bundle them with your application.
Also, be sure to be using the latest dev tool to convert your APK to BAR FILE.
https://developer.blackberry.com/android/tools/
Find here also the API support to ensuer you will not have issues with your app features
https://developer.blackberry.com/android/apisupport/
This might be esoteric but here goes.
I'm developing a program in WPF for use on a multitouch screen. I'm using the Surface 2.0 SDK and trying to get the Toolkit to simulate inputs and run the stress test. However SurfaceStress.exe is throwing an error:
Error 0: Cannot get reference to virtual digitizer controller.
and Input Simulator is giving me a timeout error looking for the controller.
I've read up about it on MSDN http://msdn.microsoft.com/en-us/library/ff727911.aspx
I know it can't run two controllers at the same time and it's not on a SUR40. It says "Tablet PC Settings" would only appear if the Input Simulator is running. But it's running anyway and its Setup button is grayed out. I don't have a touchscreen but I do have a Wacom Bamboo tablet connected. Has anyone else had interference between a tablet and Surface Input Simulator?
It was in Device Manager. Bamboo touch drivers disabled the Virtual Digitizer Controller which was also listed as a device. Flip the switches and rode off into the sunset. good job, me! o/
I've installed Appcelerator Titanium Studio on a PC and I was not able to run the android simulator on it, so I was saying to myself "it should work on Mac at least"... and I installed a new Mac with Titanium on it, downloaded the SDK, then I imported the Kitchen Sink example and configured the run configuration with the default settings... and I'm getting exactly the same problem which is an infinite loop with the 'audio_flinged died' problem! So the best I can do is to view the Android simulator with the black window and "Android..." written on it.
What can I do to finally launch that example that is supposed to run? The best I did with my Windows 7 setup was to get the screen of an android cellphone WITHOUT any app on it (default apps), so it's pretty unuseful.
I'd really like to see what Titanium is capable to do.
The Mac ends (after a few mins) with "Launching New_configuration" has encountered a problem. Session initialization failed. "Session initialization failed Failed to get version"
The problem of the infinite loop with "AudioFlinger" still persist in the two cases (PC/Mac).
Any help would be greatly appreciated.
I helped someone with a similar question. He was getting a error which you don't seem to be but my answer walked him through checking the configuration was ok etc.
might help you:
Error running Android emulator from Titanium Studio
Just a quick q about iOS development..
I'd love to be able to run a certain game emulator on my iPad..
If it's released under open source is there any thing stopping me from compiling it and running it in an emulator or getting a provisioning profile and running it on my device?
Do jailbroken apps tend to use libraries that wont run on a vanilla copy of iOS?
I.e. Do they patch the kernel to get full control of the video controller etc..
Thanks
Daniel
I think the jailbroken apps can utilize eglibc or glibc, as when I jailbroke me iPod Touch, I remember looking over the installed packages, and remember seeing something along the lines of glibc.
In short, I think if the app is self-sufficient, you probably could package it with XCode, but if it requires some low-level APIs and libraries, you're out of luck.