Android OS Forum banner
101 - 120 of 147 Posts

·
Registered
Joined
·
13 Posts
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 />
 

·
Android Freak
Joined
·
1,406 Posts
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.
 

·
Codemonkey In Training
Joined
·
276 Posts
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.
 

·
Premium Member
Joined
·
3,386 Posts
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.
Wut.
 

·
Codemonkey In Training
Joined
·
276 Posts
instead of RC being a system app, could it be a market app?
 

·
Android Freak
Joined
·
1,406 Posts
not how it works, that's like asking for settings to be a market app

Sent from my Galaxy Nexus using RootzWiki
even if it is just a system app, the titanium idea would at least be something. why was this app pulled in the first place?
 

·
Premium Member
Joined
·
1,812 Posts
dang...made sense in my head
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.
 

·
Android Apprentice
Joined
·
179 Posts
Weird, AOKP backup has been working perfectly for a few months now. No lock screen targets, but the rest is perfect.

Sent from my XT912 using Tapatalk 2
 

·
Android Freak
Joined
·
1,406 Posts
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.
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?
 

·
Premium Member
Joined
·
1,812 Posts
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?
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 :)
 

·
Android Beginner
Joined
·
82 Posts
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.
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
 

·
Premium Member
Joined
·
3,873 Posts
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
Pretty sure you just described the basic idea of AOKPBackup
 

·
Registered
Joined
·
114 Posts
Pretty sure you just described the basic idea of AOKPBackup
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?
 

·
Registered
Joined
·
114 Posts
Did the app just re-appear in the play store? I think I just bought it!

Does that mean we are "on" again? Does it work with current nightly builds?
 

·
News Team
Joined
·
1,390 Posts
Did the app just re-appear in the play store? I think I just bought it!

Does that mean we are "on" again? Does it work with current nightly builds?
Not sure about "on again" but the app has been updated to backup ribbon settings.

Sent from my Galaxy Nexus
 
101 - 120 of 147 Posts
Top