Problem: onRoomCreated returns STATUS_NETWORK_ERROR_NO_DATA 5% of the times, for no reason that we can figure out.
The game worked well for about 16 months of development (no problem of missing "permissions" in the manifest or the Google Play Console) but starting with Google Play Service 29 (that's "allegedly"... it could be unrelated), this unpredictable behaviour started, and it is blocking any further attempt to create a room (same wrong statusCode over again, even after restarting the game).
The only way to make it work again is either to restart the game after 10-15 minutes or to restart the device (usually works but not always).
The problem is the same on 3 different devices (no emulators here).
What we found about this problem (on SO and elsewhere) is that it could be related to NOT leaving the room (RealTimeMultiplayer.leave(...)) before trying to create a new one. So we are waiting AT LEAST the end of "onLeftRoom" (plus 3 sec, just in case) before trying to create a new room. To no avail.
Obviously we are following the recommended guidelines: instantiate GoogleApiClient in onCreate, .connect in onStart, .disconnect in onStop (even if .connect is on its way)...
Also notice that, because it's supposed to be a "NETWORK_ERROR", we are validating the Internet connection (with a ping) before each attempt to create a room.
Please, if you have ANY info about this issue, or if you know how to make Google Play create a room after this statusCode WITHOUT restarting the device, please let us know because until then our release date if forever postponed. Thanks a lot.
[UPDATE 2]: app was rewritten to stop making automated room creations (hence less frequent requests), and... nothing... still the same bug/problem/you-name-it ... over and over ... then Google Play updated the app "Google Play Games" (and maybe "services") and it kinda worked: only one STATUS_NETWORK_ERROR_NO_DATA in 2 weeks... now I'm going to sleep for 2 months because I'm [redacted].
[UPDATE]: according to this post, STATUS_NETWORK_ERROR_NO_DATA is used to limit the frequency of requests. Because we do automate room creations and closings this could be the definitive answer. I'll update once again when it's validated or not.
I leave the rest of this answer because, although it's not directly related, not closing rooms also induces errors.[END OF UPDATE]
Here's the answer to this unpredictable behavior (didn't come from SO but some of you might still be interested): in "onStart" and "onStop", all calls/requests to Google Play Services (with mGoogleApiClient or not) must be made BEFORE "super.onStart();" and "super.onStop();".
Otherwise what comes after "super.onStop();" will be interrupted before it's over (with some randomness added by device's speed and load), which means that any call to ".leave" an open room will fail, and then prevent the creation of a new room (hence the STATUS_NETWORK_ERROR_NO_DATA error).
Also notice that the variable mGoogleApiClient should not be declared as static, and remember to call "mGoogleApiClient.disconnect();" in "onStop" (the example "ButtonClicker" doesn't do that when it's recommended elsewhere).
Related
I am deploying my Nodejs sample app to Google App Engine Flexible env and when I am using google app engine URL which is in the form appspot.com to hit my API, it is taking around 11 secs to send response from my mobile data, but other APIs are sending response in milisecs.
Also, the time delay is only happening when I am opening my android app and sending request to the server after that all requests are taking normal time, and again delay is coming when I again open the app and send request to the server.
Edit - I found that
This can be a caused when your application is still booting up or warming up instances to serve the request and can be called as loading latency. To avoid such scenarios you can implement health check handler like readiness check so that your application will only receive traffic when its ready
That's why I checked in my Logs that readiness check is performed sometimes around 1 sec
and sometimes around 200 ms
Can anyone please tell me is there anything wrong in warming up my instances because I don't think cold boot time is causing this problem.
Edit 2
I have also tried to set min_num_instances: 2 so that once loaded atleast my 2 instances will again not get boot up, but the thing is delay is again same.
Edit 3
runtime: nodejs
#vm: true
env: flex
automatic_scaling:
min_num_instances: 2
max_num_instances: 3
Edit 4
I am noticing a strange behaviour that when I am using this app Packet Capture to capture traffic, then all https requests (if I am not enabling SSL Proxying) and all Http requests are executing in milisecs whereas without using this app all Http/Https requests are taking 11-16 secs of delay.
I don't know how but is there any certificate kind of issue here?
Edit 5
Below I have attached Network Profiler where delay is coming 15 secs
Please Help
Depends on which App Engine you are using and how you setup the scaling, there's always a loading time if you don't have a ready instance to serve a request. But if you have readiness check to ensure your instance is ready (and not cold started for the request), then there shouldn't be a problem.
Can you find a loading request or any corresponding slow request in your logs? If not, then it's likely an issue with the app. If possible, instead of calling this API on your app, do it from two apps (one is already open, one is not). So you make calls from both apps and if you notice that the one that's already open is getting a response faster than the other one, that means that's a problem with the app itself. App Engine can't determine whether or not your app is pre-opened so any difference would be client side.
=== Additional information ===
In the your logs, there's no delay at all. The request enter Google and was processed within a few milliseconds. I am sure there's something application-side. Maybe your app is constructing the request URL (first request) from some other source that results in the delay? App Engine has no knowledge of whether or not your app is opened or not or whether it's sending a first request after being opened, it cannot act differently based on it. As long as your App Engine instance is ready and available, it will treat your request the same way regardless of whether or not it's your first request after the app is opened.
The issue is resolved now, it was happening because of network service provider which is Bharti Airtel, their DNS lookup was taking the time to resolve the hostname. After explicitly using alternative DNS like Google 8.8.8.8 the issue got completely resolved. Maybe it's a compatibility issue of Airtel with Google Cloud.
Last time I checked I remember having to put a warmup request handler so that Google would know that the instance is up and running and can be used to answer calls. Keep in mind that code has to be EXACTLY under the endpoint you specify in the handler under the yaml file. (Wouldn't be the first time someone forgets that)
Here are the docs https://cloud.google.com/appengine/docs/standard/python/configuring-warmup-requests this is python specific, but you can also check other languages like Go, Java, and such in the docs.
If the problem is client dependant (each time a new clients spawns and makes a call it gets the latency) then it is most likely, either a problem with the client app itself or with initialization, registration or DNS resolution.
You could also try to reproduce the requests with CURL or similar, and see if also with those you see the mentioned delay.
For some strange reason, which I'm not entirely sure why, I'm getting not only an ANR for my application, but also of the entire systemui. It's so bad that I HAVE to reboot, and after rebooting it has to "Optimize" all of my apps like it corrupted something (anyone have an explanation as to why this happens?).
I'm assuming that parts of my code are so bad that they're causing this, but should even malicious code be able to overload the systemui? Anyway...
What I am doing is that I'm attempting to launch a service to handle screen recording. The activity (from a fragment) asks for permission (which is obtained, and I see the Screencast icon in the top right corner of the screen), then it binds a service which handles any state changes. What I mean by state changes is this...
States:
Dead - Means it needs to be initialized and prepared
Alive - Means it needs to be start and is fully initialized/prepared
Started - Means it is currently recording.
Paused - Means it will start a new video after starting again, which it will combine all temporary videos into one (haven't worked out that details yet).
Stopped - Means combine any and all files into one, then send the URI through an intent in a broadcast (haven't gotten this far yet).
It goes from Dead -> Alive -> Started <-> Paused -> Stopped -> Dead. At least that's the overall plan. I plan on having a floating button that acts as remote for controlling the service, and hence broadcasting on a receiver (local) to my fragment which is waiting for it to be finished.
Now, enough of what I intend to have, lets get into what I have right now. It's kind of a mess, I've never done this stuff before, hence why I'm asking on here. Trust me when I say that I have tried a lot of stuff, and the unfortunate bit is, the only way to test out a new solution is to reboot and wait 15 minutes while Android optimizes everything again. Now I understand it's a "Long" code-segment, but I'll say that one place it crashes is stopRecording(), at line 216.
Code here.
Let me know if I should make any changes.
Lastly: Should any of this be run on another thread? Could that be the issue? Why doesn't the app crash only instead of systemui?
I have having problems with a WSDL/SOAP service call in an app I have built in flash builder for mobile. I have connected to the service using flash builders built in data/services functionality.
For the most part, the service call works perfectly but once in a while it will cause the app to crash - on my android device it completely locks up (spinning animation stops) and then Android informs me that the app is not responding and asks if I want to close it.
The crash appears to occur quite frequently but not with any pattern. One time it happened on my third attempt, another time it took approximately 30, a couple of times I could not get it to happen and most times it occurs somewhere in between.
It appears that the crash happens after a service call is made but before any response is received. Neither the success or the fault listeners are ever fired. I am very confident that I am sending exactly the same variables to the service every time.
I have used web service calls in other apps without trouble so I have to assume there is something in this particular build that is causing problems but I can't seem to find anything.
Any thoughts on possible causes, things to test or even a solution would be hugely appreciated.
Thank you,
Jamie
Your question lacks essential details, so now I can suggest you to setup Charles proxy and monitor you requests trough it.
If you send too many requests simultaneously, you shall not be confident in fault/result events as air runtime has limitations (in any case, it is a good practice to handle request timeout).
I'm using google analytics for android with a dispatch interval (ie. tracker.startNewSession("xxxx", 10, this);). However, I noticed during development that the SDK kept printing something about the database being full and the last event not being stored in LogCat. So I decided to call the .dispatch() method manually after every API call figuring it would kill two birds with one stone:
Send events more often, which would in theory stop them from backing up and losing some events (as per the logcat entries I saw in development).
Save battery by sending any GA events while the mobile radio was active.
Once I released that, I noticed that my GA stats (pageviews, et al) were about 35% higher; which can only mean one of two things, either lots and lots of GA events were being lost before, or it's now doubling up on sending some events erroneously.
anyone have any thoughts on a good way to troubleshoot this? If it's now doing a better job of reporting mobile pageviews and visits, then this is great. But if it's not accurately tracking the data now because I'm manually calling .dispatch(), then that's bad and I should revert this change.
That's what I saw too when I increased the rate at which I manually called dispatch. Plus it does make sense : since they are storing data locally and batch-sending to the server, I wouldn't be surprised if some data got stuck for a few days. And since data is associated with the day it was sent and not generated you get skewed stats.
PS: Have you taken a look at the new example app then provide for the Android SDk ? They run everything in AsyncTask in order to improve dispatching and to not hit the Main thread with network access. I've further improved that by storing all events in a queue and running only one AsyncTask... need to put it on Github but haven't cleaned it up yet.
The EasyTracker sample app uses AsyntTask and network queues to improves performances.
As mentioned by bitbox this could improve battery life and have less lost tracks without have to manually dispatch.
You can download the jar and source of EasyTracker from https://code.google.com/p/analytics-api-samples/downloads/list
I've released my second game project on the Android Market this week, and immediately had multiple 1-star reports due to force closes. I tested it on many handsets and many emulators with zero issues. I'm completely at a loss for how to proceed and looking for advice.
I use Thread.setDefaultUncaughtExceptionHandler to intercept and report uncaught exceptions, then close gracefully. The people reporting force closes aren't getting to any of that, even though it is the first thing set in the application's main task constructor, and everything is wrapped in try/catches throughout. They are also reporting that there is no "Send Report" option in the force close popup (providing the Developer Console error reports), so I have absolutely no way of knowing what the problem is.
Uses Android 2.0, with android:minSdkVersion="5". Only Permission required is INTERNET.
(on Android market as 'Fortunes of War FREE' if you want to test)
I'm a bit surprised about the missing "Send report" button. What API level did you build the game with? I usually build the level with your minimum API level to make sure you're not using any API calls beyond that, but then switch back to the highest API level so you can use functionality like "install to SD".
I'm sure there's at least one user who wrote you a mail. Can you ask them to install LogCollector and mail you the log?
Btw, in general, I wouldn't use Thread.setDefaultUncaughtExceptionHandler so there IS the option to send a report. (It's ominously missing in your case, but normally, it should be there.)
Btw btw, the exception handler applies to the current thread. If you have an OpenGL app, maybe the crash happens in the GL thread?
I'm not sure if I understood you correctly, but as far as I know Android only shows that report dialog if you use its default UncaughtExceptionHandler.
Try this:
In your UncaughtExceptionHander's constructor, call Thread.getDefaultUncaughtExceptionHandler and save the returned object in a variable (let's call it defaultHandler). In your Handler's uncaughtException() do the things you want to do, and then call defaultHandler.uncaughtException() afterwards.
Maybe something you should know:
In my experience, your Context isn't functional anymore at uncaughtException(). So, you can't send broadcasts, etc anymore.
By the way, if you really wrapped everything in try/catch, that could be the reason why error reporting doesn't work as expected? :P
Good luck
Tom
Perhaps the force closes are caused by stalls, rather than exceptions. Users may not notice the difference. This kind of problem can occur more often if users have CPU hogging services running at the same time as your application, which explains why you're not seeing the issue in your testing.
Permission Internet sounds a lot like you try to transfer data from the net, which is very fast in your local LAN, but all of a sudden becomes slow (and time consuming) when people try this over their GSM connections.
If you then do the data transfer in the UI thread, this one is blocked and the system detects the block - but then this should end up in a "Did not respond" -- but then I've seen one user report an error with in the market on my app that was such a slow down cause.