My app is using Firebase Analytics and I believe starting in iOS 13.2 started getting the errors described here: Why I get the console warning: [Process] kill() returned unexpected error 1 when I load a WKWebView in iOS13.2?
I guess it wasn't a big deal
Since I planned for my app to go live in January, I began bigger tests in physical devices. I noticed after a while the app started to behave erratically, specially after receiving a [general] Connection to daemon was invalidated error. This doesn't occur in the simulator
Searching the internet I found a post that describes the same problem: https://forums.developer.apple.com/thread/124306
In my case, only Firebase seems to be calling WKWebView, but every time I open the UIMenuController I get the error described in the console and the app appears to be missing inputs. This is specially troublesome with UIScrollViews, which my app uses a lot. The pinch gesture seems to work at will. On an iPhone 6s, the issue isn't as noticeable, on an iPad, it's like a 50% chance the pinch gesture will work properly
Outside of removing Firebase, is there a way to mitigate this issue?
1 June 2020: The console message still persists, however, I have seemed to resolve the UIScrollView issue by deactivating delaysContentTouches, now the pinch gesture seems to work most of the time
23 October 2020 If anyone notices their app starting to behave erratically with no apparent reason I HIGHLY suggest to test it on an iOS 13 physical device if possible. Seems that Apple removed the warning from iOS 14, but testing it on iOS 13 you can pin point the exact reason after the warning appears in the console
Upon further testing, I've reduced the view down to a dead-simple UI view with a single SwiftUI TextField and the 'Connection to daemon was invalidated' still appears after I type the first character into the field. Soon thereafter the app crashes with a sigAbort. (So I don't think the reason is the UITextView wrapper I was using in the previous post). Once the invalidated message appears the app is doomed to crash, not right away but soon thereafter.
I have no idea what causes the 'invalidate' message and a Google search seems to imply that no-one else does either. Some folks appear to have made (experimental?) changes to their UI that stops the message but it appears to be impossible to determine a definite cause. (and like before it only occurs on a real phone)
Same issue without using Firebase at all. What I did: Delete build folder and compile again. Issue does not appears again.
On Xcode:
Clean the Build Folder
This will delete all of the products and intermediate files in the build folder. To clean the build folder you can use the shortcut Command+Option+Shift+K or Menu Bar → Product → Hold Option Key → Clean build Folder.
On Flutter:
Just delete build folder.
Related
I have used Expo a few times successfully before, but for a few days now, I am unable to get into the Expo App. Whenever I open it, I see the Expo icon for a few seconds up to even minutes, and then it redirects me to the blue "Something went wrong" screen, as if I had tried to open an app.
But I didn't! It doesn't even let me scan a QR code, it just always shows this error. If I click the back button in the app, it simply terminates. I have ensured that it is the latest version and already reinstalled it once.
It seems like it somehow had locked itself onto an old, now non-existant server, and kept at it after reinstalling the app. Here is how I solved the problem:
In the metro bundler, choose connection type "Tunnel" and copy and send the URL to your phone. If you then click on it on your phone, it should redirect to the expo app. After that it got unstuck and I could finally use it normally with the QR code again!
The tools sometimes do get locked into this state.
Close and restart all components (Expo cli, browser tabs and clients) making sure to:
Kill any stray processes on the server (you need to check Activity Monitor / Process Explorer or similar depending on your platform)
Force quit all client devices and simulators using the correct method for each platform. To verify that the client process has actually been killed, check that the app splash screen is displayed for a short while when invoking it.
Clear the Expo cache when starting again: $ expo start --clear
I ran into the same issue. Solved it by going to the left sidebar in the Metro Bundler and sending a link via email!
I've tried many of the solutions and only one worked for me (which i found trying random things). I already had 'allow display over other apps' turned on (Android/OnePlus 6t) and didn't think it had anything to do with that. But I tried this...
Close the Expo app, go the the app settings and turn off 'allow display over other apps', open the expo app and [when prompted] turn on 'allow display over other apps' again.
That seems to work in my case - at least until the next time.
I've been working on a game using Google VR in Unity3d and I recently updated my version of unity3d and the (built in) Google VR SDK to the latest version. After doing so the pre-launch report (automated testing on firebase) is showing crashes, during the unity splash screen, on 5 out of 6 devices.
This is the issue that is reported:
Issue: Crash of app uk.co.softkitty.puzzleroom running instrumentation ComponentInfo{com.google.android.apps.mtaas.crawler/android.support.test.runner.AndroidJUnitRunner}
Not very helpful, it looks like a generic unit test result if the app closes unexpectedly . I've looked through the logs and cant find anything unusual from my app or unity, but I did find something. It looks to me like this may be being caused by the test script itself:
10-27 01:54:54.494: I/ViewInteraction(19677): Performing 'single click' action on view (with class name: is "android.widget.ImageButton" and with id: uk.co.softkitty.puzzleroom:id/ui_back_button ...............
This to me, looks like the test runner is exploring the app UI and the first thing it does is click the "back" button. Which I would expect to close the app. I also tried using Firebase directly, which seemed to confirm it:
Firebase Activity Map
Does that seem likely that this is just a bug/red herring caused by changes to unity/GVR Or even firebase? Has anyone else experienced this?
I just don't want to release it if it really is crashing on so many devices!
Many Thanks
I asked Google Play Support about this and they got back to me.
They have confirmed that the issue is caused by a new crawler used by the Pre-Launch report. Details can be found here under the section "Pre-launch report versions"
They've escalated the issue and have also provided a workaround:
Sign in to your Play Console.
Select an app.
Select Release management > Pre-launch report > Settings.
In the “Pre-launch report version” section, move the Opt-out switch
to the right until it turns blue.
I haven't verified this yet but will mark as answer once I have.
Edit
I have tested this and all the tests pass again so this looks like a good solution for now.
We got this when uploading our APK as well. It started October 27th and crashed the following 4 days until we changed our setup. I couldn't see anything in our code base that should trigger this problem, so I wonder if it's related to changes on Google's side.
However, we did just did two changes and now everything's working again.
We added the following line to proguard-project.txt:
-keep class android.arch.** { *; }
I assume this was what fixed it.
At the same time we changed the compileSdkVersion and targetSdkVersion to 27 (and correspondingly all belonging support libs). For all I know they could have fixed it here too..
Edit:
To more directly answer your question: Yes, it does seem likely that this is just a bug/red herring, not on Unity's side, but in Firebase Test Lab or in Google's support lib. I tested the APK that failed the pre-launch tests and it worked just fine on my device.
I'm writing this post because I don't know what I can do.
I'm developing an big app for iOS with a lot of users for my company; to log error and crashes I'm using Microsoft MobileCenter (Analytics and Crashed ver. 0.6), Xamarin.Forms ver. 2.3.3.168 and a lot of components such as Xam.Plugins, SQLite, PCLStorage, SharpZipLib.
As MobileCenter request the minimum target version for the app is 8.
Apart from minor bugs, the big problem is difficult to explain. I'm trying to ask you an advice.
The app is working fine. If I test it, I can't have any problems. At same point the app crashed for any apparently reason. No logs, no crashed, no nothing in MobileCenter. From this moment it's impossible to start the app and I can't have any logs about it: I can see the splash screen but after than the app is crashed again. It seems the problem raises after taking photo with camera.
When the app starts, it deletes images (if there are any in the folder), send a file to my server, and check with CrossDeviceInfo what the OS version is. Then the first page is called.
I tried to understand the problem to read the log in Xcode after connecting my device to my iMac but it's incomprehensible.
If I try to read the View Device Logs I can find one crash for my app but the log is still incomprehensible for me.
Then from Xcode I tried to open Organizer and under Crashes...
If I connect the device with this issue to my iMac and I deploy the app on it, the app is working fine. How can I understand where the problem is to fix it?
Update
In my App.xaml.cs I initialise MobileCenter like the following code:
public partial class App : Application
{
public App() {
// my code
}
protected override void OnStart()
{
MobileCenter.LogLevel = LogLevel.Verbose;
MobileCenter.Start(typeof(Analytics), typeof(Crashes));
}
}
It's Benjamin. I've already replied to you issues in our intercom but I wanted to reply to your issue here.
This scenario is not an actual crash but a kill of the app process by the operation system. The SDK runs as part of the app process and therefor can’t ever figure out that this kill even happened because the process is fully removed right away. Technically this is not a crash from an SDK perspective that it can detect and provide details for. Every single 3rd party SDK has this limitation and there is no way around it as Apple doesn’t provide the technical possibilities to do so.
In addition, none of your provided crash reports contain any reference to Mobile Center thus I can rule out our SDK is the cause of the kill.
I hope you find the cause for the issue.🖖
I've created a BlackBerry webworks application that consists of multiple pages each loading data from a local SQLite database.
The application works fine until I've navigated between a certain number of pages, at which time the application shows a blank alert box and hangs on the loading screen that shows between pages.
This is using the Bold 9700 simulator but also occurs on the device itself. I've tried disabling caching, as well as increasing the size of the cache, both to no avail. The console shows nothing, neither does the event log on the simulator.
Has anyone come across this behaviour before? More importantly, how do I get any useful debug information out of the simulator so I can track down the culprit?
Many thanks!
Edit: I've tracked this down the the html5_init.js library that Blackberry recommend for translating HTML5 to Google Gears calls for OS5. Any ideas?
Further Edit: I've removed all traces of html5_init.js and instead I'm using the Google Gears API directly. This resolves the problem but requires that I double up all my database code. Google Gears requires that you call clear() on all ResultSets so that they don't cause a memory leak but html5_init doesn't offer that functionality. Maybe that could be the cause?
I have this very strange problem on a big flex app where it would run fine with the debug swf if the user has debug flash installed but will have some disparities for people with standard version of flash.
These disparities include:
No pop ups
loose all event catching
Weird positioning of a button
I read somewhere that updatedisplaylist was handled differently ?
For now i will try the export release way instead of the bin-debug swf, and to go back in the commits to see what was the turning point.
Any similar experiences ?
I've been using Flex for a long time and have never heard of any problems like these being related to using the debug vs standard versions of the Flash player, but I have experienced problems similar to what you're experiencing.
When an exception occurs in your application, like attempting to access something in a null class or trying to access element 10 in an array that only has 9, the debug player will pop up a window stating that an exception has occurred and give you a stack trace, even if you're not actively debugging the app. The standard player does not, so the user will have no way of knowing that something went wrong.
In my experience after an uncaught exception occurs it can make all running code from that point on very unstable, causing all of the problems you list and more.
I doubt your problem has anything to do with the two different players beyond the standard one not giving you any feedback about the state of your app.