[Defy Android Development] Blechd0se:
Thank you very much for your feedback, its highly appreciated!

The problem for the profiles is the sorting process for the UI. It takes too long and obviously it scales up if you have more apps

installed. Currently i am not sure if my code is derping or the way i am getting this information.

About your ideas;

1.) Not a very good approach, since then i have to handle much more things and reading directly from /data instead of getting

androids meta information could cause potential issues. Btw. aero control already caches the data internally since 1.4.2.

It loads the sorted app list only once and populates it to each profile available which saves a few seconds.

2.) That's actually a thing i thought myself. Currently i read the data as soon as the profiles panel is created (to show this "Active/

Non Active"-State), but that's pointless. Like you said it should only read this data if the user actually clicks on the small icon.

It doesn't solve the problem completely, but its probably the right way anyway :)

Each Aero Control release is tested on my 4 devices before i push it to Google Play (Defy, Nexus 4, Nexus 7, Moto G). Each

running a different configuration to find all bugs.

The thing that would interest me is rather do you want to wait longer until a new major release gets pushed (like 1.3, 1.4, 2.0, ..)

or do you want to get those little fixes and small features in a faster circle like now seen on 1.4.1, 1.4.2?

Of course i can publish some of the google play data here, since i want this to be open as possible. Checkout the attached image

which shows the current installs with Defy leading the charts.

Thank you very much for your input, highly appreciated and nice suggestions.

1.) That's actually something in kernel space. Since i have no device where the kernel could allow such idle control,

i simply couldn't test it nor do i know the syspath of it. On each release i am adding new sysfs entries, but i simply can't

cover all especially not those that i don't know.

If you know the right path and/or the values it can take i can implement it :)

2.) Could you elaborate this a bit more? Do you mean some scenario like; set-on-boot is enabled, user decides to undervolt ->

system crashes due to too much uv -> system boots and crashes again due to wrong values?

If so, i already thought about that myself and its definitely a thing where i will make Aero Control smarter to be able to prevent

something like this

3.) Sounds good, but same as answer 1.) If i don't know the path, i can't implement it. Aero Control shouldn't be the tool

to configure each kernel out there (that's not possible by any means). It should control kernels branded by Aero Kernel or

Kernels which are close to Aero Kernel.

Anyway, i guess with EXT4 you mean the filesystem features? That's something i can look into as well as the scheduler parameters.

4.) I just like it :p

5.) Sounds like a great additions, although i have to take care of all icons more intelligently :)

Quite long post, but i want to take care of this and i also want to show that i care about your opinion. OpenSource doesn't

only mean that you can contribute code, but also your ideas and improvements.

Although i am not sure when i can work more on it, i had an car accident on friday and feeling a bit fuzzy (i am fine otherwise,

just can't move much, that's why i can write a lot). :)