I have an Android app with most of the code written in native. I want to use startNativeTracing() to get the trace files for the native code. But I find that the function works only for emulator (QEMU) and not on the actual real device.
Why is the function not usable on the real device?
Is there any other way to get the trace files while the app is running on the actual device?
Related
I'm developing an VR Video Chat application using Agora.io api and Unity3D Engine, in which a main user streams his webcam from a standalone Pc to users equippped with an Oculus device.
As soon as I try to upload the VR app to the Oculus Server, I got that error:
This app uses permission(s) that are not compatible with this device: android.permission.CAMERA.
How do I overcome that issue?
Any suggestions?
I haven't programmed for Oculus yet but here are some ideas:
First you may try just to set android:required=“false” in the manifest to see what happens?
Secondly check the official Oculus documentation here to see if helps? https://developer.oculus.com/blog/tech-note-android-plugins-and-permissions/?locale=en_US
"You will need to modify your Android Manifest file. Because the Oculus Quest doesn’t have cameras (well, none that can be used for this demo) we will get rid of the camera use requirement ( ) located on line 9 in the folder Assets/Plugins/Android/AgoraRtcEngineKit.plugin "
This is a quote from this quick start tutorial which will get you up and running with Agora.io Video chat and Oculus Quest. It explains how to stream your webcam from a standalone PC to Oculus Quest. https://medium.com/#jake_agora.io/live-realtime-video-to-vr-oculus-quest-6bbb74e4fc63
Just in case anyone else falls into this. The solution posted where you remove the entry from the Agora included manifest doesn't work anymore, and I can't identify where its being added from, perhaps Agora can post a solution. The only way around it is to export from Unity, edit the Manifest to remove the unwanted camera permissions and then build in Android Studio.
I created a Desktop AIR in Adobe Animate CC 2017 with AIR 23, when Test everything works, after Build in my pc everything works, when test to VirtualBox (Application with runtime embedded) it run but some features like buttons events and url events doesn't works, what is problem?
After review codes and test for many times i found correct issue, when a hidden runtime error occurred some related part doesn't works properly, I used try() catch() for handle errors and external video playback instead embedded, now build works on other computers without problem.
I don't have a new Apple TV, but am working on prototyping a game for it using the simulator. Unfortunately, I can't seem to get GCController to list the Siri remote as an available controller, as the tvOS docs indicate. My list of controllers is always 0 elements long, even if I call startWirelessControllerDiscoveryWithCompletionHandler().
Does anyone have any suggestion or sample code for getting input from the Siri remote?
The current version of the tvOS simulator apparently does not support this functionality. I was able to try my code on a friend's dev kit, and it registered the remote as a Game Controller as expected. For now, the answer appears to be "use real hardware" or "wait for an updated to the tvOS simulator".
You might take a look at https://github.com/csgulley/AppleTVSimulatorController. It is an implementation of Game Controller that I wrote to allow testing with the Apple TV simulator.
In the documentation for the FileSavePicker, it states:
Warning If you try to show the file picker while your app is snapped the file picker will not be shown and an exception will be thrown. You can avoid this by making sure your app is not snapped or by unsnapping it before you call the file picker.
I'm currently checking to see if the app is snapped or not, and my app responds differently in each case. My default behavior isn't showing the FileSavePicker, either, so I can't just try and then fall back to something else. Nor do I want to force the app to unsnap.
However, ApplicationViewState is deprecated post-8.1. In that documentation and related searching, developers are advised to access the window size directly in order to determine proper behavior. However, if the view state is no longer available, how do I know if the file picker will throw an exception or not? At what size is the app considered 'snapped'?
Also, I'm using C++, so an answer compatible with C++ would be splendid. I wouldn't mind seeing the C# solution, too.
In regards to the FileSavePicker documentation - I believe that it is just an oversight. The text you quote was from the Windows 8 version, and to me it looks like it didn't get updated for Windows 8.1.
If you look at the FileOpenPicker documentation, you see that it was updated:
Important In Windows 8 if you attempt to display the file picker while your app is snapped, the file picker will not be shown and an exception will be thrown. You can avoid this by making sure your app is not snapped, or by unsnapping it before you call the file picker. ...Note that Windows 8.1 does not define a specific snapped window size. Instead, users can resize apps to any width, down to the minimum. Therefore, if your app will deploy only on Windows 8.1, you can ignore the EnsureUnsnapped function and calls to it in this topic's example code.
The last sentence (in bold) above essentially says that you can ignore state and safely open the file dialogs if you are running under Windows 8.1.
To test the above, I used VS 2012 to create a Windows 8 application with a file save picker (in C#). I believe the outcome will be the same with C++, but I am not 100% certain.
I should note that my test application does not check for view state and always tries to open a file dialog.
When the application is run under Windows 8 in the snapped state, the application causes an error. That same application (same binary) when run under Windows 8.1 allows the file save dialog to open without issue. As mentioned previously there is no snapped state in Windows 8.1, so the way I tested the application was to open the application to the minimum width (320 pixels).
To summarize:
If you are targeting Windows 8.0, you will have to make sure the application is unsnapped prior to opening the file picker dialogs.
If you are targeting Windows 8.1, you do not have to worry about state, as the file picker dialogs no longer throw any exceptions.
I'm currently trying to make the HTML5 viewer.js example work inside an android WebView.
WebView initialization looks like this:
webView.setWebViewClient(new WebViewClient());
final WebSettings webSettings = webView.getSettings();
settings.setJavaScriptEnabled(true);
webView.loadUrl("file:///android_asset/index.html");
The thing is that in a Nexus 7 running Android 4.3 JB (which uses Chrome as stock browser) the example fails and renders: Error loading document metadata (did you check the url?). I also tried a Samsung Galaxy Nexus running 4.2 with same results.
But on a GBox (MediaBox, Android TV) running Android 4.0.4 ICS (which uses the default Browser application), it takes a while but it renders the document. With a lot of styles problems, but it can render it.
However, if I serve all the assets from a remote server (for instance, a Python SimpleHttpServer) and load the WebView using the index page url, it doesn't have any problems in any device.
Is this a Crocodoc View API specific issue regarding cross-browsing?
This is a Chrome-specific issue, see here: Problems with jQuery getJSON using local files in Chrome
In summary, Chrome's security model blocks AJAX requests from file:/// URLs. This causes trouble for viewer.js because it utilizes AJAX to load resources in a performance optimized manner. The recommended solution is to always serve the assets through a web server.