Backup/Restore not working properly

[jmo707]

The behavior I expect from Backup/Restore is to be able to make "a copy" of the actual system settings setted with the program. Furthermore, it should make doing and identifiyng multiple copies easy, which AKC does.

With 2.2.0 beta2 the program won't even save this settings. With 2.2.0 beta3 it seems to save them in separate files with a date stamp on them. But trying to restore any of them starts with an advertence about the need to Reboot to restore some settings. Then it seems that no value was changed accross the program, and Rebooting won't change that. In the com.aero.control folder there are folders created for each backup, but with no file in them.

[Blechd0se]

Thank you for your report. Just to clarify this; the backup/restore option is strictly limited to kernel backups and restores. This should never actually touch settings in Aero Control. You can however, save your settings inside a profile and export it. Later on, you can import it if desired. That explains that no values are restored after a restore.
The no-file-thing sounds suspicious though. I need to check this carefully again.

[jmo707]

Oh, that would explain it... I'm still thrilled by the way settings are stored. I've checked them, in order to have them defined for my actual profile, but even after rebooting those are kept unchanged, but with the check mark on them. In 2.1.2 sometimes they where saved and restored after a reboot, sometimes they won't. About the profiles: aren't they for specific apps? When I create a profile, it reads in red: "PerApp: No esta activo" (Isn't active) and even if I change a value in, lets say, Memory management, it won't show it on the General view when I click on it.

[Blechd0se]

The whole "workflow" might not be clear, i explain it quickly; when you start to fiddle with Aero Cotnrol you tend to check that checkbox near elements (you want to keep certain settings after a reboot). In the profile section, you can create a snapshot of your currently checked elements. That's a profile then and at this point, there is no dependency to apps. Its just profile you can manually apply if you wish so.
Per-App Profiles start on top of that. You can assign certain apps to certain profiles, so that you can have your favorite settings for your favorite apps only (e.g. only for that app session). You can still apply those profiles manually or import/export them. If you don't apply a profile, it wont be set automatically. So if you imported a profile, it won't be applied automatically. The little indicator (Per-App: Not active) just gives you a quick glance that a profile is also assigned to a app[s].

I hope this clarified the behavior a little bit. I might admit that the whole process is a bit tricky, that's because of the historically grown app (Aero Control is already 2 years old). I might need to redesign this at some point.

[jmo707]

Well, maybe it's not a Profiles issue. But I've tried with them too, on a PerApp basis, and still, even showing the toast message saying that the profile I saved is being applied, the values won't change =|
Might it be some permissions bug?

[Blechd0se]

Can you send me your profile(s)? Your exported profile should be stored under /sdcard/com.aero.control/profiles
You can upload the content here directly or over at http://pastebin.com/

How do you make sure, that the settings won't apply?

[jmo707]

I've checked it with other applications (Adiutor, ROM Toolbox) and within the values showed on the very AKC. Here is the profile:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="/sys/block/mmcblk0/queue/iosched/async_read_expire">390</string> <string name="/sys/devices/system/cpu/cpufreq/boosted/ramp_down_step">0</string> <string name="boot_delay">0</string> <string name="writeback">1</string> <string name="/sys/devices/system/cpu/cpufreq/boosted/sleep_ideal_freq">700000</string> <string name="set_governor">interactive</string> <string name="/sys/devices/system/cpu/cpufreq/boosted/sleep_wakeup_freq">900000</string> <string name="dynFsync">0</string> <string name="/sys/block/mmcblk0/queue/iosched/fifo_batch">8</string> <string name="/sys/block/mmcblk0/queue/iosched/sync_write_expire">1500</string> <string name="/sys/devices/system/cpu/cpufreq/boosted/awake_ideal_freq">700000</string> <boolean name="per_app_monitor" value="false" /> <string name="/sys/block/mmcblk0/queue/iosched/async_write_expire">3906</string> <string name="entropy_settings">[echo 1024 &gt; /proc/sys/kernel/random/write_wakeup_threshold, echo 512 &gt; /proc/sys/kernel/random/read_wakeup_threshold]</string> <string name="/sys/devices/system/cpu/cpufreq/boosted/max_cpu_load">75</string> <string name="/sys/devices/system/cpu/cpufreq/boosted/ramp_up_step">0</string> <string name="read_ahead">2048</string> <string name="/sys/block/mmcblk0/queue/iosched/sync_read_expire">150</string> <boolean name="per_app_service" value="false" /> <string name="ksm">1</string> <string name="gpu_control_enable">0</string> <string name="max_frequency">1300000</string> <string name="/sys/devices/system/cpu/cpufreq/boosted/down_rate_us">50000</string> <string name="io_scheduler_list">sio</string> <string name="/sys/devices/system/cpu/cpufreq/boosted/up_rate_us">50000</string> <string name="/sys/devices/system/cpu/cpufreq/boosted/min_cpu_load">35</string> <string name="/sys/block/mmcblk0/queue/iosched/writes_starved">3</string> <string name="min_frequency">700000</string> </map>

[Blechd0se]

Thanks!
I reworked the logic behind certain operations. I hope your bug is fixed now, if you are feeling brave enough, you can test the following debug version;
http://blechdose-live.de/download/kernel/aero/debug/