Hello, sure… I did file an appeal where are describe in detail what happened and how we think this is wrong. So I guess I can just post it here to provide more details on this…
…I just feel I have to comment on the policy process which we just experienced recently otherwise I would be sending out a signal that this is just fine which it definitely isn’t…
I know we are the lucky guys here as we have resolved the issue “relatively” quickly (although we are not yet out of this). There are real horror stories on the internet from people less lucky. But this is just another reason to say that the current policy enforcement process is simply broken.
All my text below is based on the assumption that we know what was the problem, but we are just guessing as we did not get feedback on what was wrong and we will not get it: Most probably, the problem was the use of interstitialAd.show() in the interstitialAd.onAdLoaded() block IMHO.
This meant that in some very rare cases (as we preloaded the Ad at the start of the alarm screen this case would be very rare), the interstitial Ad could have shown up just after the user closed our app.
The following is based on that assumption.
-
The process can remove your app even if you are not violating any policy
After day 1 of the removal we did immediately publish a compliant version with ads completely turned off - we cannot violate any Ad-related policy if we are not serving any Ads. But this did not make the bot happy. So even not violating the policy the process kept removing the app for the next 3 days which was completely unnecessary, counterproductive and caused additional damage.
-
The problem can be anywhere in your code and you may easily get to a point with no chance to discover it
Our app is on the Play Store since 2010, it has over 300 thousand lines of code. The problem may be anywhere, not just in the latest release! The code may have even originated long before the policy was even in action. So in our case it was in a code we have published to the Play Store in 2015 (nearly 4 years ago). The policy formulations are so vague that you can easily get to situation where you will not find the the cause at all. We were just before starting to randomly turn off different features in the app just to narrow the issue down. This would have been a disaster.
-
The process can force you to shrink your user audience just to become policy compliant
Finally to fully resolve the issue we had to stop serving some of our older APKs. The reason - you cannot even build from such an old code base - because of build tools incompatibility. Even when you would do massive changes and build the old version, you cannot publish it to the Play Store due to the recent minTargetSDK enforcement. The only way is to deactivate such APKs.
In our case we did remove support for around 1000 old devices - not a big deal, right? But I can easily imagine a situation where you need to sacrifice let say 20% of your audience just to be able to comply with the policies. Especially as the minTagetSDK requirement is increasing now year after year.
PROPOSED SOLUTION
IMHO the only way to fix the policy enforcement process is to provide more feedback to developers. Ideally give them the exact line of code which triggered the rule. I can just assume Google does not want to do it to make it harder for real abusers to work around the rules. But real abusers will always find their way around such primitive code analysis checks. They can always obfuscate the code so the bot does not trigger the rule.
This is a typical example of bad rule enforcement mechanism which does not prevent the minority of bad things from happening, but punishes the majority of honest developers whose aim is just to provide the best services they can to their users.
Believe it or not waiting every day sleep deprived for the time the app gets removed again, trying to think like a Google bot to narrow down the problem which you have no details about - this is not policy enforcement - this is pure punishment!