Android OS Forum banner
Cancel

AOKP Backup Support Thread

Jump to Latest Follow
101 - 120 of 147 Posts
C

· Registered
Joined
·
13 Posts
#101 ·
unfortunately it does not work on aokp_maguro_jb-mr1_build-1

Code: 
 <br />
-------- beginning of /dev/log/main<br />
I/dalvikvm(16268): Turning on JNI app bug workarounds for target SDK version 11...<br />
E/Trace   (16268): error opening trace file: No such file or directory (2)<br />
D/dalvikvm(16268): GC_CONCURRENT freed 41K, 9% free 2744K/3004K, paused 46ms+12ms, total 86ms<br />
D/dalvikvm(16268): GC_FOR_ALLOC freed 19K, 8% free 2815K/3060K, paused 12ms, total 12ms<br />
I/dalvikvm-heap(16268): Grow heap (frag case) to 5.853MB for 3032656-byte allocation<br />
D/dalvikvm(16268): GC_FOR_ALLOC freed <1K, 5% free 5776K/6024K, paused 14ms, total 14ms<br />
D/dalvikvm(16268): GC_CONCURRENT freed <1K, 5% free 5775K/6024K, paused 1ms+21ms, total 30ms<br />
D/dalvikvm(16268): GC_FOR_ALLOC freed <1K, 5% free 5877K/6124K, paused 16ms, total 16ms<br />
D/dalvikvm(16268): GC_CONCURRENT freed <1K, 4% free 6977K/7228K, paused 2ms+7ms, total 29ms<br />
W/asset   (16268): deep redirect failure from 0x01030046 => 0x0207000c, defStyleAttr=0x01010084, defStyleRes=0x0103008f, style=0x00000000<br />
W/asset   (16268): deep redirect failure from 0x01030046 => 0x0207000c, defStyleAttr=0x01010084, defStyleRes=0x0103008f, style=0x00000000<br />
W/asset   (16268): deep redirect failure from 0x01030046 => 0x0207000c, defStyleAttr=0x01010084, defStyleRes=0x0103008f, style=0x00000000<br />
W/asset   (16268): deep redirect failure from 0x01030046 => 0x0207000c, defStyleAttr=0x01010084, defStyleRes=0x0103008f, style=0x00000000<br />
D/dalvikvm(16268): GC_CONCURRENT freed 83K, 4% free 8335K/8652K, paused 19ms+3ms, total 31ms<br />
D/dalvikvm(16268): WAIT_FOR_CONCURRENT_GC blocked 6ms<br />
D/dalvikvm(16268): GC_FOR_ALLOC freed 487K, 8% free 9614K/10404K, paused 15ms, total 16ms<br />
W/asset   (16268): deep redirect failure from 0x01030046 => 0x0207000c, defStyleAttr=0x01010084, defStyleRes=0x0103008f, style=0x00000000<br />
W/asset   (16268): deep redirect failure from 0x01030046 => 0x0207000c, defStyleAttr=0x01010084, defStyleRes=0x0103008f, style=0x00000000<br />
 
T

· Android Freak
Joined
·
1,403 Posts
#102 ·
Hey so I've seen that AOKP Backup has been discontinued, and I can't express how sad that makes me. This app is a lifesaver, it makes flashing new nightlies so incredibly easy. I'm not sure why the decision was made to discontinue it, but I'd be willing to donate to anyone who can get this app back up and running. I love AOKP, but I need my backup program.
 
Lanmonster

· Codemonkey In Training
Joined
·
276 Posts
#103 ·
If ROM control was a user app, Titanium backup could do the work for us. When something is changed in RC (feature added, etc.) it could work just like any market app. Not sure if this would work, but it seems like it could.
 
Save Share
Reply Quote
J

· Premium Member
Joined
·
3,316 Posts
#104 ·
Lanmonster said:
If ROM control was a user app, Titanium backup could do the work for us. When something is changed in RC (feature added, etc.) it could work just like any market app. Not sure if this would work, but it seems like it could.
Click to expand...
Wut.
 
Zaphod-Beeblebrox

· Premium Member
Joined
·
1,662 Posts
#110 ·
Lanmonster said:
dang...made sense in my head
Click to expand...
OK. A little explanation here. Every app has access to a SharedPreferences library (misleading name - its only accessible by THAT app, not shared amongst other apps - but the library, or API is shared :))

So ROMControl can and *does* store its values in the associated SharedPreferences storage. This is the data that would be backed up by Tibu, or any other traditional backup app.

However, remember above where I said that other apps couldn't gain access to that storage? So how would SystemUI, or the lockscreen gain access to RomControl settings to know what the options are?

There is a global System.Settings storage (your system settings) that depending on the particular settings & permissions of the fields, can be read by any app. For every field in RomControl, we have to define a corresponding field in System.Settings. As values are changed in RomControl, we replicate them in the System.Settings. In reality, the values stored in RomControls SharedPreferences don't even need to be there. The real data is always stored in System.Settings. But since the Preference API & components automatically store data in the SharedPrefs storage, we just ignore it.

So, even if RC was moved out of system and you backed up its data, without replicating that data to System.Settings, it would do no good.

The reason AOKPBackup was dropped is that it required Roman to modify/re-write it every time we released a new build (any new fields in System.Settings had to be accounted for). Having time to do this, as well as the time to do it IMMEDIATELY with the release of any build wasn't possible for him to keep up with. Catching up on a release a week or two after the fact doesn't really help anyone.
 
T

· Android Freak
Joined
·
1,403 Posts
#114 ·
Zaphod-Beeblebrox said:
OK. A little explanation here. Every app has access to a SharedPreferences library (misleading name - its only accessible by THAT app, not shared amongst other apps - but the library, or API is shared :))

So ROMControl can and *does* store its values in the associated SharedPreferences storage. This is the data that would be backed up by Tibu, or any other traditional backup app.

However, remember above where I said that other apps couldn't gain access to that storage? So how would SystemUI, or the lockscreen gain access to RomControl settings to know what the options are?

There is a global System.Settings storage (your system settings) that depending on the particular settings & permissions of the fields, can be read by any app. For every field in RomControl, we have to define a corresponding field in System.Settings. As values are changed in RomControl, we replicate them in the System.Settings. In reality, the values stored in RomControls SharedPreferences don't even need to be there. The real data is always stored in System.Settings. But since the Preference API & components automatically store data in the SharedPrefs storage, we just ignore it.

So, even if RC was moved out of system and you backed up its data, without replicating that data to System.Settings, it would do no good.

The reason AOKPBackup was dropped is that it required Roman to modify/re-write it every time we released a new build (any new fields in System.Settings had to be accounted for). Having time to do this, as well as the time to do it IMMEDIATELY with the release of any build wasn't possible for him to keep up with. Catching up on a release a week or two after the fact doesn't really help anyone.
Click to expand...
ok I can understand that. I'm sure creating the ROMs in the first place is time consuming enough. I still can't help wishing for some kind of backup option. I love AOKP, but I don't want flashing a new build to take up a huge chunk of my time because i have to restore all the settings. would it be easier for you guys to maybe bake the feature directly into the ROM? or would that be even more difficult?
 
Zaphod-Beeblebrox

· Premium Member
Joined
·
1,662 Posts
#115 ·
TenderloinShadow said:
ok I can understand that. I'm sure creating the ROMs in the first place is time consuming enough. I still can't help wishing for some kind of backup option. I love AOKP, but I don't want flashing a new build to take up a huge chunk of my time because i have to restore all the settings. would it be easier for you guys to maybe bake the feature directly into the ROM? or would that be even more difficult?
Click to expand...
I am hopeful that Roman will eventually resurrect AOKPBackup. He's been very busy with school lately (one of the reasons he took it off the market). Once he finds a little time to work on it, we may be able to structure the app such that it doesn't need to be updated for every build. Not sure we/he can pull that off, but that's my hope anyway.

As for wiping & backing up, I'm going to 'unofficially' tell you that dirty flashing should work the majority of the time. Most of us 'dev types' dirty flash back and forth between test code and official code all the time. I've not wiped my phone in several months.

Now 'Officially', we will not address any issues/problems until you've done the full wipe/clean flash dance, but that doesn't mean you shouldn't do a backup and try it :)
 
M

· Android Beginner
Joined
·
62 Posts
#116 ·
Zaphod-Beeblebrox said:
OK. A little explanation here. Every app has access to a SharedPreferences library (misleading name - its only accessible by THAT app, not shared amongst other apps - but the library, or API is shared :))

So ROMControl can and *does* store its values in the associated SharedPreferences storage. This is the data that would be backed up by Tibu, or any other traditional backup app.

However, remember above where I said that other apps couldn't gain access to that storage? So how would SystemUI, or the lockscreen gain access to RomControl settings to know what the options are?

There is a global System.Settings storage (your system settings) that depending on the particular settings & permissions of the fields, can be read by any app. For every field in RomControl, we have to define a corresponding field in System.Settings. As values are changed in RomControl, we replicate them in the System.Settings. In reality, the values stored in RomControls SharedPreferences don't even need to be there. The real data is always stored in System.Settings. But since the Preference API & components automatically store data in the SharedPrefs storage, we just ignore it.

So, even if RC was moved out of system and you backed up its data, without replicating that data to System.Settings, it would do no good.

The reason AOKPBackup was dropped is that it required Roman to modify/re-write it every time we released a new build (any new fields in System.Settings had to be accounted for). Having time to do this, as well as the time to do it IMMEDIATELY with the release of any build wasn't possible for him to keep up with. Catching up on a release a week or two after the fact doesn't really help anyone.
Click to expand...
would it be possible write some code that would read the shared preferences, compare them to their various system settings counterpart and if the results vary, replace the system info with shared settings info (the same way the app works regularly?).

Or, if its not possible to access the shared settings externally, have Rom Control save any changes to another location, that could be read?

#NotACoder
 
akellar

· Premium Member
Joined
·
3,730 Posts
#117 ·
machiz7888 said:
would it be possible write some code that would read the shared preferences, compare them to their various system settings counterpart and if the results vary, replace the system info with shared settings info (the same way the app works regularly?).

Or, if its not possible to access the shared settings externally, have Rom Control save any changes to another location, that could be read?

#NotACoder
Click to expand...
Pretty sure you just described the basic idea of AOKPBackup
 
S

· Registered
Joined
·
114 Posts
#118 ·
akellar said:
Pretty sure you just described the basic idea of AOKPBackup
Click to expand...
It sounds like the issue is figuring out what to backup and what to ignore. The System.settings is just a lookup table, so I would assume it is easy to iterate through it. So I am guessing the difficulty is determining what is important?

Instead of trying to keep track of all the new additions (which there will generally always be some, which it sounds like is why maintainence is such a drag) wouldn't it be easier to instead track the system settings you need to ignore? Maybe that would result in a shorter more static list?
 
101 - 120 of 147 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
About this Discussion
146 Replies
68 Participants
Last post:
espmartin
Android OS Forum
A forum community dedicated to Android phone owners and enthusiasts. Come join the discussion about applications, recovery, developments, styles, reviews, accessories, classifieds, and more for Unbuntu, Google Nexus, HTC, Motorola, Samsung or other Android models!
Full Forum Listing
Explore Our Forums
Galaxy Nexus AOKP Android Android Applications Developer / Themer Chat
Top