Google Kills Ads... - General Monetization

“The ad market has been a gray area, and some ad networks became very spammy,” Rob Weber, the cofounder of native ad network NativeX. “Up to this point Google didn’t take a stand, but now they’re really stepping it up.”
Google made two critical changes to its Google Play Developer Policies in late August, giving developers 30 days to update their apps, or else. The first is that ads within notifications are now banned, and the second is that adding an ad-focused new icon an Android user’s home screen is also banned.
android-kindle-fireFor both of these, it wouldn’t necessarily be clear to users which app was causing the spammy alerts, or how they could easily remove them.
In the early days of Android, Google didn’t make a big fuss over these clearly annoying practices, perhaps partly because developers were having a difficult time monetizing on Android. Now, however, the Android user experience is catching up to Apple’s at the same time that Android monetization is making big strides — and Apple never allowed these kinds of ads.
In the process, however, Google will be sucking as much as $150 million of developer revenue out of the ecosystem.
“Tens of thousands of Google Play apps were using Airpush [one of the ad networks that promoted spammy ads like these],” Weber says. “They had over $150M in revenue, and we think 50-80 percent of their revenue was from this … and that’s just one of the networks.”
That’s revenue that developers who want to continue to monetize will have to replace, and NativeX is happy to oblige with native ads, as are other ad networks. But developers will have to hurry — this week is the first week of the new Google Play guidelines, and non-compliant apps risk being booted from the most important Android app store. After all, it wouldn’t be difficult for Google to track which apps have these types of ads and demand that they be removed — or else.
It may be tough for some developers initially, but ultimately, it’s all good for users, and it’s all good for Android. A better user experience will lead to more usage, and more apps, and more trust.
“This is an awesome move by Google, and will clean up all this mobile spam,” Weber says. “

Related

[Q] Why this objection to ad revenue?

Hello,
I've been reading a few threads and posts about earning revenue from apps without the use of advertising. I've used Admob network before, but over the past month and a half I've used Sellaring ad network. These guys do audio ads and they add a few good dollars to my pocket each month. In fact, a few more months of incoming ad revenue (and more users to my apps) and I may be able to cut down my day job.
I want to ask here, why is there a great objection to advertising on apps? I see a lot of the opposition here among XDA forum members and much less of it on any other forum. Ad revenue is a potential that can give developers the resource to develop more... this is what many of us want isn't it?
Hope I'm not offending anyone, would appreciate your input.
I don't think anyone here objects to in-app adds. There are many apps with both ad-supported and paid ad-free versions, so people will either buy them or use the ad-supported free version. Those kind of ads don't really bother people. I think the biggest problem people have with ads is with ad-delivery systems like AirPush. Those are intrusive and ruin the experience of using the phone. Coming from the internet, it doesn't feel right to get ads pushed to your notification bar automatically. It's like pop-up windows on many sites on the internet (eg. www.piratebay.se). Nobody likes them.
Since phones are our personal devices and we store so much of personal data on them, it doesn't feel right when we randomly receive ads like that without any control over it (except a convoluted opt-out process). It's an intrusion of privacy. That's the only issue in my opinion.
Please use the Q&A Forum for questions &
Read the Forum Rules Ref Posting
Moving to Q&A
But do you find banner ads less annoying when you're playing a game? Where do you draw the line between intrusive and non intrusive?
Ad networks like airpush and sellaring make it possible for app developers to make money from their entire installed base... even users who don't use the app every day. For me, that helps to generate a lot more cash.
I don't mind the little in app banner ads. The push notification ads are really annoying, and feels like malicious adware. I will instantly uninstall any app that pushed notification ads.
spunker88 said:
I don't mind the little in app banner ads. The push notification ads are really annoying, and feels like malicious adware. I will instantly uninstall any app that pushed notification ads.
Click to expand...
Click to collapse
Exactly. I uninstall anything that pushes notification bar ads as for me they feel intrusive whereas in app ads I have no problems with.
Dave
Sent from my LG P920 using Tapatalk
What do you think of this? http://www.bangstyle.com/2012/03/google-phone-ads/
Looks like Google is making steps in the same direction.
Rob45 said:
What do you think of this? http://www.bangstyle.com/2012/03/google-phone-ads/
Looks like Google is making steps in the same direction.
Click to expand...
Click to collapse
I think that's a stupid idea, but meh, if it makes money it can't be that bad. It better be optional though!
Sent from my GT-I9100 using XDA
Rob45 said:
But do you find banner ads less annoying when you're playing a game? Where do you draw the line between intrusive and non intrusive?
Ad networks like airpush and sellaring make it possible for app developers to make money from their entire installed base... even users who don't use the app every day. For me, that helps to generate a lot more cash.
Click to expand...
Click to collapse
It's likely your app's users do not know where the ads are coming from. I know if I downloaded an app that caused constant advertising to appear on my phone, I would remove it immediately and never deal with that developer again. You have to also look at it from a value proposition. If you are not providing a user with value (i.e. they are not currently using your app), why should they be providing you with value via ad revenue? And imagine if every developer had separate, out-of-app ads. Your phone would be unusable.
Rob45 said:
What do you think of this? http://www.bangstyle.com/2012/03/google-phone-ads/
Looks like Google is making steps in the same direction.
Click to expand...
Click to collapse
As long as it doesn't get as bad as the Google ads in this satire video from the Onion:
http://www.youtube.com/watch?v=Xtuxax8Dtk4
spunker88 said:
As long as it doesn't get as bad as the Google ads in this satire video from the Onion:
http://www.youtube.com/watch?v=Xtuxax8Dtk4
Click to expand...
Click to collapse
LMFAO the Yphone! Couldn't stop laughing!
Sent from my GT-I9100 using XDA
spunker88 said:
As long as it doesn't get as bad as the Google ads in this satire video from the Onion:
http://www.youtube.com/watch?v=Xtuxax8Dtk4
Click to expand...
Click to collapse
That's hysterical!! But only cause it takes it to extreme...
Ring back ads are meant to be played during the Ring Back Tone.
nemosomen said:
It's likely your app's users do not know where the ads are coming from. I know if I downloaded an app that caused constant advertising to appear on my phone, I would remove it immediately and never deal with that developer again. You have to also look at it from a value proposition. If you are not providing a user with value (i.e. they are not currently using your app), why should they be providing you with value via ad revenue? And imagine if every developer had separate, out-of-app ads. Your phone would be unusable.
Click to expand...
Click to collapse
I agree that you have to provide value to users. But considering most Android users don't pay for apps (statistically) and in-app ads do not convert very well, we're pretty much stuck in between. How can we generate revenue for our work?
What if the ads are fun jingles? Doesn't that provide something of value?
Labor isn't free and ads are just one way to monetize. The only question that matters is one related to the Golden Rule.
Would you use an app with ads? Does it bother you? If not, you are doing nothing wrong under the eyes of Bob. If users were to complain and bicker, then perhaps you have another question on your hands: to cater to the users or not.
Thankfully, my phone is rooted and running cyanogenmod, so I can block in-app ads as well as revoke permissions for others that use Air push. I realize that ads are how developers make money and keep the apps free, but that doesn't make me hate ads any less. Any app for which there is no way to block all ads is an app that I will not keep, period.
Sent from my Incredible 2 using XDA
exiquio said:
Labor isn't free and ads are just one way to monetize. The only question that matters is one related to the Golden Rule.
Would you use an app with ads? Does it bother you? If not, you are doing nothing wrong under the eyes of Bob. If users were to complain and bicker, then perhaps you have another question on your hands: to cater to the users or not.
Click to expand...
Click to collapse
I'll put up with ads if they are non obtrusive and don't get in the way of using the program. Ads should only be present when the program is open and being used, meaning airpush ads should never be used. They are no different than malicious Windows adware programs that push pop-up ads.
It's not the ads, is the the network
Lets be honest, we all think ad networks are intrusive, messy to deal with (updating SDK's), and overall feel like we "cheapen" our apps when use them. But - they are the most popular "layer" you can slide into a free app in hopes of earning a little revenue from it. Using a completely different model such as fermium, or carrier-billing (Android only at the moment), or in-app purchases go beyond the scope of this post, but are better ways of earning revenue from an app in general.
Let's be honest:
No one like intrusion and advertisements like notifications, audio ads, video ads are intrusive.
Banner ads are fine as all they consume is a part of screen but some app started sending me notifications and I couldn't figure out the source, it's really annoying especially when notification can't be cleared down.
And in android 2.3, there no such feature to swipe the notification. You had to clear all notifications at a time.
I don't think developers object to app ads. There are many developers who have many apps on DesktopAd using banner ads and pop-ups to monetize apps. And I can see banner ads in many Windows apps, but I don't feel them bother me a lot. My apps are on Windows 8.1 desktop platform, I use small banners in my games, I think they would not bother my players. As a result I got generous profits from in-app ads. By the way, my ads SDK is from DesktopAd.com.

There's a Zombie-like Security Flaw in Almost Every Android Phone

Nice article to read.. Just thought I would share.. MODS PLEASE DELETE IN CASE THIS IS A DUPLICATE.
http://news.yahoo.com/theres-zombie-...013019842.html
There's a Zombie-like Security Flaw in Almost Every Android Phone
LikeDislike
Abby Ohlheiser 56 minutes ago
Technology & Electronics
.
View gallery
There's a Zombie-like Security Flaw in Almost Every Android Phone
Almost every Android phone has a big, gaping security weakness, according to the security startup who discovered the vulnerability. Essentially, according to BlueBox, almost every Android phone made in the past four years (or, since Android "Donut," version 1.6) is just a few steps away from becoming a virtual George Romero film, thanks to a weakness that can "turn any legitimate application into a malicious Trojan."
While news of a security vulnerability in Android might not exactly be surprising to users, the scope of the vulnerability does give one pause: "99 percent" of Android mobiles, or just under 900 million phones, are potentially vulnerable, according to the company. All hackers have to do to get in is modify an existing, legitimate app, which they're apparently able to do without breaking the application's security signature. Then, distribute the app and convince users to install it.
Google, who hasn't commented on the vulnerability yet, has known about the weakness since February, and they've already patched the Samsung Galaxy S4, according to CIO. And they've also made it impossible for the malicious apps to to install through Google Play. But the evil apps could still get onto a device via email, a third-party store, or basically any website. Here's the worst-case scenario for exploitation of the vulnerability, or what could potentially happen to an infected phone accessed via an application developed by a device manufacturer, which generally come with elevated access, according to BlueBox:
Installation of a Trojan application from the device manufacturer can grant the application full access to Android system and all applications (and their data) currently installed. The application then not only has the ability to read arbitrary application data on the device (email, SMS messages, documents, etc.), retrieve all stored account & service passwords, it can essentially take over the normal functioning of the phone and control any function thereof (make arbitrary phone calls, send arbitrary SMS messages, turn on the camera, and record calls). Finally, and most unsettling, is the potential for a hacker to take advantage of the always-on, always-connected, and always-moving (therefore hard-to-detect) nature of these “zombie” mobile devices to create a botnet.
The company recommends users of basically every Android phone double check the source of any apps they install, keep their devices updated, and take their own precautions to protect their data. But as TechCrunch notes, Android users really should be doing this anyway, as the devices tend to come with a " general low-level risk" from malware. That risk, however, is elevated for users who venture outside of the Google Play store for their apps.
So while the actual impact of the vulnerability is not known, neither is the timeline for fixing it. Manufacturers will have to release their own patches for the problem in order to fix it, something that happens notoriously slowly among Android devices.
Mr_Jay_jay said:
/snip
Click to expand...
Click to collapse
As always, this really boils down to the same thing: don't be a fool in the most non-pejorative way possible. With the exception of the Syrian Electronic Army fiasco awhile back, secured and verified app vendors like Google Play (or Apple's App Store) continue to provide all the services most users will need without exposing the end-user to this kind of vulnerability. If you don't expose yourself, you're not at risk.
That said, this all relies on the notion of the end-user being at least somewhat vigilant, which can be quite dangerous.
Rirere said:
As always, this really boils down to the same thing: don't be a fool in the most non-pejorative way possible. With the exception of the Syrian Electronic Army fiasco awhile back, secured and verified app vendors like Google Play (or Apple's App Store) continue to provide all the services most users will need without exposing the end-user to this kind of vulnerability. If you don't expose yourself, you're not at risk.
That said, this all relies on the notion of the end-user being at least somewhat vigilant, which can be quite dangerous.
Click to expand...
Click to collapse
Not every Android device has access to Play Store though, by-default. I have a tablet now that doesn't have access. If a normal user had such a device, they wouldn't likely go through the process needed to get Play Store, and would just deal with whatever marketplace app existed.
This exploit will likely only ever affect users that by default use devices that do not have Google support. Many of these are distributed among 3rd world nations and are typically a hot bed of illicit activities anyways. Of the first worlders that would be affected, it would be those using black market apps without knowing the risks involved in doing so. Most black market users are knowledgeable enough to know to check their sources and compare file sizes before installing apk's.
Also the notion that 99% of devices being affected has nothing with the OS being flawed (Google reportedly fixed the flaw in March), but rather the OEMs being slow in pushing out (or not pushing out at all) the patched hole.
Also I would be weary of a security outfit that has been around since 'mid-2012' and continues to pride themselves as a start-up mobile security firm.
espionage724 said:
Not every Android device has access to Play Store though, by-default. I have a tablet now that doesn't have access. If a normal user had such a device, they wouldn't likely go through the process needed to get Play Store, and would just deal with whatever marketplace app existed.
Click to expand...
Click to collapse
Granted, but the Play Store reduces the attack surface by a considerable margin. Right now, I consider non-Google blessed Android to be something akin to stock Windows 7 with Defender and Firewall turned off-- you can do just about anything with it, but you're running at a risk by not deploying some vendor-based add-ons (in this case, choosing to use the unit available).
I do understand that many devices sell outside of the Google world, before anyone jumps on me, but it doesn't change how the vulnerabilities play out.
This boils down to:
If users install a virus then they get a virus!!! This affects all Android phones!!!!!!!! Oh Nos!
Sucks that this is being patched. Guess there will be no more modding games for me.

[Q] Kids apps sold within a wide subscription

Hi,
Question for kids apps developers...
I would really appreciate you opinion on this one.
We believe the app store model is not working well when it come to small kids
No niche categorization ( within the “kids” world )
Added value app are “buried” by tons of low value apps
lot’s of sexual & violent apps on app stores
Parents dislike the ongoing pressure to buy or unexpected purchases
MOST importantly to this forum - Good kids apps are NOT rewarding to most app developers (pushed down by mega brands/monetizers)
We would like to offer our audience (close to 1 million kids) a premium subscription based service for parents and reward developers based on real usage (real minutes spent on their app) dividing the revenues among them. so instead of one time compensation, it would be spread over time.
What do you think???
Some more info on our website
BTW- I'm not posting this to sign you up, I'm sincerely looking for your feedback and your expectations from such a service.
Thanks!
Eldad from Kidoz
Good idea.
One of device brend (don't remember what) recently presented "sandbox" mode on their devices. Parents can activate this mode and then kid play without any danger. You could integrate your "market" there But google play policy don't allow to modify apk files via applications...

Malware Analyst here - love to hear from developer's on in-app Ad Fraud

Hey all, wondering if you could shed some light or share your opinion/view on the matter.
I have analyzed malicious apps that run services in the background to do constant ad impressions and make money. Typically they will autostart themselves using broadcast receivers (from common things like "BOOT_COMPLETE/etc" and invoke services).
From your experience monetizing in-app Android ads, does this seem like a practical way to make money? Im not aware of the common CPM/CPC rates, but if they are good, why dont we see this more with apps? Or even, why arent developers stacking banners on top of each other to make double money per impression for example (ethics aside)? App store may catch it, but there are plenty of ways to obfuscate this from Bouncer. Are there obstacles Im not seeing? Id also like to hear anything else you think I should watch out for with Android in-app ad fraud. Thanks!

About the use of accessibility service in Greenify

Like many other developers, I also received the 30-days deadline warning email from Google Play team about the potential "misuse" of accessibility service in Greenify.
As the very first developer who introduced this trick of "misusing" accessibility to achieve UI automation years ago, I'm very proud that many more creative tool apps followed this approach to enable fantastic functionality beyond the imagination of the creator of Android, without root. It's a miracle bred from the openness and flexibility of Android.
Unfortunately, the supervisor of the dominant app market is now declaring its right of final interpretation, to judge the proper use of Android API and claim that this whole idea is unacceptable. At this point, I feel I have to say something.
Why accessibility service?
As we all know, root is the ultimate playground of super users in the Android community. But it also has its inconvenience and grey side, so I decided to make Greenify work for users with non-root device. I had been experimenting with many approaches for this purpose in almost the whole year 2013. Finally I found the magic of UI automation driven by accessibility service. With this approach, many more users now enjoy the improved battery life and smoothness brought by Greenify.
I know that accessibility service is not a perfect solution, considering the overall UI performance degradation involved (explained below). So I never gave up seeking alternative approaches ever since, (many of which might also be considered API "misusing" in strict speaking) but still no better approach found. If Android could provide any alternative solution, I would never prefer accessibility service in the first place.
The Good
Accessibility service is so powerful, that I have to admit it's some kind of Pandora's box.
With accessibility, developers could not only help people with disabled abilities, but also greatly benefit the general users with wonderful use cases, including:
• Remote assistant via touch interaction, without root. (seems like no such apps yet?)
• Automate the tedious operations inside not-well-designed apps, even possibly driven by Tasker or IFTTT, without root.
• Programatically trigger global actions (e.g. Back, Home).
• Overlay the whole screen including the notification shade on Android O.
• ……
I even wrote a small app with accessibility service to "fix" the bottom navigation bar of my wife's Moto X Style, whose touch screen is not reading touches any more in bottommost rows of pixels.
The Bad
With such power, accessibility service is also becoming the trending target of malware, endangering average users world-wide. A typical malware could deceive user to enable its accessibility service and then perform many dangerous actions without user consent, including gaining other sensitive privileges.
Together with screen overlay, this could even hide from average user's observation, effectively making it a seductive approach, thus highly dangerous in the wild.
The Ugly
The dangers above may not be a thread to advanced users, but the overall UI lag caused by accessibility service could be a real hurt.
Android delivers accessibility events to active accessibility service in two phases. Events are first generated in the current interacting app and immediately sent to system process, then dispatched to separate accessibility services, each in its own process.
If no accessibility services enabled, both phases are shutdown, thus no performance affection at all. If at least one accessibility service is enabled, the first phase is turned on, in full power, no matter which types of events are interested (declared by accessibility service). The second phase is taking that into consideration and only delivers the interested events to each accessibility service.
The performance lag comes mostly out of the first phase because some types of accessibility events are so heavy, considering how frequently they are triggered. For example, TYPE_WINDOW_CONTENT_CHANGED is generated and sent every tiny bit of UI content changes and TYPE_VIEW_SCROLLED is generated and sent every pixel your finger is moved across during scrolling, even if no accessibility services are interested in them.
Sounds crazy? Unfortunately that's the current situation. Although Android O took a step to address that, the situation is still not changed fundamentally. Maybe in Google's view, accessibility service is not intended for general users, so performance optimization is never in the priority.
How is Greenify doing
Performance is always Greenify's priority since it’s one of the purposes defining Greenify. So I took all the possibilities to improve that in the past years, even greatly pulled-back by Android system itself.
First of all, Greenify declares no interest of events at all at most of the time and only declares minimal interest of events (all are trivial to generate) and specific target (system settings app) required during the short period of on-going hibernation operation. This is implemented by dynamic registration, cutting the cost of the second phase to almost zero.
Due to the inefficient implementation in Android system, the first phase is still the bottleneck of UI performance. After a long time of trial and failure, I finally managed to eliminate that cost, in a tricky way. With necessary permission granted via ADB, Greenify only enables its accessibility service during the hibernation operation and disable it immediately afterwards. That means, if no other accessibility service enabled, you will have no performance problem of accessibility service at all while still enjoy the power of Greenify.
With above optimization, Greenify limited the events it could receive to the minimal, thus also effectively keeps the privacy of users in safety. I'm planning to bring this optimization to broader users who has little knowledge about ADB, and even to other apps with accessibility service hopefully.
My Concern
Accessibility service is a yard full of potential creativity and magic. It should never be a Pandora's Box if Android itself implement it with caution in the first place. I understand the complexity and historical reasons that lead to the current situation, but feel sorry and sad about how Google deals with this situation, by banishing popular tool apps. Will that make Android users more secure? I highly doubt.
I don't know if Google Play team represents the atitude of Android team at Google. If so, it will then be the breaking day for all Android developers, when Google starts to use its power to judge the "proper use" of Android API, even if it's not used by malware.
Will it come a day that the use of screen overlay besides showing information will be banned?
Will it come a day that the use of content provider not for providing data will be banned?
Will it come a day that the use of internal APIs will be banned?
oasisfeng said:
Like many other developers, I also received the 30-days deadline warning email from Google Play team about the potential "misuse" of accessibility service in Greenify.
As the very first developer who introduced this trick of "misusing" accessibility to achieve UI automation years ago, I'm very proud that many more creative tool apps followed this approach to enable fantastic functionality beyond the imagination of the creator of Android, without root. It's a miracle bred from the openness and flexibility of Android.
Unfortunately, the supervisor of the dominant app market is now declaring its right of final interpretation, to judge the proper use of Android API and claim that this whole idea is unacceptable. At this point, I feel I have to say something.
Why accessibility service?
As we all know, root is the ultimate playground of super users in the Android community. But it also has its inconvenience and grey side, so I decided to make Greenify work for users with non-root device. I had been experimenting with many approaches for this purpose in almost the whole year 2013. Finally I found the magic of UI automation driven by accessibility service. With this approach, many more users now enjoy the improved battery life and smoothness brought by Greenify.
I know that accessibility service is not a perfect solution, considering the overall UI performance degradation involved (explained below). So I never gave up seeking alternative approaches ever since, (many of which might also be considered API "misusing" in strict speaking) but still no better approach found. If Android could provide any alternative solution, I would never prefer accessibility service in the first place.
The Good
Accessibility service is so powerful, that I have to admit it's some kind of Pandora's box.
With accessibility, developers could not only help people with disabled abilities, but also greatly benefit the general users with wonderful use cases, including:
• Remote assistant via touch interaction, without root. (seems like no such apps yet?)
• Automate the tedious operations inside not-well-designed apps, even possibly driven by Tasker or IFTTT, without root.
• Programatically trigger global actions (e.g. Back, Home).
• Overlay the whole screen including the notification shade on Android O.
• ……
I even wrote a small app with accessibility service to "fix" the bottom navigation bar of my wife's Moto X Style, whose touch screen is not reading touches any more in bottommost rows of pixels.
The Bad
With such power, accessibility service is also becoming the trending target of malware, endangering average users world-wide. A typical malware could deceive user to enable its accessibility service and then perform many dangerous actions without user consent, including gaining other sensitive privileges.
Together with screen overlay, this could even hide from average user's observation, effectively making it a seductive approach, thus highly dangerous in the wild.
The Ugly
The dangers above may not be a thread to advanced users, but the overall UI lag caused by accessibility service could be a real hurt.
Android delivers accessibility events to active accessibility service in two phases. Events are first generated in the current interacting app and immediately sent to system process, then dispatched to separate accessibility services, each in its own process.
If no accessibility services enabled, both phases are shutdown, thus no performance affection at all. If at least one accessibility service is enabled, the first phase is turned on, in full power, no matter which types of events are interested (declared by accessibility service). The second phase is taking that into consideration and only delivers the interested events to each accessibility service.
The performance lag comes mostly out of the first phase because some types of accessibility events are so heavy, considering how frequently they are triggered. For example, TYPE_WINDOW_CONTENT_CHANGED is generated and sent every tiny bit of UI content changes and TYPE_VIEW_SCROLLED is generated and sent every pixel your finger is moved across during scrolling, even if no accessibility services are interested in them.
Sounds crazy? Unfortunately that's the current situation. Although Android O took a step to address that, the situation is still not changed fundamentally. Maybe in Google's view, accessibility service is not intended for general users, so performance optimization is never in the priority.
How is Greenify doing
Performance is always Greenify's priority since it’s one of the purposes defining Greenify. So I took all the possibilities to improve that in the past years, even greatly pulled-back by Android system itself.
First of all, Greenify declares no interest of events at all at most of the time and only declares minimal interest of events (all are trivial to generate) and specific target (system settings app) required during the short period of on-going hibernation operation. This is implemented by dynamic registration, cutting the cost of the second phase to almost zero.
Due to the inefficient implementation in Android system, the first phase is still the bottleneck of UI performance. After a long time of trial and failure, I finally managed to eliminate that cost, in a tricky way. With necessary permission granted via ADB, Greenify only enables its accessibility service during the hibernation operation and disable it immediately afterwards. That means, if no other accessibility service enabled, you will have no performance problem of accessibility service at all while still enjoy the power of Greenify.
With above optimization, Greenify limited the events it could receive to the minimal, thus also effectively keeps the privacy of users in safety. I'm planning to bring this optimization to broader users who has little knowledge about ADB, and even to other apps with accessibility service hopefully.
My Concern
Accessibility service is a yard full of potential creativity and magic. It should never be a Pandora's Box if Android itself implement it with caution in the first place. I understand the complexity and historical reasons that lead to the current situation, but feel sorry and sad about how Google deals with this situation, by banishing popular tool apps. Will that make Android users more secure? I highly doubt.
I don't know if Google Play team represents the atitude of Android team at Google. If so, it will then be the breaking day for all Android developers, when Google starts to use its power to judge the "proper use" of Android API, even if it's not used by malware.
Will it come a day that the use of screen overlay besides showing information will be banned?
Will it come a day that the use of content provider not for providing data will be banned?
Will it come a day that the use of internal APIs will be banned?
Click to expand...
Click to collapse
Well thanks for all you've done for the Android community!
Perhaps you and many other devs should just pull away from Google and switch to a different market like FDroid.
Google has done this sort of thing in the past, like with SCR Pro (screen recording software with internal audio support) because it changed SELinux Policy. If Google loses their cut money, maybe they would rethink that decision. Personally if I was Google, I'd just add a "Potential Security Issue" or a "Modifies Critical Security Settings" indicator to apps on the Play Store that use the Accessibility Services or change SELinux Policy, or other security related settings. Give the users the option of what they choose or not choose to run on their phones! They already have some sort of a system in place that already does this with the "Play Protect" system. Slowly but surely, Android is becoming more like iOS with less freedom.
Interesting update to original article on XDA
https://www.xda-developers.com/google-threatening-removal-accessibility-services-play-store/
"Update: LastPass has just responded to this news and states that there will be “no immediate impact” for their Android apps. Whether or not this means that other applications will be given leniency remains to be seen."
Accessibility Service options
If I may ask -- what are you going to do? Are you going to pre-emptively unpublish the app before the 30 day limit is up? Are you going to try to reach out to Google and ask them to clarify whether there is any changes / clarifications? (LastPass implies they have gotten some kind of assurance, but they don't directly state that). Or, are you going to try to get as compliant as possible (put the appropriate language in the appropriate places), and hope for the best?
As far as I'm concerned your app is one of the few mission critical apps in the android ecosystem. So I can only hope that this can be resolved amicably.
I think this change is aimed solely at Substratum, as I have heard (not confirmed) than in Android 8.1 without root/unlocking and only using accessibility services, OMS can be exploited for theming. So Google is using a shotgun to kill all apps using this service rather than narrow their focus.
@oasisfeng
An insightful, deliberate and extremely well written post! ?
Sent from my SM-G955W ??
I think its time of the developers make a big migration of the apps to the XDA store to save the lagacy of the -7.0
Sent from my Asus ZenFone 3 Deluxe using XDA Labs
divineBliss said:
Interesting update to original article on XDA
https://www.xda-developers.com/google-threatening-removal-accessibility-services-play-store/
"Update: LastPass has just responded to this news and states that there will be “no immediate impact” for their Android apps. Whether or not this means that other applications will be given leniency remains to be seen."
Click to expand...
Click to collapse
LastPass and Chrome enjoyed a cozy relationship in the past. That said I'm almost surprised at the news given Google could easily incorporate similar functionality into Android. Maybe Google and LogMeIn have something going on the side (new rumor...lol).
As much as i like to sympathize with developers using Accessibility to improve functionality of Android, I can't.
Because in last couple of months i have seen many crappy apps (cleaners n all) also start asking for same permission, and average user don't really understand or even care to read what impact or access they are giving and more than 95% of Android user falls in this category. We at XDA or other nerdy site don't like this fact but it's bare truth.
And from Google perspective, They can't monitor each and every App for eternity that which one is using this permission for good and which one isn't. So hammer of Banning all of it seems only solution for now on their part. especially considering Accessibility service was never meant to use for improving "Device Functionality" (Button Mapper, Battery Saver) it was always meant for "helping hand" in case normal functionally can't be used, not as "Replacement".
Also in my personal option, i think this ban is more due to App developers are trying to bypass each and every thing device manufacturers put (Bexby & Assistant Button) than apps trying to help with routine task (LastPass, Greenify).
Though they may not say explicitly OEM are not happy with their excursive feature are ruined by apps using accessibility as bypass and they (including Google in this case) can force Play Store to make restriction on this. (whether it's is Good practice or not is entire different topic so don't dwell into that debate in replies)
So in conclusion, Till Google come up with better solution (and i think they will, People working there are not fools they understand good that this access can do for Android as whole) , banning seems fair to me because security & stability of 95% users comes above 5% demanding modification & features.
Nerdy will always find a way but it's extremely difficultly to help understand average user why their phone suddenly start behaving abnormally
and that's what Google & OEM face daily.
jineshpatel30 said:
As much as i like to sympathize with developers using Accessibility to improve functionality of Android, I can't.
Because in last couple of months i have seen many crappy apps (cleaners n all) also start asking for same permission, and average user don't really understand or even care to read what impact or access they are giving and more than 95% of Android user falls in this category. We at XDA or other nerdy site don't like this fact but it's bare truth.
And from Google perspective, They can't monitor each and every App for eternity that which one is using this permission for good and which one isn't. So hammer of Banning all of it seems only solution for now on their part. especially considering Accessibility service was never meant to use for improving "Device Functionality" (Button Mapper, Battery Saver) it was always meant for "helping hand" in case normal functionally can't be used, not as "Replacement".
Also in my personal option, i think this ban is more due to App developers are trying to bypass each and every thing device manufacturers put (Bexby & Assistant Button) than apps trying to help with routine task (LastPass, Greenify).
Though they may not say explicitly OEM are not happy with their excursive feature are ruined by apps using accessibility as bypass and they (including Google in this case) can force Play Store to make restriction on this. (whether it's is Good practice or not is entire different topic so don't dwell into that debate in replies)
So in conclusion, Till Google come up with better solution (and i think they will, People working there are not fools they understand good that this access can do for Android as whole) , banning seems fair to me because security & stability of 95% users comes above 5% demanding modification & features.
Nerdy will always find a way but it's extremely difficultly to help understand average user why their phone suddenly start behaving abnormally
and that's what Google & OEM face daily.
Click to expand...
Click to collapse
Actually Google has fairly simple way to provide a solution, for example, Play services API to provide similar functionality with refined security and proper restriction. The new SMS verification API is a good example for app to avoid requesting SMS permission. Fairly speaking, SMS too was not designed for verification purpose.
They did nothing for a long time, but rush to ban all these apps in just 30 days. I think they just don't care that much about advanced user like the old days when Android was competing with iOS fiercely.
I’m the developer of Battery Overlay Percent. Not one of the big apps out there but it does got 500,000 downloads and about 30,000 active users.
I use accessibility services for hiding overlay when user pull status bar or on later release to resolve overlay breaking permission.
I’m quite sad with Google closing down on legitimate use cases. Personally from an open source OS we now live in a world of 2 pretty closed mobile environments.
And who’s collecting most data? Play Services of course.
Hope there will be a shift from this centerlized dark state we’re in.
oasisfeng said:
Actually Google has fairly simple way to provide a solution, for example, Play services API to provide similar functionality with refined security and proper restriction. The new SMS verification API is a good example for app to avoid requesting SMS permission. Fairly speaking, SMS too was not designed for verification purpose.
Click to expand...
Click to collapse
I thought something similar and i still think they will implement it but not before 30day timeline.
They did nothing for a long time, but rush to ban all these apps in just 30 days. I think they just don't care that much about advanced user like the old days when Android was competing with iOS fiercely.
Click to expand...
Click to collapse
True that. When you have 90% of market you don't need to expand it any more you just need to control it.
I don't mean to sound like I'm supporting them, but this what people do in general, when they have control on almost entire market.
Luckily for now (and unlike with ios) Android can still and probaly can always exist without the Google Play Store and Google Play Services and thats still a big win over ios! And as much as I hate this news, this is something I think will ultimately lead advanced users and advanced developers to become less dependant upon Google Play Store and Google Play Services.... and for users/devs like us, thats actually a good thing!
Maybe now Google Play Store will finally get some real competition!! Google has certainly with their actions have now got a significant chunk of users and devs properly motivated to look or create healthy alternatives for app licensing and license management on Android, thats for sure and to also kick it off with a healthly sample of some of the most prized apps android has ever seen, yikes!! Greenify is amazing but Tasker too; bigger yikes!!!
cantenna said:
Luckily for now (and unlike with ios) Android can still and probaly can always exist without the Google Play Store and Google Play Services and thats still a big win over ios! And as much as I hate this news, this is something I think will ultimately lead advanced users and advanced developers to become less dependant upon Google Play Store and Google Play Services.... and for users/devs like us, thats actually a good thing!
Maybe now Google Play Store will finally get some real competition!! Google has certainly with their actions have now got a significant chunk of users and devs properly motivated to look or create healthy alternatives for app licensing and license management on Android, thats for sure and to also kick it off with a healthly sample of some of the most prized apps android has ever seen, yikes!! Greenify is amazing but Tasker too; bigger yikes!!!
Click to expand...
Click to collapse
Exactly.
We need to stand our ground.
I have a feeling that alternate app stores are about to see a huge boost in users. Google is going to sorely regret their decisions.
betatest3 said:
Exactly.
We need to stand our ground.
I have a feeling that alternate app stores are about to see a huge boost in users. Google is going to sorely regret their decisions.
Click to expand...
Click to collapse
I admire your optimistic attitude - But... Alphabet is a Juggernaut and if it suits them - They'd probably just buy any potential problem ?
Sent from my SM-G955W ??
shaggyskunk said:
I admire your optimistic attitude - But... Alphabet is a Juggernaut and if it suits them - They'd probably just buy any potential problem ?
Click to expand...
Click to collapse
Not to mention the relatively small number of individuals that will be adversely impacted when all is said and done. Bigger players (eg: LastPass) will likely receive some form of dispensation. Niche tools like Greenify might take a hit but that is not where the revenue stream resides. Google ain't catering to the Android enthusiast community.
shaggyskunk said:
I admire your optimistic attitude - But... Alphabet is a Juggernaut and if it suits them - They'd probably just buy any potential problem ?
Click to expand...
Click to collapse
I dont think they'll be buying the amazon app store any time soon.
but to the point of the other user you quoted, you'll likely see the accessibility needing market move to another app store.
cantenna said:
I dont think they'll be buying the amazon app store any time soon.
but to the point of the other user you quoted, you'll likely see the accessibility needing market move to another app store.
Click to expand...
Click to collapse
Sure. There are a handful of reputable alternative app stores that cater to small communities that dare to venture off the beaten path. Niche market; don't think Google is worried. Nor is it likely Amazon will cater to Android enthusiasts.
If Alphabet/Google is serious about reining in potential abuses look for further adjustments in the successor to Android 8.
Can you on XDA Dev put an parallel market on the XDA Labs with PayPal account with less taxes (good for all) to maintaining and update webpage to conventional user going fu*k up the Google to the apps then will not survive on the Google rules on the market?
Put and good design market to the conventional use on XDA please.
Sent from my Asus ZenFone 3 Deluxe using XDA Labs
---------- Post added at 05:31 PM ---------- Previous post was at 05:20 PM ----------
If you on XDA Labs put a inner market in the app with an Market safe with PayPal the developers can update the Apps on the Market with no acessibility but make an link to be updated on the XDA Labs with a plugin or a new full version, we can free more people with xposed solutions to defeat Google Policy
Sent from my Asus ZenFone 3 Deluxe using XDA Labs
---------- Post added at 05:37 PM ---------- Previous post was at 05:31 PM ----------
Dev can update your apps and redirect to the external link in XDA Labs without violated google policy.
Sent from my Asus ZenFone 3 Deluxe using XDA Labs
---------- Post added at 05:50 PM ---------- Previous post was at 05:37 PM ----------
XDA Labs have power with an safe and free market scanning and checking malicious new apps to be so respected and Xposed so popular then I believed on the futere ASUS and Samsung make the ZenFone Deluxes and Galaxy S with Xposed on stock on the most expansive "and free" devices, absolutely. Please think renew the XDA webpage and XDA Labs to defeat the enemies of the freedom on coding.
Sent from my Asus ZenFone 3 Deluxe using XDA Labs
---------- Post added at 05:58 PM ---------- Previous post was at 05:50 PM ----------
Its time of the XDA webpage be more like Facebook on design and XDA Labs more like market on the safe and design to receive more redirected links to update and pay by apps on the XDA Labs with PayPal an Google Account if I like. Well if that happen we really will see if Google support free coding on open source.
Sent from my Asus ZenFone 3 Deluxe using XDA Labs
Interesting/digestible read; nothing new if you have been keeping up with the news on this topic.
https://www.howtogeek.com/333365/android-apps-using-accessibility-services-could-disappear/

Categories

Resources