Related
So I'm a bit of a paranoid guy, and I like to use security extensions in my browser to keep companies from spying on me, such as Ghostly and Adblock Plus. I'm also concerned about AT&T tracking my browsing history and so on.
What are some good security apps for Android? I found Adblock Plus but I can't seem to find anything like Disconnect + and so on, the kind of stuff they have listed here http://donttrack.us/
idumych said:
So I'm a bit of a paranoid guy, and I like to use security extensions in my browser to keep companies from spying on me, such as Ghostly and Adblock Plus. I'm also concerned about AT&T tracking my browsing history and so on.
What are some good security apps for Android? I found Adblock Plus but I can't seem to find anything like Disconnect + and so on, the kind of stuff they have listed here http://donttrack.us/
Click to expand...
Click to collapse
Read my article here about orbot.i think it will keep you safe enough
http://forum.xda-developers.com/showthread.php?t=2088703
♥gt-n7000 galaxy note 4.0.4 using xda premium♥
you would probably be better served w/ adaway since it blocks via hosts. you'll need to be rooted, of course.
and if you're serious about privacy, read up about tor.
Sent from my SGH-I777 using xda premium
sepehrthegreat-iran said:
Read my article here about orbot.i think it will keep you safe enough
http://forum.xda-developers.com/showthread.php?t=2088703
♥gt-n7000 galaxy note 4.0.4 using xda premium♥
Click to expand...
Click to collapse
I've tinkered with Orbot before, but how well does it keep the connection to the other nodes when you switch between GSM and WiFi?
Naked Browser seems secure enough browser as it demands.
This is the reborn version of Adblocker, which helps you block advertisements from various Ad-Network.
It can block advertisements in many aspects according to a pre-loaded-list, such as activities, views, hosts-based, webview-based, receivers and many many more.
It does not affect system hosts file, and does not conflict with it either. It also has whitelist feature so you can easily control it. You can also use it along with AdAway or other adblockers to extend its power, especially built-in app ads.
This module is being actively developed, and I will update it about every ten days. If you have any issues or want to contribute to the project, feel free to contact me via Github or XDA.
MOD EDIT
Numerous reports from users of certain devices that this module can disable things, cause erratic behaviour and other issues, have been reported.
Specifically, most of these seem to be related to users of Xiaomi's Mi-line of devices. In the case of these devices, the module can cause behaviour such as stopping the launcher and removing some options from settings, making the module difficult to remove.
Proceed with your own caution, and preferably a backup to restore if you encounter such erratic behaviours. This will also be posted in the OP of the thread.
There are varying alternatives that work well. This module has also NOT been updated at all lately, and it's recommended that users seek alternatives.
Download:
http://repo.xposed.info/module/com.aviraxp.adblocker.continued
Features:
- Activityies Block
- Views Block
- Hosts Block (Not affect system hosts file)
- WebView Block
- Services Block
- Receivers Block
- .............
Principle of Work:
I hook some fundamental classes and methods of Android system, check if they are included in a pre-loaded-list (maintained by me), and break the calling of these classes and methods if included. There might be some false positives so feel free to contact me.
FAQs:
- How does it work compared to AdAway and MinMinGuard?
AdAway modifies system hosts file to redirect some ad servers to local host, thus prevent from accessing them. MinMinGuard blocks some prebuilt app Ad providers from taking effect. My application have both of their features, and extends by blocking services and receivers.
- Where is the hosts' source?
Now, it covers Dan Pollock's hosts and some app specific blocking hosts. I am searching for good sources which is simple and effective. If you have some suggestions, feel free to let me know.
- Why does not it take effects to some browsers?
The reason is basically the same as unbeloved hosts. Some browsers have their own network solutions which conflict with the normal handling method. But for browsers which simply use original WebView loading method it works well.
- There are some false positives!
Contact me via Github or here. You can also use the whitelist feature. For element whitelist, just enable debug logging, find the element(activities, hosts, views...) according to a 'block success' line, and add them to the whitelist. Each element takes one line.
- I need to view ads for some reason.
Use the whitelist feature. However, some apps uses Android System WebView as an elements loader, so you should whitelist it too. But this will ramp down the power of blocking. I am working on a better whitelist feature.
- I want to donate to you for your work.
Use the PayPal donation option:https://www.paypal.me/wanghan1995315. But it will not make any difference or be a privilege for you. There is no such thing as advanced support.
- How can I contribute to you if I found something useful (hosts, Ad SDKs)?
I am working on a block list repo on Github. Feel free to open a pull request.
XDA:DevDB Information
AdBlocker Reborn, Xposed for all devices (see above for details)
Contributors
aviraxp
Source Code: https://github.com/aviraxp/AdBlocker_Reborn
Xposed Package Name: com.aviraxp.adblocker.continued
Version Information
Status: Stable
Current Stable Version: 1.5.1
Stable Release Date: 2017-03-13
Created 2017-02-11
Last Updated 2017-04-18
CHANGE LOG:
1.1.1:
- Fix an incremental bug which causes many false positives
- Add system apps protection
- Add shortcut block (all credits to apsun)
- Various Fixes
1.1:
- Add more builtin hosts
- Replace regular expression with Easylist rules to improve performance
- Tweak default preferences (Hiding is disabled and WebView Block is enabled)
- Introduce element whitelist
- Implement system framework apps protection
- Various fixes
1.0.2:
- Implement aggressive block toggle
- Add XDA link and PayPal donation
- Improve blocking effect by importing blacklist from AdScanner
- Address more false positives
Works flawlessly. Had some issues with MinMinGuard. I am currently using AdAway+Adblocker Reborn. Everything is perfect.
Version 1.0.2 has been updated. If you meet any issues feel free to contact me.
Sent from my OnePlus2 using XDA Labs
works perfect atm,thanks
works as expected. great
Thank you for your work. Could anyone confirm if this module impact (negatively) battery duration ?
IgorMarinho said:
Thank you for your work. Could anyone confirm if this module impact (negatively) battery duration ?
Click to expand...
Click to collapse
From my personal experience, it does not have any evident effect on battery. But to be honest, every exposed module will affect battery since the phone now has more work to do, which is implemented by the module. I will keep the battery consumption as low as possible.
Sent from my OnePlus2 using XDA Labs
Uhm what exactly is the reason I should use this. I just tested a website for adblock check, whereas adaway active lead to first pic.
Disable adblock and enable this tool and restart lead to the second one. So obviously the ad had not been blocked by this mod.
Is your mod for ads in games or how should i understand that?
Just a bit confused, sry
Awesome module
What can this xposed module/app do that THIS APP can't? Just curious, thanks!
@aviraxp thanks a ton!! Obviously does the trick especially when it comes to being redirected to a million other places then what I clicked on. In that sense, that is something that adway does not do no matter what host file/s I use as well as adguard and minminguard. There were a couple sites I just about swore off because it was impossible to do anything as far as a navigation goes but I can do as I like now thank you very much.
pieceofphil said:
Uhm what exactly is the reason I should use this. I just tested a website for adblock check, whereas adaway active lead to first pic.
Disable adblock and enable this tool and restart lead to the second one. So obviously the ad had not been blocked by this mod.
Is your mod for ads in games or how should i understand that?
Just a bit confused, sry
Click to expand...
Click to collapse
I guess you are using Opera, right? Opera has its own proxy solution and unfortunately it does not use the system web view, thus I cannot get it work with the same reason as UnbelovedHosts. I am still searching for more stable hooking methods.
Sent from my OnePlus2 using XDA Labs
@aviraxp Does this continuation of "pl.cinek.adblocker" ?
exodius48 said:
@aviraxp Does this continuation of "pl.cinek.adblocker" ?
Click to expand...
Click to collapse
Generally, yes. But his code only covers about 10% of this app. You can think this is a new app too.
Sent from my OnePlus2 using XDA Labs
aviraxp said:
Generally, yes. But his code only covers about 10% of this app. You can think this is a new app too.
Sent from my OnePlus2 using XDA Labs
Click to expand...
Click to collapse
Nice.
Just a feature request, hope this app can block all miui ads. :angel:
exodius48 said:
Nice.
Just a feature request, hope this app can block all miui ads. :angel:
Click to expand...
Click to collapse
Sadly I do not have xiaomi devices. For MIUI, you can use other tools like RootToolsNeo.
Sent from my OnePlus2 using XDA Labs
aviraxp said:
Sadly I do not have xiaomi devices. For MIUI, you can use other tools like RootToolsNeo.
Sent from my OnePlus2 using XDA Labs
Click to expand...
Click to collapse
Ah..ok, nevermind.
Just gave the module another go, still having the same issue.
I'm playing this game : Animation Throwdown the Quest for Cards, and i have minminguard installed and the game whitelisted, the game offers ads in exchange for some increased drop rates, and you have to click on the watch button for the ads to start, which in my setup works well.
When i install this module, activate, whitelist the game, reboot (exact steps), clicking the watch ads button in game does nothing, rebooting doesn't change anything.
Once i disable/remove the module and reboot i can run the ads again, haven't tried with other apps since i don't have any others with ads in them tbh.
ticktock666 said:
Just gave the module another go, still having the same issue.
I'm playing this game : Animation Throwdown the Quest for Cards, and i have minminguard installed and the game whitelisted, the game offers ads in exchange for some increased drop rates, and you have to click on the watch button for the ads to start, which in my setup works well.
When i install this module, activate, whitelist the game, reboot (exact steps), clicking the watch ads button in game does nothing, rebooting doesn't change anything.
Once i disable/remove the module and reboot i can run the ads again, haven't tried with other apps since i don't have any others with ads in them tbh.
Click to expand...
Click to collapse
I am addressing this issue, but I need more info. Does every time you click the ads it does nothing?
Sent from my OnePlus2 using XDA Labs
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/
Any favorites recommended that work well with the pixel 3? Looking for a non-rooted option (for now).
Blokada is the best option I can find. It's available on f-droid as well as directly from their website. Totally free and very configurable. No root required as it's using the built-in VPN functionality.
WITH ROOT, the king is Adaway for sure. Simple, lightweight and works great.
WITHOUT ROOT I'd personally recommend DNS66. Blocks host names via DNS through Android's VPN interface. Without ROOT that's as good as it gets, or another app very similar like sirebral123 mentioned above. Both are available on F-droid site.
How about just using the Brave browser? Built on chromium, faster than chrome, doesn't track you around, and it has ad blocking built in. Available in the play store and I use it on my desktop as well.
Droid1019 said:
How about just using the Brave browser? Built on chromium, faster than chrome, doesn't track you around, and it has ad blocking built in. Available in the play store and I use it on my desktop as well.
Click to expand...
Click to collapse
That doesn't remove ads that appear in apps.
Blokada is working pretty well. Thanks. Any preferences on hosts or dns servers to select or add? I was able to download it here on xda labs app. Same version available in fdroid.
To people recommending VPN apps to block ads.... you realize you are then funneling all of your phone's network traffic through their servers, right? That would make me wildly uncomfortable.
GldRush98 said:
To people recommending VPN apps to block ads.... you realize you are then funneling all of your phone's network traffic through their servers, right? That would make me wildly uncomfortable.
Click to expand...
Click to collapse
They run a local VPN on the phone, there is no 3rd party server
Sent from my Pixel 2 using XDA Labs
Cares said:
That doesn't remove ads that appear in apps.
Click to expand...
Click to collapse
If I find an app i like and use on a regular basis, I just pay for it and that takes care of the ads for me and supports the developer.
Well I feel like a horses ass. That's actually pretty clever.
I use a combination of PiHole at my house/work and brave browser.
Droid1019 said:
If I find an app i like and use on a regular basis, I just pay for it and that takes care of the ads for me and supports the developer.
Click to expand...
Click to collapse
Everyone should sign up for Google Opinion Rewards. It's a great way to get money for the Play Store and is perfect for this exact scenario.
https://play.google.com/store/apps/details?id=com.google.android.apps.paidtasks&hl=en_US
Droid1019 said:
If I find an app i like and use on a regular basis, I just pay for it and that takes care of the ads for me and supports the developer.
Click to expand...
Click to collapse
There are public apps that don't offer a pay to remove ads thing like sports score apps.
You may wanna give "adguard for android" a shot, i have a paid version, works like a charm..
Droid1019 said:
If I find an app i like and use on a regular basis, I just pay for it and that takes care of the ads for me and supports the developer.
Click to expand...
Click to collapse
Yeah but not every app has a "pay to make the ads go away" feature.
I'm rooted but prefer using Adguard. Being to disable ads for individual apps or website is a plus. Also, the app has a feature to allow the use of custom DNS which I have changed to use Cloudflare DNS. The VPN it creates is a local VPN, data DOES not get funneled to their site. i've been using adguard for over 2 years and paid lifetime. They do have a free trial
I can speak to both options. My phone and my wife's (Pixel 3 XL and Pixel 3) are both rooted and use AdAway. My sons' two phones (Huawei Mate SEs) and their tablet (Samsung Galaxy Tab S2 8") are not rooted and each have a lifetime licence of AdGuard. I notice pretty much no difference in terms of what they block. I can't do an A/B spead comparison, but none of their devices seem adversely impacted by AdGuard. I very seriously considered going to the OP6T for my wife and I and going with AdGuard and no root since I am on T-Mobile and would have used the OG Pixel XL and Pixel both as trade-ins. My decision to stay with Google phones and root had nothing to do with ad blocking. In fact, the three devices with AdGuard are easy enough to root. The Mates are BL unlocked, and the S2 is pretty easy already. Any difference between AdGuard and AdAway is simply not worth giving them root access that they don't need.
How do the VPN ad-blockers (like AdGuard) affect battery life? I assume they use more than Adaway or other root methods.
dsmero said:
I use a combination of PiHole at my house/work and brave browser.
Click to expand...
Click to collapse
Me too. Pi Hole is really good. Easy to install on a Raspberry Pi and it blocks ads and spyware on all devices connected to your network. Should you encounter a web site which doesn't work it is easy to suspend Pi Hole for a predertermined time, or until you re-enable it. A nice little project on very cheap hardware. You don't need the most expensive Raspberry Pi either - but I would recomment connecting it via ethernet so if anyone is interested make sure you buy a Pi with an ethernet socket.
[emoji1360] i already buy it before two years with life license. Its amazing
sneilkanth said:
You may wanna give "adguard for android" a shot, i have a paid version, works like a charm..
Click to expand...
Click to collapse
Sent from my Pixel 3 using Tapatalk
Twitter Ad Eater is a module for the Xposed/LSPosed framework that attempts to remove ads from the Twitter Android application.
Currently tested on Android 11 / latest LSPosed but should work on other versions as well.
Downloads: https://github.com/ppawel/twitter-ad-eater/releases
Source code: https://github.com/ppawel/twitter-ad-eater
Report issue: https://github.com/ppawel/twitter-ad-eater/issues
Thank you! Can confirm this works with the latest EdXposed 0.5.2.2_4683.
Working with Android 11 / EdXposed 0.5.2.2_4683 / OP5T
May I post a feature request?!
It seems you are filtering out all the views containing the string "promoted". Could you like add an option for custom strings?!
For example, I really don't wish to see k-pop news popping up on my trending page! So I could add the string "K-Pop" (is it case sensitive?)
Cheers!
ChesterXXX said:
Working with Android 11 / EdXposed 0.5.2.2_4683 / OP5T
May I post a feature request?!
It seems you are filtering out all the views containing the string "promoted". Could you like add an option for custom strings?!
For example, I really don't wish to see k-pop news popping up on my trending page! So I could add the string "K-Pop" (is it case sensitive?)
Cheers!
Click to expand...
Click to collapse
The code searches for the "promoted" string in the view id, not in the content of the tweets. It is really hard to find out exactly the content of the tweets because the structure of the Twitter app UI is very complex and also the whole app is scrambled with ProGuard, so it's not easy to reverse-engineer anything.
I will add your request to the TODO list and keep it in mind in case I will find a way to get tweet content.
ppawelppawel said:
The code searches for the "promoted" string in the view id, not in the content of the tweets. It is really hard to find out exactly the content of the tweets because the structure of the Twitter app UI is very complex and also the whole app is scrambled with ProGuard, so it's not easy to reverse-engineer anything.
I will add your request to the TODO list and keep it in mind in case I will find a way to get tweet content.
Click to expand...
Click to collapse
these feature will be too strong. imagine opening elon's tweet replies without bitcoin and youtube links. btw awesome moves dev thanks
Yeah, looking forward to the potential new features. Any updates coming soon, @ppawelppawel? I'm pretty much glued to your Github looking for changes.
Sorry, been busy with work in the last few weeks, but will try to add some more filtering features soon.
just want to throw out there that I love this module, it's so simple yet so effective because nothing else removes the ridiculous promoted ads (tried dns level blocking & minminguard). on a side note, I wish we had a module to remove the same type of ads in the official reddit app, but that's wishful thinking.
Does the app work on Android 8? I can't install in on my phone running Oreo now.
Not sure if it will work but LSPosed at least supports Android 8.1 so I will try to release a version with proper SDK requirements so you can try it out - right now at least Android 10 is required by the apk I think.
thirtythr33 said:
just want to throw out there that I love this module, it's so simple yet so effective because nothing else removes the ridiculous promoted ads (tried dns level blocking & minminguard). on a side note, I wish we had a module to remove the same type of ads in the official reddit app, but that's wishful thinking.
Click to expand...
Click to collapse
Thanks for the feedback. Yes, the module is quite simple but there is one flaw - if you scroll up and down your timeline, you will notice that the whole view is jumping around, like it skips one or two posts sometimes. This is because the way the module works - it hides the posts that are ads and it is visible when you scroll.
It would be much better to take out the ads before they get added to the timeline view but it's very complicated to figure out how the Twitter app works as everything is obfuscated and it's a huge code base to analyze.
Anyway, thanks again, glad you enjoy it.
xymopen said:
Does the app work on Android 8? I can't install in on my phone running Oreo now.
Click to expand...
Click to collapse
New version released which should be installable on Android 8.1 (SDK 27).
Release v1.3 · ppawel/twitter-ad-eater
Lowered minimum SDK version to 27 (Android 8.1) - this aligns it with the minimum Android version supported by LSPosed. Now it should be possible to at least install the module on lower Android ver...
github.com
Can't go lower than that because of LSPosed compatibility.
ppawelppawel said:
Thanks for the feedback. Yes, the module is quite simple but there is one flaw - if you scroll up and down your timeline, you will notice that the whole view is jumping around, like it skips one or two posts sometimes. This is because the way the module works - it hides the posts that are ads and it is visible when you scroll.
It would be much better to take out the ads before they get added to the timeline view but it's very complicated to figure out how the Twitter app works as everything is obfuscated and it's a huge code base to analyze.
Anyway, thanks again, glad you enjoy it.
Click to expand...
Click to collapse
I really do not even notice the jumping around, but its a small price to pay for no promoted nonsense. thanks dev
ppawelppawel said:
New version released which should be installable on Android 8.1 (SDK 27).
Release v1.3 · ppawel/twitter-ad-eater
Lowered minimum SDK version to 27 (Android 8.1) - this aligns it with the minimum Android version supported by LSPosed. Now it should be possible to at least install the module on lower Android ver...
github.com
Can't go lower than that because of LSPosed compatibility.
Click to expand...
Click to collapse
Thanks for your work. Works on Oreo with LSPosed without problem!
Any updates planned? Hoping this isn't abandoned again like the old Twitter ad killer.
I hope updates will come when necessary, but for now it works fine!
Is it not possible to do this using something like adaway?
Thanks. It works fine on android 11 .
It works fine if you're scrolling down, but try to scroll up on the feed and Twitter will jump all over the place. It gets the job done, but could use some improvement.
Works perfectly on Android 11, thanks