Coinciding with Google's latest release during Google I/O the other day, I'm finding Google Assistant intermittently hangs with the 3 dots typing animation forever, even after it receives what appears to be an error-free, fast response from my bot.
Usually, when I repeat the utterance, GA gets out of its funk and responds, but not always. It happens both in the simulator and from my Android phone, but more often from outside the simulator.
This never happened before a day ago. Has anyone else noticed this? Is this a known problem? My bot hasn't changed significantly to warrant this kind of erratic behavior at a GA-level. Normally, GA should timeout, not hang showing animation dots.
I have been using Actions SDK V1 on Node, not sure yet if that has something to do with this problem, and should probably migrate to the new SDK.
I went ahead and migrated my Action to the new Action SDK V2 for Node today and so far I've seen no hang behavior yet after a few hours of testing. It appears as though Google's backward compatibility may not be all there.
Related
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.
It is well known that Chrome intentionally throttles javascript setTimeout calls for background tabs to a minimum of 1 second, however very recently (Chrome 75 on MacOS 10.13), I have found that my Chrome App is still throttled after returning to the foreground and remains throttled until I close and reopen it, after which setTimeout works as expected.
This does not happen unless the app has previously been in the background or unused for a considerable period of time (e.g. hours). My issue is that returning it to the foreground (i.e. interacting with it) does not speed up its behaviour and I would rather not require my users to close and reopen it.
I have read in other questions on this topic that continually playing audio is a work around. Please can someone point me in the direction of an example of how this can be done natively in a Chrome App i.e. without adding too much bloat.
I'm testing a turn based game between two devices. As far as I understand, sending a turn with [GKTurnBasedMatch endTurnWithNextParticipants:], for example, should automatically push a game center notification to the opponent. Sometimes, this works just as expected: the turn is sent and right away a banner notification shows up on the other device. All is well.
What is baffling me is that other times, even though the turn itself is sent properly (I can tell because when the opponent refreshes the matches, the match is up-to-date), there's no push notification coming in.
Are there any holes in my understanding here? If I'm understanding correctly, the inconsistent notifications shouldn't have anything to do with my code, because the issue here isn't how I handle notifications, it's that there is no notification at all. In other words, [handleTurnEventForMatch:] (aGKTurnBasedEventHandlerDelegate method) doesn't have anything to do with it (I don't think) because if no notification is being received, it's never going to be called anyway.
So, I'm just wondering if anyone has had any experience with this. Is it possible that this is due to something in my code? Or, is it possible that the Game Center sandbox is responsible for the inconsistencies, and there's nothing I can do about it?
Any thoughts or ideas would be much appreciated.
It is an issue with GameCenter's sandbox mode. In order for your device to enter sandbox mode you have to open/run your app and authenticate game center. If you say, open a different (published) game after your game is open it will leave sandbox mode and and go back to regular game center mode.
Even if your game is running in the background, as long as it is the last game-center enabled game opened you should get the push notifications as normal. But if you open the game, and then kill the process, you will no longer be in sandbox mode and will not receive the push notifications.
For those who are experiencing similar problems: this turned out to be a Game Center sandbox problem. It had nothing to do with my code, and things were fine in the App Store release. So, read through the comments here and make sure there aren't other things factoring into whatever issues you're having...but know that it's possible that you're simply experiencing some Game Center sandbox issues that are out of your control!
I am also facing the same problem. My game stops receiving turn events and turn notifications from Game Center, I finished my game and was testing, but this week, the problem started to happen. It was working like a charm but suddenly instances started not to receiving turn events for a couple of days.
I am using the iOS7 SDK and targeting iOS7 (turn event handling is different than prior iOS versions, I will need exchanges in upcoming game features, that's why I am using iOS7).
Then I made a test app to check if it was same with iOS6 and prior SDKs, but no help, it was same. So don't waste your time to upgrade your code to iOS7 hoping it would work, the problem is there. I also tried many things, like resetting devices and settings, using new users, etc.
I also tried it with Ray Wenderlich's Turn-Based Gaming with iOS 5 tutorial, by downloading source code, and it doesn't work neither.
The thing is, usually when I launch the game, game receives turn events, but after a few turns, it just stops, and when it stops receiving, stops like forever. If I reload the match, I can get the updated match and it's data is also updated, so I can make the turn. It means match is updated on Game Center. So, either Game Center is not pushing the data to users (possibly this is happening because user cannot receive notifications from Game Center when the game is in background), or the GameKit is not firing the event to the handler.
I don't know why it is happening, or why it started to happen, but I can't release my game like this, hoping that it would work out of sandbox. I will be trying a couple of more things (like maybe trying turn reminders of iOS7, to see if they push it to the user), then I will ask to Apple's support team. One other thing i am planning to do is, putting my test app to App Store and see it if works out of sandbox.
Hopefully it is a sandbox problem.
We currently have an iphone app in the app store. We release version updates periodically, about once every other month or so, sometimes more often. Most of the times, the updates are not large, just added bits of functionality, bug fixes, etc. Sometimes however, there may be major changes (so far it had happened once, about a year ago and it's about to happen again).
When major changes do happen, ideally, I'd like to get the users to update to the latest version. I know that there's no way to automatically install the update. As the app communicates with a web service to receive its data, I can use that service to check for the latest version and, if it's not the latest one, I can alert the user that a newer version is available and prompt to update. If the user chooses not to update, I have to options: (1) let them continue running the older version, or (2) effectively force the user to update by blocking the app functionality if it's not the latest version.
As the app requires back-end web-service, usually for major app updates the back-end needs changing. Sometimes these changes render the back-end incompatible with the previous version of the app. The previous time this happened, I had to set up a separate back-end for the new version (I now have to two web apps running on the server: for v.1 of the app and for v.2). While theoretically I can continue doing the same - setting up v.3 and so on, I would much rather prefer not to and force the update on the user.
Now, technically it's quite easy to set up. However what is Apple's view on such behaviour? Could they reject an update because of this? Any experience on this front? Thanks in advance.
It depends on the time frame of your transitions. We have a customer who exactly required the behavior you describe. We can send the client application two signals: should-update and must-update. When the client receives must-update, it will no longer allow the user to run. We have transition periods and tag the breaking changes, so maybe the active backends right now are e.g. V6, V7 & V8. We give users enough time to transition.
The Chase bank app forces you to update when an update is available (or else you can't log in). I think it's pretty annoying from the user's perspective, but Apple has certainly approved updates that do exactly what you're describing.
Currently I'm testing an app that I've written with ios 4. I've spent a good bit of time looking for memory leaks and that side of things seems o.k.
I have a problem where the app seems to "randomly" quit after going from one view to another. Sometimes this will happen after a minute or 2 and sometimes it won't happen at all. Because of this it's really very difficult to determine where the flaw in my application is and under what circumstances because my observations of whats going on is subjective. Also it can get very annoying very quickly sitting there hitting buttons until something happens and then trying to remember the sequence of your actions.
What would be a good method to hunt down the cause of this seemingly randomly occurring problem?
For example,
I remember speaking with QA engineer before and he spoke of tools that he used to automate a user using an application. He'd leave it running over night and then in the morning he could examine what combination of user actions and under what circumstances a problem occurred.
Are there such tools available for testing iphone applications? Ideally what I'd like to see is a report of
action a
action b
action c
= everything ok.
action a
action c
action b
= there was a problem.
There's also fonemonkey: http://www.gorillalogic.com/fonemonkey
As for random crashes... I am tester, not developer, and random crashes are usually one of the topics I examine more thoroughly on every iphone app. My favorite scenarios are: leave the phone for 2 min, for 10 min, and switch apps (on iOS 4). In all cases it's better to use a real phone (and the older the better), not a simulator (some crashes never happen on simulator). Commonly nested views are affected (e.g. get to some view, let phone sleep, click "Back" button to return to previous view - crash). Usually developers say that incorrect retain / release, autorelease while another object holds pointer, and other memory issues are to blame. Also Device Logs (which will have crash report) usually can pinpoint problem pretty accurately.
Hey.
Instruments by Apple. Apple reference.
Instruments has its limitations and drawbacks, but just try it. It may be confusing at the begging so try to follow tutorial, or some other.
Check out running the app with zombies enabled. Also, instruments in Xcode is very helpful.