sweenish
Diamond Member
- May 21, 2013
- 3,656
- 60
- 91
It could be possible that CM is poorly coded, but what I'm trying to say is that both LED control and brightness control are APIs that are open to developers to access. The difference between CM and 3rd party apps is that they offer an interface to access those APIs. LightFlow and Lux act as intermediate apps that must sit by to overwrite those default system values. So for example, LightFlow listens to notifications and instead of allowing the default notification to trigger the LED which by default flashes white, it overwrites that command with its own command to light a green LED for example.
The CM interface opens up the ability to change those defaults, and so there isn't another process that has to listen to notifications. jimv1983's point that it's still listening to notifications is valid because there is already a notification API. It's leveraging existing APIs. Of course the system is listening to notifications. It's just that LightFlow adds a SECOND listener that has to stay open and is prone to getting killed.
Another example I like to cite is all those kernel tweak apps. Custom kernels come with a bunch of default values in the registers, such as fast charge being off. When you run Trickster Mod or Franco Kernel Updater and set fast charge to 1 or gamma to load a certain profile, what happens is that when you boot up, your system has to load the app which then executes a list of commands to set fast charge to be on and for the gamma profile selector to load a certain profile. By using init.d scripts, you're telling the system to execute the commands on boot without launching an app. Or if you're daring enough, go into the /sys folder and make the changes you want so that by default no script has to run.
It's not that I'm against 3rd party apps, but they do add a level of "bloat" to the system boot. To be able to manage as much of it in the OS is far more efficient.
I also get that jimv1983 doesn't need LED control or brightness curve controls, but I like them. Including them in the OS does't hurt him one bit because it's not an extra process running in the system. Nor does the Android OS need to create an extra process. Those same processes are already running. The only difference is the user has 0 control over them without using a 3rd party app.
What he's suggesting is like if you removed the ability to choose ringtones, notifications and all those selection menus or even volume control. The system doesn't save any processes. Those same options still exist, but you're just removing the checkboxes and pulldown menus and hiding it from the user.
On the same coin, Lightflow is using the sanctioned method of notification interception and the middleman approach is nigh seamless because it's a functionality built into the OS. It's a fine line that you're walking as far as distinguishing the two methods. You address it already, but I think you're not giving enough credit to the API. It's also not prone to be killed off.
I've generally found the way CM exposes stuff to the user to be powerful, but ugly and sometimes hacky. Their Quick Tile arrangment comes to mind especially.
Boot time being affected is a once in a blue moon event. I only ever reboot when something's acting up. It happens maybe twice a month at the most. I definitely had ROMs re-booting themselves far more often than that.
Last edited: