Related
Hi there! I was curious as to the ROM developer workflow. I'm somewhat familiar with building AOSP for x86 VMs and have done some skinning and manipulating system apk's ... but I have some other questions:
1. What distinguishes a ROM package from other zip installers, I guess since it is *nix, everything's a file and most ZIPs then just have the files changed?
2. Jokersax makes mention of doing all development on the device itself... What this workflow, just doing a lot of nandroid backups then, or just replacing things on the fly and hoping for the best?
3. What options exist for adapting system level native code, perhaps I guess I'm asking if, for instance, the camera works with Blur stock SBFs, how could one go disassembling the functionality and deriving CM9 compatible packages? Are the drivers that tightly coupled with the UI elements? That would seem impossible to maintain, and say what you want about Motorola, I couldn't imagine this to be the case.
Thanks -ap
Sent from my MB855 using xda app-developers app
antipasto said:
Hi there! I was curious as to the ROM developer workflow. I'm somewhat familiar with building AOSP for x86 VMs and have done some skinning and manipulating system apk's ... but I have some other questions:
1. What distinguishes a ROM package from other zip installers, I guess since it is *nix, everything's a file and most ZIPs then just have the files changed?
2. Jokersax makes mention of doing all development on the device itself... What this workflow, just doing a lot of nandroid backups then, or just replacing things on the fly and hoping for the best?
3. What options exist for adapting system level native code, perhaps I guess I'm asking if, for instance, the camera works with Blur stock SBFs, how could one go disassembling the functionality and deriving CM9 compatible packages? Are the drivers that tightly coupled with the UI elements? That would seem impossible to maintain, and say what you want about Motorola, I couldn't imagine this to be the case.
Thanks -ap
Sent from my MB855 using xda app-developers app
Click to expand...
Click to collapse
1) You are pretty much correct....and rom can be turned into a simple one file zip or vice versa
2) He actually uses the device along with a build machine. You can do some simple stuff on the device itself, but if you're going to get into decompiling jars or apks, you will need a bot or a PC.
3) Apktool (Linux/Windows) or Android Suite (Windows) will allow you to break down the apks like you are describing. I'm sure you can make a blur apk work with CM9 (obviously app developers on the Play market do manage to make both). I'm not very familiar with Blur/CM7, as I started work on ROMs after ICS had hit, and I really didn't see much real desire to do something that wasn't forward from where my phone was.
Mainly, you can do source work, which you are most likely familiar with the process of.
I do "port" work...taking the framework, apps and some other necessary functionality-related parts and making a new rom for my device with it.
If you are interested in the process, by all means get in touch with me via PM. We are in need of some people to help with a void that has been left by our team member Spleef taking on a second job.
Thank you so much for the extensive reply. I have about a kabillion personal projects, it would be perhaps interesting to ruminate some on the metadevelopment as it were, I do notice that the Cyanogen project seems to have a lot more ability to automate their workflows, it would be cool to try and get more people into those kinds of logistics to help out... Anyway, I'm trying to remain productive, I'm a long time lurker, and I can't bring myself to post unnecessarily to even get to the 10 posts I need to provide feedback in the development forums, but I'll try
I've been really inspired with the Clojure / Java community, especially "Leiningen" and things like Jenkins for continuous integration. Could be cool to try and think at this level, perhaps like a chrooted VM or something that enthusiasts could run to assist in build CPU times, or hell I dunno, this kind of thinking is all pie in the sky and is hell to set up possibly for little gain, although I'm encouraged that Bittorrent is being used a little more here and there perhaps to offload some of the hosting costs. FWIW I have used S3 in my own projects, and for various static sites I have, I've been hard pressed to pass 30 cents a month in hosting costs on S3, but this is all low traffic stuff and there's a lot of options out there with various kinds of advantages and disadvantages.
All in all, thank you all for your continued efforts, especially going into the later part of this year when JB will mature, and the possibility of ICS drivers being integrated. You guys rock!
I'm working on a JellyBean port of Cornerstone. It is currently building with CM10, but does not work very well at all. I'm not sure if this has to do with the resolution of my tablet, 1900x1200 TF700T, which I tried to account for, but may have screwed up. I could use some help on this, as I have very little time and not much experience with building Android from source. Specifically, any advice on toolchains/testing code without needing to do an entire build would be appreciated. What would be more appreciated is if I could get some help with the project itself to get it to a stable place, and perhaps to include a path for continuous updates with as new releases come out.
https://github.com/emil10001/cornerstone
My current build environment is an Ubuntu VM, just using the commandline. I write the code and try a build. It usually fails and I go in and fix the errors that it gives me. This process means that I spend about 1-10 minutes coding and 2 hours waiting for it to build and fail. At present, it's actually building just fine, but it isn't working very well.
I really like the idea of Cornerstone and would like to see it working on newer builds. I am also reaching out to the Cornerstone Google Group, but they have been fairly silent for months. https://groups.google.com/forum/?fromgroups=#!topic/cornerstone-dev/Gz345pbd-co
Thanks,
John
I did talk with them a while back and the did say they're working on updating the codebase to support jellybean.
I had a quick glance at your fork.
This way its really hard to test, you could better just fork frameworks/base from android and then modify the files instead of the copying the changed files.
That would make it easier to test, view what changed, etc.
You could also use gerrit.
mmm path/to/it will do a quick rebuild.
I've had the apps up on github.com/sgt7 but they haven't been updated since way too long, will update them when I find some time.
Sent from my GT-P1000
...
Thanks for the tips!
The reason that I am keeping them separate is mainly for sanity, I wanted to try to keep the cornerstone stuff outside the main android code so that I can keep the android codebase relatively up-to-date, and also very obvious about what's a part of cornerstone for anyone that wants to grab the source from me. I'm also wondering if it's possible to pull part of this, say frameworks/base, into Eclipse (without it taking a day and a half to build the workspace).
Also, with gerrit, I wanted to keep this separate from the CyanogenMod stuff, mainly due to the comments that Dianne Hackborn made on G+ to Steve Kondik. I have a feeling that that's what killed the project.
I'd also really like to see how this works on a 1200x800 device, since that's what Cornerstone was originally designed for. I'm thinking that I screwed up the data in the xml resources, and that that's a big reason as to why it looks so funky on my device.
emil10001 said:
Thanks for the tips!
The reason that I am keeping them separate is mainly for sanity, I wanted to try to keep the cornerstone stuff outside the main android code so that I can keep the android codebase relatively up-to-date, and also very obvious about what's a part of cornerstone for anyone that wants to grab the source from me. I'm also wondering if it's possible to pull part of this, say frameworks/base, into Eclipse (without it taking a day and a half to build the workspace).
Also, with gerrit, I wanted to keep this separate from the CyanogenMod stuff, mainly due to the comments that Dianne Hackborn made on G+ to Steve Kondik. I have a feeling that that's what killed the project.
I'd also really like to see how this works on a 1200x800 device, since that's what Cornerstone was originally designed for. I'm thinking that I screwed up the data in the xml resources, and that that's a big reason as to why it looks so funky on my device.
Click to expand...
Click to collapse
Just checkout a new branch with the modified code, that's what version control is for.
Also, i believe it should be fine now if there is some sort of a whitelist implementation, and only few apps are supported by it. (*le Samsung Mutli Window)
cdesai said:
Just checkout a new branch with the modified code, that's what version control is for.
Also, i believe it should be fine now if there is some sort of a whitelist implementation, and only few apps are supported by it. (*le Samsung Mutli Window)
Click to expand...
Click to collapse
What happens when you try to use an unsupported app anyway? I have Note 2 with the multiview hack and every app I've tried with it has worked, though I've never tried anything like say Angrybirds, just google voice and Trillian and stuff like that.
Is this still something that you are trying to work on? GOD I would love cornerstone on my tf700!!!
Need some help testing/coding ect? I would love to help, not an advanced dev but working on my android chops daily.
I am available to help with testing.
Am a rom developer.
So i did a quick Google search, however, i didn't find anything answering my question.
So when we think about android we (at least the ones who knows their thing) we know it is related to google. However, so far i know that Android is open source, correct me if i'm wrong, but that means that anyone CAN "cook" their own rom of android. (As soon in the numerous threads in android development). So far so good.
A while back i recall reading Google forbidding Cyanogenmod of including their multi-window feature (the one that allows you to surf the web and watch a youtube video simultaneously as seen in Samsung devices(Note 1/2 probably S4 and S3(?)). Anyways, my guess is they came to terms where they can agree or did Samsung ignore what google had to say? So to make a long story short, what are google's rights when it comes to android?
Can google, for instance, if it doesn't like what a manufacturer is adding to their phone be it a feature or a skin say that they only want manufacturers to stick to the AOSP look and if they do add their own skin they will be taken to court? Can they do this?
Just curious to understand how things are running here. I wanna know the rights google has and if it could have went to court with samsung because of using the multi window feature.
I think that you are asking a good question, to which I have no answer, but would be interested in following this.
Personally, I would like to see an Android ROM devoid of Google.
____________________
Sent from my HD2 JB-CM10 with XDA Premium
shadehh said:
So i did a quick Google search, however, i didn't find anything answering my question.
So when we think about android we (at least the ones who knows their thing) we know it is related to google. However, so far i know that Android is open source, correct me if i'm wrong, but that means that anyone CAN "cook" their own rom of android. (As soon in the numerous threads in android development). So far so good.
A while back i recall reading Google forbidding Cyanogenmod of including their multi-window feature (the one that allows you to surf the web and watch a youtube video simultaneously as seen in Samsung devices(Note 1/2 probably S4 and S3(?)). Anyways, my guess is they came to terms where they can agree or did Samsung ignore what google had to say? So to make a long story short, what are google's rights when it comes to android?
Can google, for instance, if it doesn't like what a manufacturer is adding to their phone be it a feature or a skin say that they only want manufacturers to stick to the AOSP look and if they do add their own skin they will be taken to court? Can they do this?
Just curious to understand how things are running here. I wanna know the rights google has and if it could have went to court with samsung because of using the multi window feature.
Click to expand...
Click to collapse
My understanding is while 'Android' or rather the AOSP is completely open source and free to use as you like, there are parts that Google have restrictive licensing over, or example the 'Gapp' (gmail, google+, play store etc). Manufacturers then also hold rights over the parts they add into Android (skins, other apps etc.).
Google has no control over manufacturers sticking Android on a device and that manufacture changing Android in anyway (hence the many many random Chinese devices), however Google can prevent a manufacturer from having a license to include the play store etc if they are unhappy with whats being done.
Google didn't forbid the CM team from including it, they said they would restrict access to the Play Store for devices running CM. The Play services is the only thing Google has power over, since that's their proprietary service. They cannot prevent someone from making a device that runs Android, since that's open source.
And I so believe Samsung's method is different, because apps require some changes before you can run then in multi windows, so you can't just run any app (officially, that is).
Lesicnik1 said:
Google didn't forbid the CM team from including it, they said they would restrict access to the Play Store for devices running CM. The Play services is the only thing Google has power over, since that's their proprietary service. They cannot prevent someone from making a device that runs Android, since that's open source.
And I so believe Samsung's method is different, because apps require some changes before you can run then in multi windows, so you can't just run any app (officially, that is).
Click to expand...
Click to collapse
I see. Doesn't that in theory mean that Samsung could just take their sgs 3, remove all google services and smack their own play store onto it or am i missing something here?
shadehh said:
I see. Doesn't that in theory mean that Samsung could just take their sgs 3, remove all google services and smack their own play store onto it or am i missing something here?
Click to expand...
Click to collapse
Oh they could. But then it would be blocked from other Google projects as well.
Wayne Tech S-III
Hi all
This is my thread for an ongoing project im working on called AndroidOAP
OAP is not Owesome Android Project, lol
This is Andriod Old Age Pensioner!
But WAIT!! This may have many applications to other areas in the caring community!
Background
My mum is 75 and has early stage altzimers. I have noticed a lapes of memory, eyesight and hearing. I have also just got her a 10" rk3066 4.1 tab for xmas.
The aim of this is to help her keep in touch with family and friends (social networking), keep up to date on the weather/news (she loves it), keep her mind active (games).
Aim of Project
This project has a few aims, guided by anyone who wants to contribute. some of which are :
BASIC
- Creating a simple UI that is easy for pensioners/handicapped people to use
- Identifying simple to use apps that perform complex tasks
- Utilise the accessibility capabilities of android specifically for the users needs
- Monitor the device remotely
- Monitor the users interactions and provide alerts (IE medication, doctors apointments, etc)
EXTRA
- Create a working rom that can be installed on devices that can be given to the target audience (OAPs, disables, etc)
- Obtain ongoing support for this project
This will probably not interest most of you but anyone willing to contribute to this nobell cause will be very appreciated
Please get in touch with any ideas
Thanks for your time
Chriz
Cass1977 said:
Hi all
This is my thread for an ongoing project im working on called AndroidOAP
OAP is not Owesome Android Project, lol
This is Andriod Old Age Pensioner!
But WAIT!! This may have many applications to other areas in the caring community!
Background
My mum is 75 and has early stage altzimers. I have noticed a lapes of memory, eyesight and hearing. I have also just got her a 10" rk3066 4.1 tab for xmas.
The aim of this is to help her keep in touch with family and friends (social networking), keep up to date on the weather/news (she loves it), keep her mind active (games).
Aim of Project
This project has a few aims, guided by anyone who wants to contribute. some of which are :
BASIC
- Creating a simple UI that is easy for pensioners/handicapped people to use
- Identifying simple to use apps that perform complex tasks
- Utilise the accessibility capabilities of android specifically for the users needs
- Monitor the device remotely
- Monitor the users interactions and provide alerts (IE medication, doctors apointments, etc)
EXTRA
- Create a working rom that can be installed on devices that can be given to the target audience (OAPs, disables, etc)
- Obtain ongoing support for this project
This will probably not interest most of you but anyone willing to contribute to this nobell cause will be very appreciated
Please get in touch with any ideas
Thanks for your time
Chriz
Click to expand...
Click to collapse
If I read this correctly, you want to develop an OS based on Android, but one that is extremely simple to use? All I know is that this would be an extremely time consuming project, probably half a year at the least, because you'd have to remove tons of drawables (images and stuff that is rendered) and code, and add in many more. It would be much easier to just install a launcher with big icons, change the system font size to the largest possible, perhaps use some accessibility settings, and debloat the tablet to the max.
Has your mother ever used electronic gadgets before? I forget the saying, but it's something like you can't teach an old dog new tricks. Considering that these types of electronics didn't exist during older peoples' generations, it'll be significantly harder to get them accustomed to such things. I don't know if I'm stereotyping or not, but it may be increasingly difficult to teach her how to use Android because she has Alzheimers. I'm not saying it's not worth a try though. As long as she doesn't feel overwhelmed or frustrated, I'd say to definitely try it out for a while and see how it goes. Happy holidays and have a happy new year. I hope your gift does good for you all.
Codename13 said:
If I read this correctly, you want to develop an OS based on Android, but one that is extremely simple to use? All I know is that this would be an extremely time consuming project, probably half a year at the least, because you'd have to remove tons of drawables (images and stuff that is rendered) and code, and add in many more. It would be much easier to just install a launcher with big icons, change the system font size to the largest possible, perhaps use some accessibility settings, and debloat the tablet to the max.
Has your mother ever used electronic gadgets before? I forget the saying, but it's something like you can't teach an old dog new tricks. Considering that these types of electronics didn't exist during older peoples' generations, it'll be significantly harder to get them accustomed to such things. I don't know if I'm stereotyping or not, but it may be increasingly difficult to teach her how to use Android because she has Alzheimers. I'm not saying it's not worth a try though. As long as she doesn't feel overwhelmed or frustrated, I'd say to definitely try it out for a while and see how it goes. Happy holidays and have a happy new year. I hope your gift does good for you all.
Click to expand...
Click to collapse
Thanks for the input dude, but, I think your over complicating things. A custom rom doesnt mean rebuilding it from the ground up! The aim is to find the most user friendly apps and the best settings and then create a rom around that. no need for new icons, etc.
Just to let you know, even though my mum is 75 she has been a nurse all her life so is well versed on using computers (hell, she brought me up and im a developer, lol). Touching icons on a screen will be no problem for her, altzimers or not. To be fair, you are stereotyping and its pretty sad
Regardless of the support I will continue with this as its a personal project that I will persue. I was just after any help I could get, not negativity.
Have a nice day
Cass1977 said:
Hi all
This is my thread for an ongoing project im working on called AndroidOAP
OAP is not Owesome Android Project, lol
This is Andriod Old Age Pensioner!
But WAIT!! This may have many applications to other areas in the caring community!
Background
My mum is 75 and has early stage altzimers. I have noticed a lapes of memory, eyesight and hearing. I have also just got her a 10" rk3066 4.1 tab for xmas.
The aim of this is to help her keep in touch with family and friends (social networking), keep up to date on the weather/news (she loves it), keep her mind active (games).
Aim of Project
This project has a few aims, guided by anyone who wants to contribute. some of which are :
BASIC
- Creating a simple UI that is easy for pensioners/handicapped people to use
- Identifying simple to use apps that perform complex tasks
- Utilise the accessibility capabilities of android specifically for the users needs
- Monitor the device remotely
- Monitor the users interactions and provide alerts (IE medication, doctors apointments, etc)
EXTRA
- Create a working rom that can be installed on devices that can be given to the target audience (OAPs, disables, etc)
- Obtain ongoing support for this project
This will probably not interest most of you but anyone willing to contribute to this nobell cause will be very appreciated
Please get in touch with any ideas
Thanks for your time
Chriz
Click to expand...
Click to collapse
Hi @Cass1977, I see your project as a great initiative to encourage older people to use technology. Although this project might be huge (and I don't have the tablet to test), I might be able to just provide suggestions for your project.
In the Basic section:
Simple UI: It should be easy, due to the fact that many launchers today are user-friendly and easy to use.
Simple to use apps that perform complex stuff: do give some examples.
accessibility capabilities: I don't know of much apps for that (there could be some in the play store) but once we attract the attention of some developers, we can start rolling.
Monitor the device remotely: what do u mean exactly?
Isn't monitor the user's interaction same as the point above? Correct me if I'm wrong.
More suggestions:
Create some tutorials for some complicated apps.
Better colour profile.
Less bright screen=less strain to the eye in low light conditions.
Bigger font=less strain to the eye.
More suggestions will come as I think of them.
Smack that thanks button if I helped!
Note 2 LTE powered by Illusion ROM and Plasma Kernel.
Sent from dat small country called Singapore.
P.S. replies with quotes will be replied to faster.
Hi @Cass1977, I see your project as a great initiative to encourage older people to use technology. Although this project might be huge (and I don't have the tablet to test), I might be able to just provide suggestions for your project.
In the Basic section:
Simple UI: It should be easy, due to the fact that many launchers today are user-friendly and easy to use.
Simple to use apps that perform complex stuff: do give some examples.
accessibility capabilities: I don't know of much apps for that (there could be some in the play store) but once we attract the attention of some developers, we can start rolling.
Monitor the device remotely: what do u mean exactly?
Isn't monitor the user's interaction same as the point above? Correct me if I'm wrong.
Click to expand...
Click to collapse
Good advice, but I feel too many launchers have too many options. the main thing the user needs is simple to access apps. Maybe large icons, etc.My mum likes her news and weather too so simple widgets may help with things like that (A lot are provided with the apps).
TTS will be required too (Text to speech). Maybe an app that will speak highlighted words? Probably have to be built?
More suggestions:
Create some tutorials for some complicated apps.
Better colour profile.
Less bright screen=less strain to the eye in low light conditions.
Bigger font=less strain to the eye.
More suggestions will come as I think of them.
Smack that thanks button if I helped!
Note 2 LTE powered by Illusion ROM and Plasma Kernel.
Sent from dat small country called Singapore.
P.S. replies with quotes will be replied to faster.
By the way, By 'Monitor the device remotly' I mean basically the same thing I have with my kids tabs. Screen Time (MASSIVE RESPECT TO THIS APP!!!) It monitors what my kids do on their tab and allows me to lock it at certain times and give them chores to earn rewards. NOT the same thing we need here, but, thats the kind of monitoring im thinking. Monitoring medication (pop up reminder and if its not used a remote notification)
Any more ideas you have then let me know, Many thanks for your input
Chris
Cass1977 said:
Good advice, but I feel too many launchers have too many options. the main thing the user needs is simple to access apps. Maybe large icons, etc.My mum likes her news and weather too so simple widgets may help with things like that (A lot are provided with the apps).
TTS will be required too (Text to speech). Maybe an app that will speak highlighted words? Probably have to be built?
By the way, By 'Monitor the device remotly' I mean basically the same thing I have with my kids tabs. Screen Time (MASSIVE RESPECT TO THIS APP!!!) It monitors what my kids do on their tab and allows me to lock it at certain times and give them chores to earn rewards. NOT the same thing we need here, but, thats the kind of monitoring im thinking. Monitoring medication (pop up reminder and if its not used a remote notification)
Any more ideas you have then let me know, Many thanks for your input
Chris
Click to expand...
Click to collapse
I can help test launchers according to what u want and report back. Widgets are easy. (Most news apps has widgets.) There may be some apps for TTS designed for this but it's rare (if not none). (TTS apps are extremely complicated) yea, we might need to build it. (Build from Google voice search, possibility)
OK... I'll have to search it up on Google. (We may have to build from another app...) we can build from Screen Time (add some features into it, we could ask Screen Time's developer for help!)
P.S. I think editing a system file can increase the maximum volume of the sound...
Smack that thanks button if I helped!
Note 2 LTE powered by Illusion ROM and Plasma Kernel.
Sent from dat small country called Singapore.
P.S. replies with quotes will be replied to faster.
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/