[Q] V - Bootloops with modded framework-res.apk usual fixes not helping
- Thread starter shockwaverider
- Start date
Just a stupid question... How does adb trigger a reboot? If we can still use the reboot command in terminal emulator, would some kind of workaround be possible using whatever activity that command uses? Sorry if this is a completely ridiculous suggestion, I admit I have no idea what I'm talking about, but this is the only thing that comes to mind for me.
Sent from my LT25i using xda premium
So I've finally posted something about this in the apktool thread. I'm assuming that nobody's yet had any success with this?
Just a stupid question... How does adb trigger a reboot? If we can still use the reboot command in terminal emulator, would some kind of workaround be possible using whatever activity that command uses? Sorry if this is a completely ridiculous suggestion, I admit I have no idea what I'm talking about, but this is the only thing that comes to mind for me.
Sent from my LT25i using xda premium
That would be possible but.. I think its a "crude" way to do it :/ because intsead you could just add a script shortcut to your homescreen and press it everytime you want to reboot
Yeah, I figured it would be a pretty dirty workaround to do something like that, but then my knowledge is pretty limited, so I threw it out there.
Oh well.Sent from my LT25i using xda premium
--deleted--
The shutdown files were moved to services.jar in the jb update :banghead:
I will update it asap
Still, too bad we cant edit main framework yet..
The shutdown files were moved to services.jar in the jb update :banghead:
I will update it asap
Man, you're making it hard to stay on ICS!
I'll probably jump over to JB now that you've got this and the lidroid mod worked out. Still hoping that someone cracks the code on this framework problem. I don't know enough to even make an educated guess.
Sent from my LT25i using xda premium
Attached is the logcat I get when pushing framework-res. If someone who knows more than me wants to take a look at it, great.
Hmm. Bad zip. What did you use to add your changes to the original zip? Winrar or something else?
---------- Post added at 08:24 PM ---------- Previous post was at 08:13 PM ----------
Maybe the same problem? Duplicate entry? Somewhere, something.
https://groups.google.com/forum/m/?fromgroups#!topic/android-developers/nrl9mKjZCrs
---------- Post added at 08:24 PM ---------- Previous post was at 08:13 PM ----------
Maybe the same problem? Duplicate entry? Somewhere, something.
https://groups.google.com/forum/m/?fromgroups#!topic/android-developers/nrl9mKjZCrs
I've always used winrar. I suppose I can try with 7zip and see what happens.
I'll follow up with that link tomorrow when I'm hopefully not so tired, thanks for that. I've also got some suggestions to try out from the apktool thread, so hopefully this is on its way to being solved. But again, I won't be able to do anything until tomorrow evening.
Sent from my LT25i using xda premium
If it is any consolation, I am working on a CM10 ROM port and have run into similar problems after making a simple change to /system/framework/framework-res.apk: Phone hangs at boot animation. I haven't tried recompiling without changes, but I imagine the outcome would be the same.
I am using Virtuous Ten Studio, 7-zip and CSigner.
CSigner yields no errors except it doesn't zipalign because it claims that it can't find ADB --- even with ADB in PATH and/or inside the CSigner directory.
Anyway, I wonder if it is necessary to build framework-res.apk from scratch...?
[UPDATE]: A potential option is to use overlays to modify the framework-res.apk configuration: http://xdaforums.com/showthread.php?t=2017043.
Here's a quote: "It is in the source code tree, and is a much cleaner method for altering framework resources at runtime than the procedure others have been using of decompiling, editing and re-building, imo. "
I am using Virtuous Ten Studio, 7-zip and CSigner.
CSigner yields no errors except it doesn't zipalign because it claims that it can't find ADB --- even with ADB in PATH and/or inside the CSigner directory.
Anyway, I wonder if it is necessary to build framework-res.apk from scratch...?
[UPDATE]: A potential option is to use overlays to modify the framework-res.apk configuration: http://xdaforums.com/showthread.php?t=2017043.
Here's a quote: "It is in the source code tree, and is a much cleaner method for altering framework resources at runtime than the procedure others have been using of decompiling, editing and re-building, imo. "
Last edited:
Indulge a noob here... If I understood correctly, that method overrides framework-res.apk's resources.arsc? In other words, this is basically in lieu of modding xml's in the res/values folder? Or can it be used to override anything, anywhere in framework-res? I'm all over this if it works, especially if the "traditional" methods don't work, but I'm trying to get my head around how, for example, to use this to "edit" styles.xml, which has a lot of identical entries. From what I took away from the thread you linked to, everything gets dumped into config.xml, with no structure a la res/values. Or am I missing something?
And then a bit of a status update: As suggested in the apktool thread (and as I should have thought to do anyway), I diffed the public.xml from the original framework-res.apk and my rebuilt version. Every single id value in it is different. Specifically, every value in the original begins 0x010xxxxx, whereas in the recompiled version every one starts 0x030xxxxx. Here's where my noobness comes in again (and yes, I will google it) - I honestly don't know enough about how public.xml is built during compile to know if this is out of the ordinary. I do know that when I did the same thing with SystemUI.apk just to see what would happen, the diff showed identical files. So there's that, hopefully it's potentially useful. I haven't checked back in on the apktool thread with this, that's my next stop.
Last edited:
That's what I figured, but I wanted somebody smarter than me to say it first!
And confirmed in the apktool thread:
Guess it's time to start using those workarounds.
Last edited:
Yeah, just out of curiosity I fed the resources.arsc from an original/untouched and from a decompiled/recompiled (otherwise unmodified) framework-res into vbindiff and as expected, basically the whole window was red. Even assuming that public.xml is the only thing getting corrupted (I suppose it wouldn't be a bad idea to go through and diff everything in /res/values just to be sure), is there any way to isolate and somehow patch that part of the hex code into resources.arsc?
(edited because I'm stupid!
)
Last edited:
OK, I read up a bit on the thread that sendust7 linked to, which in turn links to another thread HERE. It seems like it may be a workaround for the problem we're having, but I'm not all that confident in my ability to get it working without a little bit of feedback about potential problems. To that end I've posted the following in that thread:
I guess the main thing to do is just to do it, so I'm going to take a crack at it as soon as I can, but if anyone here cares to point out whatever flaws they spot, that would be helpful as well!
I guess the main thing to do is just to do it, so I'm going to take a crack at it as soon as I can, but if anyone here cares to point out whatever flaws they spot, that would be helpful as well!
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
2Attached is the logcat I get when pushing framework-res. If someone who knows more than me wants to take a look at it, great.1I know that there are already several thousand threads on forums spanning the internet involving recompiled framework-res.apk's causing bootloops, but the ones that are actually useful pretty much all say the same thing, that is to replace the meta-inf folder and AndroidManifest.xml from the newly built apk with the ones from the original file. Needless to say, that hasn't worked in my case, and neither has changing from apk-manager (wanam's latest version) to using command line apktool or from using flashable zips to adb pushing the file to /system/framework. Primary and secondary frameworks are both installed. The apk decompiles and recompiles without errors. SystemUI.apk, the only other apk I've worked on thus far, flashes without issues. I don't have a lot of experience with adb, and right now I can't remember the exact error it gave me, "protocol error" perhaps? Firmware is deodexed 9.0.1.D.0.10 / Nordic "SuperSport".
Quite probably I'm doing or not doing something really basic that will make me look and feel foolish once this is resolved, but I'm out of ideas and I just want to start modding some 9.png's. Does anyone have any suggestions?1Sv: [Q] V - Bootloops with modded framework-res.apk usual fixes not helping
Try the framework-res from here and let me know
http://xdaforums.com/showthread.php?p=365032381
True. The jump from GB to ICS was a huge PITA for me, and I'm somewhat dreading upgrading to JB, as far as theming goes.
I finally just found this version of APK Manager in my DropBox, it's the one I used for months without problems but couldn't find it before because I stuck it in the wrong folder when I changed computers recently. Nuri, if you want to try it go ahead, I'm at work now and won't be able to do anything with it for at least another 12 hours, and possibly not until this weekend. I know it's a long shot, but it can't hurt to try.
EDIT: I also found this in the Xperia T/V/whatever Apps & Themes forum in the "[MOD] Reduced size onscreen buttons" thread, basically that another user (with a different device?) solved his bootloops by replacing the resources.arsc in his rebuilt apk with the original. I haven't followed that up because to be honest, that's only mildly useful for me as I tend to do a lot of modifications in /values/styles.xml as well as in other values files, so of course I need to be able to use the rebuilt resources.arsc. But for anyone not doing any edits in values, this may be enough of a workaround to get a working framework-res.1
That's what I figured, but I wanted somebody smarter than me to say it first!
And confirmed in the apktool thread:
Guess it's time to start using those workarounds.
