After discovering that the Google team upgraded the Android Developer API, I made a script to automatically update all my apps data in multiple languages at once.
However, I've noticed that, when you follow a workflow of:
Ask for Edit ID,
Do all your changes
Commit all your changes
At some point, you get a SocketTimeoutException when you try to update changes. Well, this may be due to a problem in my connection.
So, to solve that, I changed my workflow:
Ask for Edit ID,
Do one change
Commit one change
Repeat from 1 until changes finished
However, following this process, it ends with this when I try to commit after some changes:
{
"code" : 403,
"errors" : [ {
"domain" : "androidpublisher",
"message" : "Daily save quota exceeded.",
"reason" : "publishingDailySaveQuotaExceeded"
} ],
"message" : "Daily save quota exceeded."
}
Looks weird to me, as there is no explanation about save quotas for this API.
Also, after an intense use, the current quota limit keeps frozen at 0/200k, as if I didn't do anything. I didn't use the v1 of this API, so I don't know anything about this.
Do you know if that's the correct behavior?
Unfortunately it looks like their "recommendation" in their API's usage page is the rule.
Do not publish alpha or beta updates more frequently than once a day. (Production apps should be updated even less frequently than that.) Every update costs your users time and possibly money. If you update too frequently, users will start ignoring updates, or even uninstall the product.
Seems odd to me that they hard limit it like this though. It should be explicit at the very least.
Update
To follow up, I'm actually able to publish more than once a day as long as attempted uploads aren't rejected for some reason (such as 401 unauthorized). Haven't tested to see what the upper limit is, but it does make testing this a nuisance if it does heavily rate limit after one bad attempt.
The Google Play Developer API has a default limit of 200,000 queries per day.
For the purpose of enforcing this quota, the day ends at midnight Pacific time (UTC-8 when California is on standard time, UTC-7 when California is on daylight time).
https://developers.google.com/android-publisher/quotas
Related
We try to get an update into the play store for over a month now (34 days). But we‘re basically stuck in „processing update“.
We tried to contact the Google Play Console support, they can‘t help us, they keep telling us „it takes time“. We also tried to contact them via Twitter, their they either said „it takes time“ and once „you were rejected, check the email for details“.
We never got an email, so we have no clue what‘s going on, we asked them to send the email again, no response.
Is there any way to get in touch with the review team to get this sorted, we‘re getting mad with this problem.
So basically nothing really helped here besides waiting, after 36 days both updates got approved. End of story.
Unless you know someone at the review team you won't have any luck.
I'm trying to use the google api for auto-complete.
I created a key and did some testing, due to an error in my code, that sent many requests in a short time I had the error: OVER_QUERY_LIMIT
I made the correction of my code, deleted the used key and created a new one. Now I get the following message:
{
"error_message" : "The provided API key is expired.",
"predictions" : [],
"status" : "REQUEST_DENIED"
}
Does anyone have any idea how to solve it?
The Message you are getting seems to be very clear.
You could have a licence an this license seems to be exceeded.
Please read the documentation.
The clarity of the message is quite obvious.
The problem is that google warns you that you have a 100k limit available.
The detail is in: these 100k is only available when billing is activated, without activating billing the limit drops to 1.
I would never imagine that.
But it's settled!
The tip is for anyone to go through the same problem
I am trying to upload hosted content for in-app purchases, however I have been unable to succeed so far.
I have previously uploaded around 100 in-app purchases packages for my app using Application Loader. I used to be able to upload these packages before without any issues. Now I’ve noticed that the latest version of Application Loader (Version 3.0) doesn’t even give me the option to upload hosted content (see attached)?
So instead I’ve taken the time to use the iTMSTransporter bash script instead. However when I try to upload the content packs using:
iTMSTransporter -m upload
I am getting the following error:
Package Summary:
1 package(s) were not verified because they had problems:
/Users/Cortana/Documents/iOS/Clients/AccentKit/InAppContent/854413379.itmsp - Error Messages:
ERROR ITMS-90320: "The archive for In-App Purchase 'com.accentkit.AustraliaFemale1' is invalid. The 'IAPProductIdentifier' in the ContentInfo.plist must match the In-App Purchase Product ID."
[2018-04-14 07:12:45 MYT] DBG-X: Returning 1
I’ve double checked and the value for IAPProductIdentifier on the ContentInfo.plist matches exactly with what’s setup on the In-App Purchase Product ID on iTunesConnect. (see attached screenshots) This error is making no sense to me.
Any ideas?
If there was an issue with banking and your sales contract are according to you theoretically back in effect, they may not be effectively back in effect, that is, from Apple's servers point of view.
perhaps this is a process that takes up to a week and the only way to speed it up is to call their technical support.
this is where that'll happen : https://developer.apple.com/support/technical/
I suspect it's likely that your app having been on monetary lockdown at any one point while the bank was an issue may have led into this buggy situation that apple may not have accounted for or that they have accounted for and want you to first go through their IT support process in order for them to first be able to asses that everything is in order.
cheers! :)
I decided to try out Firebase hosting and wanted to start fresh so I deleted my one and only app, but when I tried to create a new app with the same name I was unable to due to the error:
"This Firebase URL is not available"
I can only guess this is because of caching of app names/URLs? Hopefully it will become available (unless someone else beats me to it) after some timeout? Any info from others who have experience with this issue or otherwise know the answer is appreciated!
Not sure whether this is the right place to ask although Firebase suggest coming to SO because they apparently monitor Firebase-related questions closely according to their website.
Thanks!
Once you delete a Firebase URL, it is permanently unavailable. It cannot be recovered.
During confirmation, you should see a message like this, which explains in detail:
This stems from a number of abuse vectors that are possible by misappropriating a project id that the prior owner believes is deleted and could still have apps/releases in the wild attached to the defunct backend. Since compliance requires that we purge all data related to the project, including information about ownership, there's not even a way to restore one you personally deleted.
Generally, I don't ask questions to stackoverflow because I always find an answer by searching. But today, we have a very important problem.
We have somes Drive API issues for a few hours.
A lot of 500 Internal Server Error when we want to take the ownership of a document.
We have tested directly with APIs Playground and it's the same :
https://developers.google.com/drive/v2/reference/permissions/insert
{
"role": "owner",
"type": "user",
"value": "blabla#example.com"
}
The big problem is the API return an error but the take ownership is OK. So Google return to us an error whereas the request is passed correctly...
Does it means we can't trust the API ?
We use Python for this application but we have the same issue for the same request in another application in Java...
Drive is having one of its bad hair weeks. They happen from time to time.
To answer "Does it means we can't trust the API ?", well trust is a bit subjective, but we have started to add defensive coding to our apps. So rather than assume the API is working to spec, we assume it isn't and do a double check.
Eg.after an insert we are now re-fetching the inserted file to confirm that it has been correctly inserted. We also track 304 rate limit errors on inserts because sometimes, despite the exception, the file was inserted. (similar to your observation, except you're seeing 500).