I got following error on google play store but I have no idea why this error occured. They said that it is happing on (Sharp AQUOS sense2 SH-01L Android 9 (SDK 28) ).
I have logcat but I can't find anything in logcat too. I already released to production. This one is my bugs fixed for new release.
ANR in com.google.android.apps.tachyon;PID: 18069;Broadcast of Intent {
act=android.accounts.LOGIN_ACCOUNTS_CHANGED flg=0x5000010 cmp=com.google.android.apps.tachyon/com.google.apps.tiktok.account.data.device.DeviceAccountsChangedReceiver_Receiver };
A similar Error occurred for me as well.
"ANR in com.google.android.apps.tachyon" at same device "Sharp AQUOS sense2 SH-01L"
E/ActivityManager(1566): ANR in com.google.android.apps.tachyon
E/ActivityManager(1566): PID: 18457
E/ActivityManager(1566): Reason: Broadcast of Intent { act=android.intent.action.LOCALE_CHANGED flg=0x11200010 cmp=com.google.android.apps.tachyon/.common.applifecycle.LocaleChangeReceiver }
I believe this device has com.google.android.apps.tachyon app is installed by default and an automatic update for this app could be running in the background (just a guess) which crashes anytime.
The crash is just a coincidence.
It will not happen every time with the same app and with the same use case. It will also not happen with any other device. just update the versionCode and publish the App again.
One other option is to go to the device catalog and mark this device as not supported.
After a lot of research, I think I have finally solved this for my app.
In my case, other than my main activity, the other Activies were only called by my app. In my activities in my AndroidManifest.xml, I had
android:exported="true"
Of course, this allows these activities to be invoked by other external activities/etc
By changing this to:
android:exported="false"
...it prevents the activity from being called.
In my case and going through the logs, I didn't see anything that jumped out and bit me but my research led me to believe that com.google.apps.tiktok.* was some sort of old transactional piece of Android. Also, I noticed my Tutorial activity was logging well after it should have been.
My suspicion is the test may actually be real and intended to check for either Activities handling external launches or checking for a security injection of some kind.
I think the use case is likely that an Android user is changed on the phone (usually at end of these robo tests), ticktok handles that and sends this intent/message to all externally known Activities. If so, that would mean either the Activities have to not be exported or handle the intent appropriately.
Anyhow, this change helped me tremendously and I haven't hit this with this app since after about 100 robo tests. Hope it helps someone else.
I think this is a problem with Google Play Store testing devices. Problems went away without me making any changes on a new release.
Related
I am relative new to Flutter.After playing around with adding ads to my app (emulator implementation so far - using firebase admod plugin - latest version), the console keeps spawning the following message
Attempt to remove non-JNI local reference, dumping thread
Firstly, I considered as a warning of something. However, the app's performance keeps decreasing and sometimes causing some services to fail.I made an apk build in order to test the behavior at a mobile, but still I haven't seen any ads in order to see any performance hiccups (newly subscribed to admob so it take some time to serve ads). When I remove completely all the code for the ads the performance comes back to its standards.
Another strange thing is that when I use the
adUnitId: BannerAd.testAdUnitId,
it gives me the same message 4-5 times and then stops. However, with real adUnitId keeps logging the same message over and over again.
I saw related subjects, but none of them referring to Flutter.
I would appreciate any advice. Probably, I do something wrong.
Thanks in advance.
A first-party plugin google_mobile_ads has been recently launched and the Flutter team recommends using this plugin going forward.
Our apps are live on the app store.
I wish to recognise crashes of out of memory that some users are getting.
I understand there is no way to 100% recognise an out of memory crash.
Is there any way to recognise these crashes(with a pretty large probability) by doing some logic in the applicationDidReceiveMemoryWarning? (I am not talking about finding it in xcode during development time, i am talking about code that will recognise the out of memory crash from actual users and will log something to file)
While I was looking for any service or library that give me OOM tracking, I could only find this article from Facebook engineering:
https://code.facebook.com/posts/1146930688654547/reducing-fooms-in-the-facebook-ios-app/
The idea is to deduce the reason why the app needs to be launch, checking different aspects (like if the app was at background, if there is an app/OS update,...).
Discarding all the other possible reason that can force the previous app exit, you can know if the reason is a background out of memory or a foreground out of memory.
It would be nice to have a library that implements the Facebook article procedure. But nowadays I couldn't find any, probably there is some reason that make this difficult or may be impossible to add it as an sdk.
If anyone knows any service, please share it with everyone with a comment or a new answer.
Edit:
I have discovered this github (https://github.com/jflinter/JRFMemoryNoodler) with an implementation of the Facebook post procedure. I haven't tried yet, but we will deploy it in our apps to try it.
Look out for the applicationWillTerminate message in your app delegate. This is called if you app is terminated by the system (due to e.g. low memory), but not if the user leaves the app in the usual way by pressing the home key. Note: if your app is in the background and memory runs out, your app gets killed without any messages being sent to it.
YMMV, especially with older versions of iOS, and it's worth researching to ensure that the above is accurate.
The images at this blog post are quite informative (although slightly dated).
For more info, see How to know whether app is terminated by user or iOS (after 10min background)
Firstly Analyse your application by clicking on the Product at the top menu bar of your Xcode and click on Analyse section it will show you the number of leaks on in the application and can take you to the place where leaks occurred. This is how you can find the memory leak and rectify it.
Secondly it above does not worked then see to the view controller where crash occurred and check whether you have left any object to release.
Hope this might help you to resolve your problem.
I have a question which seems like it should be a fairly common occurrence. I am trying to test code which only runs the first time an ios application is installed. While in principle this is very easy, I'm having trouble with it behaving properly the second time the app runs (note, this is not crash related).
I have been force running the app for a second time using the "Application does not run in background" flag in the plist, and then just hitting the home button. This works great, except i stop getting log data after the first run.
Does anyone know how to test for this situation in a way where you can continue seeing the log information after the app closes? For example, if there is a way to attach the xcode logger to the new process id? Or just another way to force an app reboot without losing the logging feature?
Thanks in advance!
Use the debugger menu:
Product>Attach To Process
(Results may vary with different versions of Xcode).
Also, you might need to insert a sleep at the very start of your launch to catch the very early log messages.
EDIT: If you're on a device then you can use the Device Organizer (cmd+shift+2) to watch all logs on a device.
I'm planning to release a new app in the future.
I have a custom logging function which logs some application data (not crashes) into a file (location manager state, app foreground-background transitions, main actions...). These logs helped me a lot to debug problems which were app-related, but not causing a crash. Until now these were in the documents directory (shared in iTunes) and the testers sent them to me after they saw some incorrect behaviors, however I don't want to share them anymore because this directory contains the app's database too.
I'd like to obtain these logs even when the app will be on App Store, but I don't know how this should be done. As I wrote, it is a new app and even after the test phase may exist minor bugs. I know that the users can report problems in iTunes or on the Dev site, but without a detailed scenario or log it is really hard to correct a bug. Should I make some kind of in-app bug report functionality (even if this creates a wrong user impression) ? How is this usually handled ?
Edit1 : I'd want these logs only if the user thinks something went wrong and should be analyzed, otherwise I don't really need them. I think some kind of user action is needed to confirm that something isn't working as intended, that's why I asked about making a functionality ( like the "Report a problem" in the Maps App ).
Thanks
If your app is gonna crash, don't submit it to AppStore because more likely it will be refused.
I don't know your app but usually logging slow down things. But if you really want logging I would suggest you to first find out if application crashed. For instance in your appDelegate when the app is terminated without problems set some NSUserDefaults value like closedSuccesfully=YES. Just after you start app set closedSuccesfully=NO, but if it was set to NO before it means your app crashed last time. In that case you could grab your previous logs and try to send them to your server via http post message. On your server there might be very simple php script to get that data. That way it will be automated and your users wouldn't have to do anything and you would get all crashes even these not reported.
If been looking around the web and can't seem to find any good solutions to sending allowing your user to submit bug reports from your iPhone app.
How do you handle crashes and exceptions?
Do you send the error user-data to a server,
grab a log file from somewhere and attach,
or do you ignore it and pretend it never happened?
Anybody got any experience with this?
Update
I am aware of how to prepare you software testing it with Static Analysis, Leak Detection, User Testing etc.
But errors might still happen when a user (mis)using my software. Always assume your user is trying to break your software.
What I want to figure out is how (I, or rather the app) can provide me with useful data when/if errors happen. As they do even in top quality products – like my own ofc. :)
I'm looking anyone that has experience with allowing the use to send error reports, stack traces, logs etc. to see how they handle the problem.
Some people use built-in analytics like Flurry which will post exception data to Flurry's website which you can review later.
Also, Apple has a "crash log" reporting area on iTunes Connect, but I'm not sure if it works since I've yet to see something come through and I kinda doubt each and every person has run my apps flawlessly. Not saying I write poor code (hopefully), but not every device is created equal either so I have to imagine it has crashed at least ONCE. There's always the option of logging and sending to a server later though.
Most of the time though, if you give users your e-mail address within the app itself (like on an instructions or about screen), they will e-mail me about any issues. That's a little bit nicer since it gives you a chance to correct the issue before they hit the review forms on iTunes.
You can also try BugSense. It's free, realtime, error reporting for iOS
PS: I am one of the founders.
Crashes most of the time comes with problems of memory management. To test memory leaks and find in your code on to what areas you were leaking a memory. Use the Instruments if your using XCode.
In your XCode go to Run -> Run with performance tool -> Leaks.
You can check everything here when it comes to memory allocations.
Note: To avoid crashes, make sure you released objects correctly and check your scheduled timers as well.
Regards,
ZaldzBugz