Hello.
I am here seeking for help and advice on how to approach the development of a security framework (via APP or via hacked Android ROM to be used by kids, that could be monitored by adults (parents or legal tutors).
The idea would be to develop a (white hat) hacked ROM, that would allow the kids to communicate with their friends, but also would allow their parents to supervise/monitor in real time what their children are doing, who are they communicating with and that way protect their children. The thing is not to spy on our kids, but to be able to check regularly if there is anything wrong going on with our kids (mobbing, insults or harassment). Kids aged (10-14) could be influenced by other kids, adults, or adults simulating being kids, and on some occasions they can be tricked to do things without their parents consent/knowledge that can lead to a tricky situation.
When I was a kid, we had the telephone (wired telephone, of course) on the middle of the hallway, so all our conversations were basically family-public. The truth is that there are not many secret things a 10yo kid could/should talk about, but nowadays, it could be a little bit worrying to lend a smartphone to a kid. I think it's just as letting a kid drive a car; he can do it right, or not be able to evaluate the whole consequences of driving a car.
Talking to other parents around me, they all found very interesting the idea of having a telephone that one could lend to their son, having the kid available all the time, and with the peace of mind that you could know what's going on. Of course the kid should be aware of this, and that the telephone comms are being supervised. I think it's no big deal. "Kid, it's very simple. The telephone is mine, and if you want to use it you have to use it under my terms".
Probably, all of us working for a company, have also our communications supervised, cannot make personal phonecalls with the company's telephones, probably cannot navigate to webs looking for personal content, and we asume those rules (because neither the company's phones nor the computers are ours but our company's). It's basically the same, switching the company-employee role to a father-son one.
So, let's get to the point (technically). I am a tech-geek, linux pro-user, have compiled a few ROMs just for personal use, but don't feel capable enough of starting a project of these magnitude alone. If there is anyone willing to help, opine, or whatever, will be very welcome.
First of all, APP or ROM? I basically think that the ROM is the way to go, but I'm asking just in case someone can convince me on the contrary. I will make a poll on this question.
APP An APP could be easily downloaded and installed but would require a rooted phone, and I don't see it clearly if an APP could resolve all the needed issues (access to communications for example) and could be fairly easily uninstalled too.
ROM On the other hand, a ROM would be trickier to uninstall (basically flashing another ROM) but wouldn't be as easy to install as an APP (though the installer model of cyanogenmod could be kind of a solution). There could be an universal (if possible) independent flashable module, over whatever android ROM, or an entire ROM solution.
Features that I want to develop in this ROM (by the way, I call it 'Vigilante ROM'):
Suitable for as many devices as possible
Web interface for parents available to see device-related information
Some hack-proof measures to avoid kids bypassing the ROM's security
Alerts triggered on some events (offensive words, whatever)
Position of the mobile -just in case-
Suitable for as many devices as possible
The first thing I though was what platform should be used for this ROM. To select Android over others (iOS, Blackberry, W7) was a no-brainer. Now, the question is should we use pure Android or make a CyanogenMod fork?
In my opinion, even though every phone maker has to supply their ROM sources publicly, they usually introduce so many modifications (HTC Sense, Samsung Touchwizz and so on) that it looks more difficult to develop a common security framework over each manufacturer's version of Android, rather than using a more standardized one like CyanogenMod.
CyanogenMod already works with a wide number of devices (and a wider one if you count the unofficial supported devices), I think CyanogenMod should be the base of this ROM. If all the 'things' needed could be flash on top of any Android device, would be even better, but technically I need help with this one.
I understand that basically there should be an internal proxy setup, so that all the communications go through this internal proxy, and based on the kind of communication, we could log whatever we need. For example:
Visited URLs
Whatsapp or other messaging apps should be decrypted
Incoming/Outgoing calls/SMS
Social network activity
I know the Whatsapp protocol because I'm familiar with a project called WhatAPI. The key point to be able to intercept whatsapp messaging is a key generated and exchanged during the app install (although there are ways to later ask the Whatsapp server to renegotiate this keyword) and that's used later to encrypt all the messages between the phone and the whatsapp server.
Web interface for parents available to see device-related information
Behind every kid with a smartphone there should be a responsible adult supervising the kid -even if it's remotely-. In my idea, logs of messaging activity, incoming/outgoing calls/SMS and even the position should be available to the supervisor through a web interface.
Some hack-proof measures to avoid kids bypassing the ROM's security
That's an easy one. CRC checks on some keyfiles would guarantee that the device is not being 'counter-hacked'. Some kids are also very techie, and we should make some defences against kids trying to hack (counter-hack?) the phone.
Alerts triggered on some events (offensive words, whatever)
It could be interesting if somehow the supervisor could receive a notification whenever the kid sends/receives and offensive word, or tries to enter some special tagged website.
Hi all.
I have a rooted phone that is used strictly in wifi mode and only needs to be able to run 4 or 5 standard aps, a couple of optional aps, plus the aps that support rooted phones and enhanced power management. I don't want google-anything on it, and I am not kidding. My prime concern is battery life, I hope to be able to run my phone for 3 to 4 days (or more) between charges, so deleting all fluff aps and crapware is important, as is underclocking it and getting rid of google. I also want to stop updating of the operating system and installed software by google.
I hope to do a hardware mod to remove power from the cell band rf transceiver. Despite it being turned off in the phone using software, I am detecting occasional transmissions from the cell band transmitter. Hardware mods are not a problem for me, I'm a retired EE, who specialized in RF design.
I need to know if it's possible for the phone to function if gmail, google+, google search, chrome, google calendar and google-whatever are exhorsized (uninstalled)? Yes, I also want to give the playstore the boot, to prevent excessive battery drain (and, yes, I do realize downloading aps will be slightly more difficult without the playstore).
For those who might be interested, the phone is used as a wifi phone for the home based Ooma telephone service. I also might like to run a mini bittorrent server. It seems to me that the android community could use bittorrent in place of the playstore, thus making it easier for others to give google and google playstore the boot
I love this forum, and want to thank all those that support and administer it.
Aloha,
A
alohagirl said:
Hi all.
I have a rooted phone that is used strictly in wifi mode and only needs to be able to run 4 or 5 standard aps, a couple of optional aps, plus the aps that support rooted phones and enhanced power management. I don't want google-anything on it, and I am not kidding. My prime concern is battery life, I hope to be able to run my phone for 3 to 4 days (or more) between charges, so deleting all fluff aps and crapware is important, as is underclocking it and getting rid of google. I also want to stop updating of the operating system and installed software by google.
I hope to do a hardware mod to remove power from the cell band rf transceiver. Despite it being turned off in the phone using software, I am detecting occasional transmissions from the cell band transmitter. Hardware mods are not a problem for me, I'm a retired EE, who specialized in RF design.
I need to know if it's possible for the phone to function if gmail, google+, google search, chrome, google calendar and google-whatever are exhorsized (uninstalled)? Yes, I also want to give the playstore the boot, to prevent excessive battery drain (and, yes, I do realize downloading aps will be slightly more difficult without the playstore).
For those who might be interested, the phone is used as a wifi phone for the home based Ooma telephone service. I also might like to run a mini bittorrent server. It seems to me that the android community could use bittorrent in place of the playstore, thus making it easier for others to give google and google playstore the boot
I love this forum, and want to thank all those that support and administer it.
Aloha,
A
Click to expand...
Click to collapse
There are threads all over the place trying to do this. Google is deeply ingrained into all the apks used by the os. You will be very hard pressed to find away to remove them completely and still have things work right.
I agree that security is an illusion. I dumped Microshaft in 2013 in order to improve my security and privacy.
However, the android operating system is supposed to be open source, so it should be possible to de-google-ize it IF someone knows how to edit and recompile the android OS.
I was merely asking if anyone knew of a way to give google the boot, even if it came down to paying someone to compile a custom rom.
The loss of google playstore is not a consideration, neither is a monetary forfeiture (any programmers out there?).
I'm curious, is it possible to gag google so it can't connect to the outside world (with a firewall)? We used to do this in XP to prevent Bill's Internet Explorer from downloading updates.
Are any of the custom roms currently available able to run without google-anything??
Is there any hope, or is it truly hopeless? If a custom rom that gave google the boot was available, how many would pay a small fee to have it? Just curious??!!
TY
A.
alohagirl said:
I agree that security is an illusion. I dumped Microshaft in 2013 in order to improve my security and privacy.
However, the android operating system is supposed to be open source, so it should be possible to de-google-ize it IF someone knows how to edit and recompile the android OS.
I was merely asking if anyone knew of a way to give google the boot, even if it came down to paying someone to compile a custom rom.
The loss of google playstore is not a consideration, neither is a monetary forfeiture (any programmers out there?).
I'm curious, is it possible to gag google so it can't connect to the outside world (with a firewall)? We used to do this in XP to prevent Bill's Internet Explorer from downloading updates.
Are any of the custom roms currently available able to run without google-anything??
Is there any hope, or is it truly hopeless? If a custom rom that gave google the boot was available, how many would pay a small fee to have it? Just curious??!!
TY
A.
Click to expand...
Click to collapse
There is one project that is working on removing Google completely in the forums. A search will find it for you. There are some issues that I don't recall if they could find a way around or fix. You could give that a shot.
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/