“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. “
Hey,
When I turned on my phone the RAM it was taking was 300 MB, after a days use it is now 500MB (even after pressing 'clear RAM' button).
I've entered Settings->apps->running and it shows only two small things (the keyboard and some weather widget) which combined take only 20 MB.
So what is the rest of the memory is beign allocated for?
Thank you.
Does your rom have Usage Manager in the app drawer?
Sent from my SAMSUNG-SGH-I747 using xda app-developers app
Here is the path to all your applications.
Settings -> Apps --> Swipe left until the menu Running --> On top you see the description "Show cached processes", klick on it --> now you see the rest of the running applications
pc103 said:
Does your rom have Usage Manager in the app drawer?
Sent from my SAMSUNG-SGH-I747 using xda app-developers app
Click to expand...
Click to collapse
No, the closest I have is "Task Manager".
lenovoOwner said:
Here is the path to all your applications.
Settings -> Apps --> Swipe left until the menu Running --> On top you see the description "Show cached processes", klick on it --> now you see the rest of the running applications
Click to expand...
Click to collapse
Thank you, indeed I see some more RAM guzzlers, but It seems like they make up most of the addition but not all of it ... plus funny thing, when I try to close everything (in 'running' and 'cache) and I reenter- here it is there again...
1) Can I see all of the elements that take up my ram (the system as well)?
2) Can I close them properly?
Thank you very much.
PS. Is there some comfortable way to jump between apps? Like in the Iphone where by pressing the 'Home' button will show you a bar with a row of icons of the currently active processes....
For your PS question, it's a long press on the Home button (below the GS3 screen).
Sent from my SAMSUNG-SGH-I747 using xda app-developers app
---------- Post added at 10:14 PM ---------- Previous post was at 09:45 PM ----------
The closest app I'm running to that option is Android Tuner Free. I got it for its storage optimization functions.
The busy interface has a learning curve, but it is a comprehensive & poweful app. I recommend Advanced mode & the One Click home screen.
For what you want, see both the Tasks & Kill All tiles. The first is a Task Mgr., the second is a quick 1 click. The app can teach a lot about what runs & why. It also offers a lot of fine control.
I also use the root app Startup Manager which is self explanatory & efficient.
Sent from my SAMSUNG-SGH-I747 using xda app-developers app
pc103 said:
For your PS question, it's a long press on the Home button (below the GS3 screen).
Sent from my SAMSUNG-SGH-I747 using xda app-developers app
Click to expand...
Click to collapse
LOL {hit myself on the head}, didn't occur me to try...
pc103 said:
---------- Post added at 10:14 PM ---------- Previous post was at 09:45 PM ----------
Click to expand...
Click to collapse
pc103 said:
The closest app I'm running to that option is Android Tuner Free. I got it for its storage optimization functions.
The busy interface has a learning curve, but it is a comprehensive & poweful app. I recommend Advanced mode & the One Click home screen.
For what you want, see both the Tasks & Kill All tiles. The first is a Task Mgr., the second is a quick 1 click. The app can teach a lot about what runs & why. It also offers a lot of fine control.
I also use the root app Startup Manager which is self explanatory & efficient.
Sent from my SAMSUNG-SGH-I747 using xda app-developers app
Click to expand...
Click to collapse
I was hoping there is a way to avoid using apps...
Ok, I suppose it opens another question which I thought about creating a new thread for, but if the opportunity already arose...
How do you actually know if you can trust an app?
I'm kinda new to android and I'm much more used to the opennes of windows, also I'm pretty paranoid (a cellphone contains information 100 times more sensitive than a PC (At least my PC is like that)). I look at the permissions every app want to have and I'm simply aghast, I know of the logic behind those requests (at least for most of those I've seen) but I have zero transparency over what actions the app takes.
That really stress me a great deal...
oy-ster said:
How do you actually know if you can trust an app?. . . (a cellphone contains information 100 times more sensitive than a PC (At least my PC is like that)). I look at the permissions every app want to have and I'm simply aghast, I know of the logic behind those requests (at least for most of those I've seen) but I have zero transparency over what actions the app takes.
That really stress me a great deal...
Click to expand...
Click to collapse
Digital Privacy
Well it certainly stresses the last remaining fiber of your privacy. I just watched the latest "60 Minutes Overtime" piece on data brokers framing this as a lifestyle issue. Step back from the small screen & consider that your actions on board the PC have a ripple effect on your smartphone. "NAI Opt out" & "Disconnect software" are useful PC search words.
Where it Went
I rarely hear from a tech guru or even a lawyer who can decipher a EULA, TOS or Privacy agreement they didn't author themselves; yet online, we are steeped in the cumulative concessions we have accepted from them and the affiliates and partners they enable for.
The Biggest Brother?
Google is a data harvester, not a broker. They are the custodians of much of our imprint online across all platforms. check your settings accordingly; within each Google service / app/ platform you use and adjust them to taste. Know, for example, that persistent login to Gmail will append any collocated G-Search activity to your G profile if Web Data | Web History remains on. I read recently that simply joining Plus has a similar but more comprehensive effect by default, by unifying the G tracking across your entire electronic imprint.
Android Permissions
Yes. The most invasive part of Android is its permissions free for all. They are demands, not requests that each app poses. The logic is sometimes one sided and self serving to the developers at our disadvantage. What can we do?
1. Know something about your developer. XDA membership in an app developer helps define their role in a community. Check their website, reviews, accessibility, postings etc.
2. Consider lower permission alternative apps listed in the play store.
3. For each app you review in the Play Store, (have you checked play store settings yet?) assess its longevity in the marketplace to decide if you are willing to be an early adopter.
4. Resist resorting to apps to broker built-in functions your system already has. Learn your OS.
5. Weigh the logic of each permission demanded, based on risk / reward and your intended uses. Example: On my phone Google search leads the field with 59 permissions. App Permisssions by FSecure is in the low end group with zero. How do I know? App Permissions. What can I do? More on that later.
6. Debloat. I have frozen over 60 apps/services/processes using a combination of tools ranging from built in (no root) Application Management to Startup Manager and the App Quarantine app.
7. Don't be lazy about toggling settings as needed. One stock default has the GPS always enabled which may not be necessary for you.
8. Learn about the types of location services in your OS. Check location settings in affected apps and consider toggling location services as needed. Apps will prompt if the needed service is off when you use them.
9. Review your synch settings. Mine are off on the OS. I use a 3rd party mail app and manually back up contacts using Super Backup when needed.
10. Review background data settings. they are visible in Settings / Data usage, by selecting Mobile Data, and scrolling to the list of apps to tap through each and set Restrict background data if appropriate. It saves battery by reducing tower hunting and focuses you on which apps pose the highest demands.
I promised more. Learn about App Ops if you haven't. I have the luxury of running a 4.3 version that supports it so I can use a client app to filter and toggle various permissions on a per app basis. There are other, and perhaps more thorough approaches to this but I'm staying with this one for now.
pc103 said:
Digital Privacy
Well it certainly stresses the last remaining fiber of your privacy. I just watched the latest "60 Minutes Overtime" piece on data brokers framing this as a lifestyle issue. Step back from the small screen & consider that your actions on board the PC have a ripple effect on your smartphone. "NAI Opt out" & "Disconnect software" are useful PC search words.
Where it Went
I rarely hear from a tech guru or even a lawyer who can decipher a EULA, TOS or Privacy agreement they didn't author themselves; yet online, we are steeped in the cumulative concessions we have accepted from them and the affiliates and partners they enable for.
The Biggest Brother?
Google is a data harvester, not a broker. They are the custodians of much of our imprint online across all platforms. check your settings accordingly; within each Google service / app/ platform you use and adjust them to taste. Know, for example, that persistent login to Gmail will append any collocated G-Search activity to your G profile if Web Data | Web History remains on. I read recently that simply joining Plus has a similar but more comprehensive effect by default, by unifying the G tracking across your entire electronic imprint.
Android Permissions
Yes. The most invasive part of Android is its permissions free for all. They are demands, not requests that each app poses. The logic is sometimes one sided and self serving to the developers at our disadvantage. What can we do?
1. Know something about your developer. XDA membership in an app developer helps define their role in a community. Check their website, reviews, accessibility, postings etc.
2. Consider lower permission alternative apps listed in the play store.
3. For each app you review in the Play Store, (have you checked play store settings yet?) assess its longevity in the marketplace to decide if you are willing to be an early adopter.
4. Resist resorting to apps to broker built-in functions your system already has. Learn your OS.
5. Weigh the logic of each permission demanded, based on risk / reward and your intended uses. Example: On my phone Google search leads the field with 59 permissions. App Permisssions by FSecure is in the low end group with zero. How do I know? App Permissions. What can I do? More on that later.
6. Debloat. I have frozen over 60 apps/services/processes using a combination of tools ranging from built in (no root) Application Management to Startup Manager and the App Quarantine app.
7. Don't be lazy about toggling settings as needed. One stock default has the GPS always enabled which may not be necessary for you.
8. Learn about the types of location services in your OS. Check location settings in affected apps and consider toggling location services as needed. Apps will prompt if the needed service is off when you use them.
9. Review your synch settings. Mine are off on the OS. I use a 3rd party mail app and manually back up contacts using Super Backup when needed.
10. Review background data settings. they are visible in Settings / Data usage, by selecting Mobile Data, and scrolling to the list of apps to tap through each and set Restrict background data if appropriate. It saves battery by reducing tower hunting and focuses you on which apps pose the highest demands.
I promised more. Learn about App Ops if you haven't. I have the luxury of running a 4.3 version that supports it so I can use a client app to filter and toggle various permissions on a per app basis. There are other, and perhaps more thorough approaches to this but I'm staying with this one for now.
Click to expand...
Click to collapse
Thank you very much for the comprehensive reply!
Indeed some of the things here are common sense but some were fairly new to me, like the close contact you are suggesting with the developer.
I have to ask though, what reviews are you reffering to? the ones in the app market or the ones on here? Also, from what I have seen in the play market, all of the reviews are about functionality but no one actualy checks the veracity of the code.
Like for instance some song recognition&download software that requires internet access permission (makes sense) and SD card access permission (also makes sense), but besides doing what it does (in a splendid manner, leaving tons of happy customers) it also steals your Whatsapp chat logs (just read an article about that breach 10 mins ago)...
How can people catch on that (otherwise the app will linger for 2 years, giving you the impression you're not an early adopter)?
Hrmph, you have given some very sound advice which I obviously intend to follow through and for that I thank you. However it seems to me like the underlying foundation is still trust in the publisher (not to abuse the permissions you had to enable for functionality sake), and the trust should stem from how well the author presents itself to the community. I suppose it is the nature of the beast, it is just that if I were to sneakily attack someone I would make sure to present myself in th best way possible .
thx.
PS. my version is 4.1 but I'll see what I can do about Appops.
P.P.S I just searched for "Tasks" on google market and all I see is an organizer. Did you mean "Task Killer"?
oy-ster said:
Thank you very much for the comprehensive reply!
Indeed some of the things here are common sense but some were fairly new to me, like the close contact you are suggesting with the developer.
I have to ask though, what reviews are you reffering to? the ones in the app market or the ones on here? Also, from what I have seen in the play market, all of the reviews are about functionality but no one actualy checks the veracity of the code.
Both sources really. There's no hard & fast divide as to what aspect reviewers might respond to at either venue. More often, Play Store reviews have alerted me when my device or my Android version gets poor results from an app. Granted code integrity issues are raised more frequently at XDA.
Like for instance some song recognition&download software that requires internet access permission (makes sense) and SD card access permission (also makes sense), but besides doing what it does (in a splendid manner, leaving tons of happy customers) it also steals your Whatsapp chat logs (just read an article about that breach 10 mins ago)...
How can people catch on that (otherwise the app will linger for 2 years, giving you the impression you're not an early adopter)?
Interesting example. I will look for the article. I wonder if the app declared that permission in their Play Store disclosure. If not, it challenged Google's policing system. I read somewhere that SELinux in newer ROMs, set to "Enforcing" brokers applicable policies from each host domain and also restricts apps from exceeding their declared permissions. (See also my note on 4.3+ below)
Hrmph, you have given some very sound advice which I obviously intend to follow through and for that I thank you. However it seems to me like the underlying foundation is still trust in the publisher (not to abuse the permissions you had to enable for functionality sake), and the trust should stem from how well the author presents itself to the community. I suppose it is the nature of the beast, it is just that if I were to sneakily attack someone I would make sure to present myself in th best way possible .
You're welcome! Placing that trust is ultimately a leap of faith, so we ask ourselves:
Does my configuration already offer this function at the OS or existing app level?
Can I justify each declared permission here?
Is there a less invasive equivalent to this app?
Have I gone over the settings thoroughly once installed?
What does my installed anti-virus say about this?
Do I need this to auto launch or only on demand?
Is it using excessive data or uptime as I monitor?
Am I getting all the Android security I could be with my current rom image?
You get the picture. Common sense, best practices & due diligence can go a long way toward closing the security gap.
PS. my version is 4.1 but I'll see what I can do about Appops.
Google only exposed it (to client apps like App Ops Starter) in 4.3 & 4.4.0, before & after that I believe an Xposed Framework module is the main alternative.
P.P.S I just searched for "Tasks" on google market and all I see is an organizer. Did you mean "Task Killer"?
Click to expand...
Click to collapse
The "Tasks & Kill All tiles" I referred to appear on Android Tuner Free's One Click advanced mode home screen. BTW certain apps on my phone are "frozen" when not in use.
I forgot to mention. 4.3 I'm running is on the 4.1.2 bootloader, completely avoiding lopsided knox security. I hope I didn't appear to recommend the OTA update. That's a personal choice.
Sent from my SAMSUNG-SGH-I747 using xda app-developers app
pc103 said:
Quote:
Both sources really. There's no hard & fast divide as to what aspect reviewers might respond to at either venue. More often, Play Store reviews have alerted me when my device or my Android version gets poor results from an app. Granted code integrity issues are raised more frequently at XDA.
Interesting example. I will look for the article. I wonder if the app declared that permission in their Play Store disclosure. If not, it challenged Google's policing system. I read somewhere that SELinux in newer ROMs, set to "Enforcing" brokers applicable policies from each host domain and also restricts apps from exceeding their declared permissions. (See also my note on 4.3+ below)
You're welcome! Placing that trust is ultimately a leap of faith, so we ask ourselves:
Does my configuration already offer this function at the OS or existing app level?
Can I justify each declared permission here?
Is there a less invasive equivalent to this app?
Have I gone over the settings thoroughly once installed?
What does my installed anti-virus say about this?
Do I need this to auto launch or only on demand?
Is it using excessive data or uptime as I monitor?
Am I getting all the Android security I could be with my current rom image?
You get the picture. Common sense, best practices & due diligence can go a long way toward closing the security gap.
Google only exposed it (to client apps like App Ops Starter) in 4.3 & 4.4.0, before & after that I believe an Xposed Framework module is the main alternative.
Click to expand...
Click to collapse
Thanks again!
I just wanted to note that after spending some time here in the forum( http://forum.xda-developers.com/android/apps-games/ ) looking for some intresting picks, I haven't actually encountered much comments from people that actually went over the code... so I'm a bit bummed out. :silly: :laugh:
pc103 said:
The "Tasks & Kill All tiles" I referred to appear on Android Tuner Free's One Click advanced mode home screen. BTW certain apps on my phone are "frozen" when not in use.
Click to expand...
Click to collapse
Oh. Got it.
Anyway, Thank you!!!
oy-ster said:
Thanks again!
I just wanted to note that after spending some time here in the forum( http://forum.xda-developers.com/android/apps-games/ ) looking for some intresting picks, I haven't actually encountered much comments from people that actually went over the code... so I'm a bit bummed out. :silly: :laugh:
...Anyway, Thank you!!!
Click to expand...
Click to collapse
You're welcome. To be fair, most times I've seen postings by people who background checked code it was in rom threads, or over root exploits or security apps. In most other cases due diligence is our best defense.
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/