Android as an OS has been around for over a decade now and compared to iOS, it does offer a lot more freedom. However, Google maintains dominance over app distribution on the Android platform. Even if Android is open to third-party app stores and sideloading, we can’t trivialize Google’s hold over the smartphone ecosystem built up over many years. This hold is the result of millions of app developers contributing meaningful app experiences to the platform over its existence, giving users a reason to use a smartphone with Android. Google and app developers have a symbiotic relationship, but it’s not one where the power dynamics are equal. Time and time again, we’ve seen complaints from long-standing developers whose apps were punted from the ecosystem, with the explanation for such removals found in vague or automated emails from Google.
Case in point: DroidScript
David Hurren, the founder of DroidScript.org, reached out to tell us about his recent experience dealing with Google Play’s developer support. For those unaware, DroidScript is an app that serves as a mobile IDE, allowing novice developers to create Android apps directly on their phone. The app is designed to make Android programming more accessible to beginners and non-professionals or to those coming from a Web development environment as DroidScript revolves around JavaScript use. While the app does look dated, it had around 1.5 million downloads over 7 years with ~105,000 active users, according to the developer. For an app made by a small, not-for-profit organization, those are good numbers.
Screenshots from DroidScript’s now-removed Play Store listing.
According to David, Google Play recently removed the DroidScript app from the Play Store on suspicion of committing ad fraud. Ad fraud is a serious matter, so a removal would be valid if that is indeed what happened. David denies any such thing occurred, which means of course he was going to appeal the decision. The problem, as usual, is that appealing a decision to Google can lead to an incredibly frustrating experience.
As David presents it, Google first disabled their AdMob account for “Invalid Traffic”, and upon appeal, further suspended the account for Ad Fraud. The appeal response came within 11 minutes and read as if it was automated. What makes matters murky is the lack of transparency that Google maintains regarding these matters. The developer insists that they only have a single banner ad in their app and had been using AdMob without issues for about a year when they received this notice and ban out of the blue.
To make matters worse, a week later, when the developer was working on removing AdMob from the app, they received a suspension email from Google Play for their app DroidScript. This email had some more details, like “APK:206 Ad Fraud. App violates Ad Fraud policy.”, but that is about it as far as transparency goes. Upon appeal, Google added “Malware” as a reason too, after taking 12 days to respond to the appeal:
During review, we found that your app violates the Malware policy. We don’t allow apps with any code that could put a user, a user’s data, or a device at risk. If your app was developed by a third party, we recommend contacting them to verify that they designed your app to comply with our policies. You can read through the Malware policy page for more details and examples of common violations.
Your app is not compliant with the Ad Fraud policy. Ad fraud is strictly prohibited. Ad interactions generated for the purpose of tricking an ad network into believing traffic is from authentic user interest is ad fraud, which is a form of invalid traffic. Ads should not be shown in a way that results in inadvertent clicks. Forcing a user to click an ad or submit personal information for advertising purposes before they can fully use an app is prohibited. Ads should not appear after the user has exited the app, or after the user has pressed the back button to exit the app.
The “Ad Fraud” policy mentioned in this email is a direct copy-paste from this Google support page, and it gives the developer no information on exactly which part of the policy their app violates. The “Malware” policy doesn’t seem to be a direct copy-paste but reads as boilerplate text that doesn’t describe what exactly about the app is malicious. Further emails generated more boilerplate responses and no useful information.
DroidScript remains suspended from the Google Play Store, for reasons not entirely clear. The developer’s account and other applications remain visible, including a few plugins for the main DroidScript app. Since the app is no longer published on Google Play, premium subscribers are having their subscriptions automatically canceled. That, coupled with the loss of 30% of revenue due to the AdMob suspension, is crippling the team behind the app, says David.
The suspension is also affecting projects dependent on DroidScript. One user responding to the announcement from the DroidScript developer says their apps developed in the IDE are still up on the Play Store, while another worries about the removal’s effect on their ongoing commercial development project.
What Google did (and continues to do) wrong
The issue with this incident isn’t that a long-standing app was booted off the Play Store. This is not the first time it has happened to someone, and it certainly won’t be the last time either. The issue here is Google’s reluctance to share details of how developers allegedly violate their policies. There are good reasons why Google can’t delve too deeply into what triggered their ad fraud detection — you don’t want to give malicious actors insight into Google’s detection algorithms so they can work around them — but for developers who are genuinely unaware of why their app was removed, they’ll face difficulties fixing the problem.
In response to complaint after complaint about a lack of transparency in app takedowns, Google issued a Play Policy Update in July 2020 seeking to address the matter.
Under the new policy, Google promised to be more transparent about the actual policy violation that resulted in an application being terminated. Developers were promised to be provided more details, such as a text excerpt from the Play Store listing or even a screenshot of the alleged violation. Google had also promised to add guidance to correct the issue. The overall idea was to make the violation clearer and a fix accessible, which would be very helpful for developers trying to navigate the complex jargon of Policy documents. Not all violations are intentional and malicious, and developers who are innocent are likely to fix such unintentional violations when they are helpfully pointed in the right direction.
We don’t know for sure if DroidScript and its developer are free of fault. It’s possible that the developer is indeed guilty of what Google has accused them of. We have no way of determining whether or not ad fraud occurred, and while we haven’t done a full teardown of the app, a quick analysis on VirusTotal and MetaDefender shows no obvious signs of malware. We don’t know Google’s side of the story here, but that’s kind of the problem. (We have reached out to Google for comment and will update this article if we hear back.)
What is ultimately disappointing is the fact that Google is still following practices that it had recognized were detrimental to developer interest. Google had promised to update its procedures to make them more developer-friendly, but they are still removing apps with as little transparency as before. To be clear, there is overlap between AdMob and Google Play suspensions, and better reasoning should have emanated from the Google Play side. But knowing the tight integration within its own ecosystem that Google pushes for, it should have been willing to offer some more helpful words and an opportunity to remedy violations, if any. Because it sure would hurt to see 7 years of progress wiped out by a few emails that look like they weren’t written by humans.
The post Google still struggles with transparency over Play Store app removals appeared first on xda-developers.
from xda-developers https://ift.tt/330xuoU
via IFTTT
No comments:
Post a Comment