My Google Marketplace app, a spreadsheets script, has been available in production and running for years now. It has been installed thousands of times. This past week the app was suddenly delisted which immediately broke it for hundreds of users. In the Marketplace SDK screen it says it was "Rejected", but I see no way to find the reason for the rejection.
Earlier in the last several months I got notice that the app would be removed if I didn't add a Privacy policy link, supposedly a new Marketplace requirement. I added the link a week before the required date and it was visible in the public Marketplace listing. I'm not sure how to tell if the contents of the privacy policy were unacceptable or if an automated system didn't recheck the updated privacy policy link status of the entry.
I don't have paid support because this is a free app that I publish on my own free time. I don't see a way to escalate this or to understand why an app was rejected suddenly after multiple years.
Related
I have an app on the "Internal Testing" track with a couple of friends as registered testers. They could all install it, no issues here. But they don't get updates automatically when I publish a new version on this track. The only way to install new updates is to uninstall the app and install it again via the invite link.
First thing I learned about this is that Google will not enable auto updates on Internal Testing if they haven't done at least one review of the app (although the track itself doesn't get reviewed). So you have to submit one version on the "Closed Testing" track in order to get it reviewed. I did this and it got accepted but still no updates on "Internal Testing".
Since I got reviewed on "Closed Testing" I published several new versions on "Internal Testing" but none got pushed to my users. They don't even see the update if they actively search for updates in the Play Store app.
I didn't find much explicit information about what to expect from the "Internal Testing" track wrt. updates, but this post says that it should be deployed automatically if the user has set their device to auto-update apps:
If your users have their device set to auto update apps, it will just update to the newest release when the device recognizes a release is available. (source)
What am I doing wrong here?
If this is not possible with "Internal Testing": what would be the right method to give a limited number of test user access to the app with auto-updates enabled?
Thanks in advance!
Edit: I found one way to update the app: if I long-tap the App icon and tap the (i) icon (this might be Samsung specific), I end up in the Play Store listing which shows an update button. The auto-updates are enabled btw, so it should have been installed automatically.
What I found is that testers list should be exclusive for different testing tracks. In other words, a tester should not have the same Android device trying to access internal testing track releases and open / closed testing track releases.
Did not find any official documentation from PlayStore on this, but learnt it the hard way.
Maybe this post is still helpful for you: https://medium.com/#tukai.anirban/internal-testing-in-google-playstore-47de955062ad
I have an application on play store to whom the targetSdkVersion is update to 30 from 29, which is getting rejected again and again by Google Play after an update.
Previously, there was a permission of MANAGE_EXTERNAL_STORAGE in one of the SDK Manifest.
After removing MANAGE_EXTERNAL_STORAGE permission and storage permission (WRITE_EXTERNAL_STORAGE) completely from my app, uploading the app on store, app update gets rejected again.
This is the email received from Google Play for the rejection reason.
Note: I am saving all my media files in app-specific internal storage.
Also, I have the permission of READ_EXTERNAL_STORAGE in my SDK as we have chat feature in our app to get images and videos of device to sent it.
According to Use of All files access (MANAGE_EXTERNAL_STORAGE) permission READ_EXTERNAL_STORAGE permission has not impact.
Attached reference.
Update
I also removed READ_EXTERNAL_STORAGE permission from the app, but still got the rejection with same reason from Google Play.
Is the issue with Storage Policy, or something else?
I had the same error for a month but finally, Google Play Store accepted my uploads.
Briefly, what I did was to create new builds for each track, and -interestingly- it worked!
(Before my countless update trials, our latest version on Production was 2.23.5 (build 1), our active tracks were Internal Testing Track and Production, and I was trying to upload my updates to Internal Testing Track.)
Below are the steps that I've applied:
Created a new build 2.24.1 (build 1) with all necessary changes. (e.g. upgrading targetSdkVersion to 30, removing MANAGE_EXTERNAL_STORAGE permission, etc.)
Activated our inactive tracks (Open, Closed Alpha, and Beta Testing Tracks), uploaded the same build 2.24.1 (build 1) to these tracks, and then paused those tracks. (I've paused them as I won't use them actively, you may not want to pause it)
Created another build 2.24.1 (build 2) which was completely the same as build 1. I've just updated its build number.
Uploaded 2.24.1 (build 2) to the Internal Testing Track.
Created another build 2.24.1 (build 3) which was completely the same as build 3. I've just updated its build number.
Uploaded 2.24.1 (build 3) to the Production Track.
Went to "Publishing Overview" page, activated Managed Publishing in order to manually publish my uploads to Production and other tracks as they got accepted.
Sent these uploads to review at once and voila, Google accepts your uploads!
Sarcasm on.
Hereby, I would like to congratulate Google Play Support as they've shared all these details within their documentation, within their rejection e-mails, and within their super fast response to the appeal.
Sarcasm off.
I've found this solution referencing from this answer https://stackoverflow.com/a/69933431/2833718. I couldn't find any help from Google's official docs. They've always rejected my uploads with the same e-mail which is impossible to decode for a human being. They've never returned to my appeal.
This migration and support process was completely a failure.
Thank you Google Play Support, you are everything but support to developers.
My Android rejected build is approved finally after 3 weeks of headache.
Basically, Google was checking old APK, if it is available in any of the track (Internal, Open, Closed or Production) with Policy Violation.
So, in this regard you have to roll out the app to 100% in the track which has this Policy violation. Which will deactivate the old build.
I wasn't rolling out the new app to 100%.
Thanks to Google Policy Team.
I Found a solution for my issue .
Actually there was another channel in google play "Internal Testing channel" That has a build with permissions . You need to remove/Update any builds inside any channels to be empty from any Sensitive/ Highly risk permission.
One method for solve your problem, is start one new app. But when you for config your app, put disable the iten that say about file sms and file critical.
Resume, your app is been reject because the uour pre config. And not by your code.
The app was build and it was on internal test mode for about 1 month after it was reviewed. I created a production release skipping the alpha and beta test because it was ready to be launch.
After the production release was created, I saw a message saying that the app is being reviewed on the dashboard on Google Play Console. After it was reviewed, it was published but it was label as Internal Beta and I can't find it on the Play Store while searching or it. The version of the app is the old one on the Internal Test. There is no information about what is the problem and how to get the app to publish.
Try to access directly - https://play.google.com/store/apps/details?id=YOURPACKAGENAME
If you are able to access the right version - Great. It's not appearing in search, my be you need to work on marketing.
If you are able to access old version - wait for some time, it's being updated. Sometimes it may take upto 7 days.
If you are unable to access, your app is removed. You should appeal to Google.
I have a client who forgot to pay for their enterprise account and therefore their apps stopped working, as expected.
However, one would think that it should be sufficient to just start paying again to be able to use the apps as before. But as it seems, all certificates in the apple developer portal are now deleted?!
Is this expected behaviour or will they show up after some time again?
As it is now, we will have to rebuild all apps again with new distribution certificates. Is this the solution?
Short answer to your question:
I wouldn't expect the certs to automatically reappear. I recommend opening a support incident with Apple. Since the account was recently renewed, you should have two incidents available.
There's this section of the App Distribution Guide which talks about re-creating deleted certificates but I'm guessing it's more geared toward iTunes distributed apps and circumstances where certificates (private keys) are deleted but not revoked at Apple's CA.
Instead of recompiling your apps, you might be able to instead push out updated Provisioning Profiles and Certs. See below for more details.
Additional info:
It makes sense that Apple would revoke Enterprise certs upon membership expiration since that's the only way they could force apps to stop working. Since Enterprise apps stop working when either the Provisioning Profile or the Certificate expire, Appple can't push out an expired Provisioning Profile, and there's no in-app check for a Profile either (which is why if you delete your Profile in the developer portal, it won't affect any already downloaded/installed apps), which leaves the only other option: revoke the certs. The affected apps stop working once they sync with Apple's CA. Devices without connectivity will continue working until the Profile expires.
It may be possible to remove your certs from the Certificate Revocation List (CRL) but Apple support would be your only likely resource to help with this.
If you're out of options for re-enabling your old certs, you can update the Provisioning Profiles (and I think Certs) and push that out without recompiling all your apps. Also, if you use wildcard App IDs, an update to one app Provisioning Profile will apply to all installed apps that share that App ID.
If your users' devices are managed via MDM, it's possible to push updated provisioning profiles via MDM, and according to this post, via Device Enrollment Program (DEP). I thought I read a while back that you could also update provisioning profiles from a desktop/laptop to a connected device using iTunes - not sure where that is now. I don't know if it's possible to direct users to a link to update the Profile OTA like they would install an app.
I hope this helps in some way. Please let us know what happens - I fear the same could happen to me, whether a cert is deleted by Apple or a haphazard developer.
As a developer of an app it could be quite a turn off if half of your users cannot open your app because they get following error.
[i know there is a workaround by going to sys preferences->security-> allow apps from "anywhere" but users of our apps are kids, they may not be in the best position to know how to do that]
What things I need to take care of in oder to avoid this warning, or to get apple developer identity?
This app has been published on App Store, so all the provisioning profiles and certificates are there. Now we want to put the app on our website, but before doing that we want to eliminate this gatekeeper hurdle.
In the screenshot above you can see that the right developer is selected while archiving.
The signing identity used for App Store submissions and for independent publishing are different. The latter requires a Developer ID identity be used. See Distributing Applications Outside the Mac App Store for more information about the process.