Related
I've figured out all apk files are really just zip files, but why am I not able to unzip the framework-res.apk file, edit the images within, then save it again without causing my phone to hang on boot?
Is there some step I am missing? I've tried rezipping with normal compression, store only, and only photoshopping and resaving a single image within the apk and still it fails.
How are images edited and updated? What am I missing?
I use apkmanager myself for most theming. You might look into it
Sent from my SCH-I500 using XDA App
An apk is a zip, but it's a *signed* zip
Sent from my SCH-I500 using XDA App
Here is the way I do it. I use 7zip to do this and I think it is the only program that can do it.
The way you can do it is to extract the drawable-hdpi folder within the framework-res.apk then do all your edits and save them with the exact same file names. Then you can go back into your framework-res.apk and drag and drop the drawable-hdpi folder back in and it will over write the original ones. Now just hit the Up (like to move up a directory) button until you see the message "framework-res.apk has been changed. Update it in the archive?" then click yes. Now you can put it on your phone without force closing. If you were just editing framework-res and it was not within another .zip file then you won't get that message and that is fine.
APK Manager.
You can use extract/zip (2/3) for image-only edits, but you need to decompile/compile (9/11) to mess with xml files.
Do *not* sign system apks (like framework-res.apk). Do sign other apks.
Btw, this is in the wrong forum.
(Next step: learn about the update.zip packaging script. Remember to name it something besides update.zip afterwards, because on the Fascinate we're installing everything through Clockwork, which should be the only file actually called update.zip.)
s44 said:
APK Manager.
You can use extract/zip (2/3) for image-only edits, but you need to decompile/compile (9/11) to mess with xml files.
Do *not* sign system apks (like framework-res.apk). Do sign other apks.
Click to expand...
Click to collapse
Oooh! I didn't know this app made xml's editable. That opens up a whole new set of theming fun. I can't wait to release my new theme. It should be well received (I hope)
Btw, this is in the wrong forum.
Click to expand...
Click to collapse
I considered putting this in Themes, but this was a theme development question, so here it ended up. If the Theme and Development forums ever hook up and have a few drinks, then spawn a sub-forum, Theme Development, I assure you it would have been a much easier decision to make
Thanks everyone for helping me out. My last time playing with a phone is an old WinMo 5 device. Anroid seems limiting in it's own ways (no dedicated theme files (can't update without losing the apk theme), but much better for customizing for a 'look' of the OS.
Here are the steps I followed to change the wallpaper on my Kindle. Credit for this goes to Josepho1997 for the guide for the original Kindle Fire: http://forum.xda-developers.com/showthread.php?t=1765044&highlight=wallpaper
Disclaimer:
The risk of a bricked device or bootloop exists. To my knowlege there is no way to create a back up yet which makes recovery even harder. I am not liable for any damaged devices. Proceed at your own risk.
Things You'll Need:
Rooted Kindle
File Browser like ES File Explorer
7-Zip
Changing the Wallpaper:
1. Using ES File Explorer go to: /system/framework and copy (do not move!) framework-res.apk to your SD card.
2. Plug your Kindle into the computer and move the framework-res.apk (from SD card) to your computer and make a back up copy.
3. Use 7-Zip to open the one you intend to modify
4. Browse to \res\raw
5. Find the wallpapers named hi_xxx_p.jpg and hi_xxx_l.jpg. (These are the 1280x800 images, p are portrait images and l are landscape images. I am unsure what purpose the other images of different resolutions serve at this time).
6. Replace the .jpgs with the images you want, keeping the names exactly as they are. DO NOT delete any images. (I recommend replacing each image with the same resolution image for the best results).
7. Close 7-Zip and the new framework-res.apk will be saved, move this back to your SD card.
8. Open ES File Explorer. In the settings make sure you select "Up To Root", "Root Explorer" and "Mount File System".
9. Copy the framework-res.apk to /system.
10. Change the permissions to rw-r-r using ES File Explorer (this is critical, failure will cause a bootloop)
11. Move framework-res.apk to /system/framework. Let it replace the other file.
12. Reboot.
13. You will see your new wallpaper(s) when your Kindle reboots. To tidy up, go back into ES File Explorer and uncheck "Mount File System".
These are the steps I followed successfully but I caution anyone as it is risky. Follow them carefully and if you are uncomfortable or cannot afford to brick your device please wait until someone has developed a safer, easier method.
You can delete all of images (it'd result in a black no-background), and you can also add new images. Differently prefixed images (which you may also notice are of diff resolution) are for other devices.
ignoramous said:
You can delete all of images (it'd result in a black no-background), and you can also add new images. Differently prefixed images (which you may also notice are of diff resolution) are for other devices.
Click to expand...
Click to collapse
If you add new images, you need to renamed them correctly. I think in the id.xml(maybe string.xml), they have the wallpaper's name. If you put in a different name, it wont work. And you could edit the id.xml(maybe string.xml, I forget) so that the name of the wallpapers match yours, but then you would have to properly uncompile it and then recompile it.
Android>iOS... Android FTW!
jst07 said:
9. Copy the framework-res.apk to /system.
10. Change the permissions to rw-r-r using ES File Explorer (this is critical, failure will cause a bootloop)
11. Move framework-res.apk to /system/framework. Let it replace the other file.
Click to expand...
Click to collapse
Although I should have been warned by the red text above I finally resulted in a bootloop when changing those permissions. I don´t know what exactly went wrong, but it did.
As this may have happened to someone else (apparently it did, as the warning shows): Is there a way out? The only thing to do is to change back the framework-res.apk file from a backup on desktop or even to flash the whole KFHD from an update file (which does contain this file also). Unfortunately the device is unknown to cmd, although adb seems to be properly configured...
Any suggestions?
nakedtruthishere said:
Although I should have been warned by the red text above I finally resulted in a bootloop when changing those permissions. I don´t know what exactly went wrong, but it did.
As this may have happened to someone else (apparently it did, as the warning shows): Is there a way out? The only thing to do is to change back the framework-res.apk file from a backup on desktop or even to flash the whole KFHD from an update file (which does contain this file also). Unfortunately the device is unknown to cmd, although adb seems to be properly configured...
Any suggestions?
Click to expand...
Click to collapse
Flashing system.img in fastboot is about the only way to recover these devices right now-
http://forum.xda-developers.com/showthread.php?t=1951254
onemeila said:
Flashing system.img in fastboot is about the only way to recover these devices right now-
http://forum.xda-developers.com/showthread.php?t=1951254
Click to expand...
Click to collapse
Unfortunately this tool doesn´t work for me - "waiting for device" is the only result.
ADB is on, but I´m not sure about fastboot with the original USB cable - although QemuRoot worked fine with that. How do I surely know that fastboot is on? While trying to start fastboot via cmd, it prompted some syntax info, nothing else happens - that´s it (?)
nakedtruthishere said:
Unfortunately this tool doesn´t work for me - "waiting for device" is the only result.
ADB is on, but I´m not sure about fastboot with the original USB cable - although QemuRoot worked fine with that. How do I surely know that fastboot is on? While trying to start fastboot via cmd, it prompted some syntax info, nothing else happens - that´s it (?)
Click to expand...
Click to collapse
The possible reason is your using the cable that came with the kindle and for you to flash the system.img file you will need the factory cable which is differnt from the one that came with your KFHD
Hope this helps
doriean said:
...to flash the system.img file you will need the factory cable
Click to expand...
Click to collapse
That´s, what I suspect, too. I ordered one already.
On the other side there must be a way with the OEM cable, as in my opinion rooting means access to the affected files as well. Qemuroot works well
With "nolock" and go locker its much easier to change the lock screen wall paper or not?
Gesendet von meinem KFTT mit Tapatalk
I got to change my wallpaper in my friend kindle fire, really nice, thank all.
Help!
jst07 said:
Here are the steps I followed to change the wallpaper on my Kindle. Credit for this goes to Josepho1997 for the guide for the original Kindle Fire: http://forum.xda-developers.com/showthread.php?t=1765044&highlight=wallpaper
Disclaimer:
The risk of a bricked device or bootloop exists. To my knowlege there is no way to create a back up yet which makes recovery even harder. I am not liable for any damaged devices. Proceed at your own risk.
Things You'll Need:
Rooted Kindle
File Browser like ES File Explorer
7-Zip
Changing the Wallpaper:
1. Using ES File Explorer go to: /system/framework and copy (do not move!) framework-res.apk to your SD card.
2. Plug your Kindle into the computer and move the framework-res.apk (from SD card) to your computer and make a back up copy.
3. Use 7-Zip to open the one you intend to modify
4. Browse to \res\raw
5. Find the wallpapers named hi_xxx_p.jpg and hi_xxx_l.jpg. (These are the 1280x800 images, p are portrait images and l are landscape images. I am unsure what purpose the other images of different resolutions serve at this time).
6. Replace the .jpgs with the images you want, keeping the names exactly as they are. DO NOT delete any images. (I recommend replacing each image with the same resolution image for the best results).
7. Close 7-Zip and the new framework-res.apk will be saved, move this back to your SD card.
8. Open ES File Explorer. In the settings make sure you select "Up To Root", "Root Explorer" and "Mount File System".
9. Copy the framework-res.apk to /system.
10. Change the permissions to rw-r-r using ES File Explorer (this is critical, failure will cause a bootloop)
11. Move framework-res.apk to /system/framework. Let it replace the other file.
12. Reboot.
13. You will see your new wallpaper(s) when your Kindle reboots. To tidy up, go back into ES File Explorer and uncheck "Mount File System".
These are the steps I followed successfully but I caution anyone as it is risky. Follow them carefully and if you are uncomfortable or cannot afford to brick your device please wait until someone has developed a safer, easier method.
Click to expand...
Click to collapse
Ok I did all of this but i am still getting the regular images, which doesnt make sence because if i open up the framework in system/framework folder all the images i replaced are there none of the originals. Did I do something wrong? I gave rw-r-r access I have Kindle Fire HD 7
Go Launcher EX and HD
Just out of interest, isn't installing Go Launcher and Go Locker a safer approach?
Both these applications do not require any movement to /system/apps
I guess if you like the Amazon Launcher, this is not a solution? I just try to keep
people away from any steps that may involve Bricking the device. These are
only thoughts. By the way, great tutorial, very informative and detailed.
jst07, Never mind, your solution eliminates the annoying double lock
screen. Great work jst07!
Best Regards, Chris Bryant (prokennexusa)
joedirt2013 said:
Ok I did all of this but i am still getting the regular images, which doesnt make sence because if i open up the framework in system/framework folder all the images i replaced are there none of the originals. Did I do something wrong? I gave rw-r-r access I have Kindle Fire HD 7
Click to expand...
Click to collapse
Same here. I also tried to 'reinstall' framework-res but it failed to reinstall.
Do not attempt this modification it is no longer valid
Slimepuppy said:
Same here. I also tried to 'reinstall' framework-res but it failed to reinstall.
Click to expand...
Click to collapse
Slimepuppy,
This post needs to be updated. This was written when the software version was 7.1.x, at that time
this worked great and he had a great idea - he still does. Unfortunately, it looks like the jst07 has
been too busy to keep up the post. It happens to the best of us! I would recommend to NOT make
these changes until one of us is able to post an updated version of this modification. In Software
version 7.2.1 and higher, which is a modified version of Ice Cream Sandwich, the names in the
folder \res\raw have changed to k2_xxx_p.jpg and k2_xxx_l.jpg - not hi_xxx_p.jpg and hi_xxx_l.jpg.
Having said this, you will not see any changes when you attempt to modify images that the Kindle
no longer uses. Our new Kindle Fire Toolkit will automate this dangerous modification. So be
warned DO NOT ATTEMPT THIS MODIFICATION IT IS NO LONGER VALID IN SOFTWARE 7.2.X
The following is a link to our new Backup and Recover software: http://forum.xda-developers.com/showthread.php?t=2096888
---------- Post added at 10:32 PM ---------- Previous post was at 10:27 PM ----------
joedirt2013 said:
Ok I did all of this but i am still getting the regular images, which doesnt make sence because if i open up the framework in system/framework folder all the images i replaced are there none of the originals. Did I do something wrong? I gave rw-r-r access I have Kindle Fire HD 7
Click to expand...
Click to collapse
joedirt2013,
This post needs to be updated. This was written when the software version was 7.1.x, at that time
this worked great and he had a great idea - he still does. Unfortunately, it looks like the jst07 has
been too busy to keep up the post. It happens to the best of us! I would recommend to NOT make
these changes until one of us is able to post an updated version of this modification. In Software
version 7.2.1 and higher, which is a modified version of Ice Cream Sandwich, the names in the
folder \res\raw have changed to k2_xxx_p.jpg and k2_xxx_l.jpg - not hi_xxx_p.jpg and hi_xxx_l.jpg.
Having said this, you will not see any changes when you attempt to modify images that the Kindle
no longer uses. Our new Kindle Fire Toolkit will automate this dangerous modification. So be
warned DO NOT ATTEMPT THIS MODIFICATION IT IS NO LONGER VALID IN SOFTWARE 7.2.X
The following is a link to our new Backup and Recover software: http://forum.xda-developers.com/show....php?t=2096888
prokennexusa said:
Slimepuppy,
This post needs to be updated. This was written when the software version was 7.1.x, at that time
this worked great and he had a great idea - he still does. Unfortunately, it looks like the jst07 has
been too busy to keep up the post. It happens to the best of us! I would recommend to NOT make
these changes until one of us is able to post an updated version of this modification. In Software
version 7.2.1 and higher, which is a modified version of Ice Cream Sandwich, the names in the
folder \res\raw have changed to k2_xxx_p.jpg and k2_xxx_l.jpg - not hi_xxx_p.jpg and hi_xxx_l.jpg.
Having said this, you will not see any changes when you attempt to modify images that the Kindle
no longer uses. Our new Kindle Fire Toolkit will automate this dangerous modification. So be
warned DO NOT ATTEMPT THIS MODIFICATION IT IS NO LONGER VALID IN SOFTWARE 7.2.X
The following is a link to our new Backup and Recover software: http://forum.xda-developers.com/showthread.php?t=2096888
---------- Post added at 10:32 PM ---------- Previous post was at 10:27 PM ----------
joedirt2013,
This post needs to be updated. This was written when the software version was 7.1.x, at that time
this worked great and he had a great idea - he still does. Unfortunately, it looks like the jst07 has
been too busy to keep up the post. It happens to the best of us! I would recommend to NOT make
these changes until one of us is able to post an updated version of this modification. In Software
version 7.2.1 and higher, which is a modified version of Ice Cream Sandwich, the names in the
folder \res\raw have changed to k2_xxx_p.jpg and k2_xxx_l.jpg - not hi_xxx_p.jpg and hi_xxx_l.jpg.
Having said this, you will not see any changes when you attempt to modify images that the Kindle
no longer uses. Our new Kindle Fire Toolkit will automate this dangerous modification. So be
warned DO NOT ATTEMPT THIS MODIFICATION IT IS NO LONGER VALID IN SOFTWARE 7.2.X
The following is a link to our new Backup and Recover software: http://forum.xda-developers.com/show....php?t=2096888
Click to expand...
Click to collapse
If the new images are named k2_xxx......, then you will just have to properly rename them to the appropriate name.
a.k.a. Urahara
The truth! I'm really a girl!
Change the Wallpaper
Jessica said:
If the new images are named k2_xxx......, then you will just have to properly rename them to the appropriate name.
a.k.a. Urahara
The truth! I'm really a girl!
Click to expand...
Click to collapse
Jessica,
Thank you Jessica, if it was that easy I would have said just that but it looks like Amazon has make changes to
the cabinet. I spent about 40 minutes to put it all together and I just did not have time to test it all. I saw one
person Brick there Kindle and another frustrated since it "was not working". I have been a Software developer
for over 25 years (Linux Unix AS400 & Windows) and a phone app developer since the first smart phone was
released. I am just VERY conservative when I make recommendations - I always test, test, and test. When I
know it works and safe, then I post the results. I have not had time tonight and did not want to see anyone
waste there time, so I posted the warning. Tomorrow when I am at the office, I will post the modification
after I have thoroughly tested the solution.
Jessica said:
If the new images are named k2_xxx......, then you will just have to properly rename them to the appropriate name.
a.k.a. Urahara
The truth! I'm really a girl!
Click to expand...
Click to collapse
Exactly. There is a set of images in the location specified for this method (framework-res.apk/res/raw) and they have the k2_xxx_l.jpg or K2_xxx_p.jpg name. I created a replacement pair of images, renamed them, and pushed them into the apk with 7zip on a PC.
The replacement images are in the framework-res.apk but after two reboots the Fire HD is still displaying the old image. (I only replaced one image in both portrait and landscape mode. One can quickly cycle through the lockscreen images by closing/opening the cover. I wonder if it's the magnetic catch or the light sensor that's triggering that?)
Maybe there's another set of images. This is just enough like Linux to be trouble - time to buy another book!
prokennexusa said:
<snip> I have not had time tonight and did not want to see anyone
waste there time, so I posted the warning. Tomorrow when I am at the office, I will post the modification
after I have thoroughly tested the solution.
Click to expand...
Click to collapse
Sounds great, Chris - thanks for being conscientious and methodical.
Andy
Slimepuppy said:
Exactly. There is a set of images in the location specified for this method (framework-res.apk/res/raw) and they have the k2_xxx_l.jpg or K2_xxx_p.jpg name. I created a replacement pair of images, renamed them, and pushed them into the apk with 7zip on a PC.
The replacement images are in the framework-res.apk but after two reboots the Fire HD is still displaying the old image. (I only replaced one image in both portrait and landscape mode. One can quickly cycle through the lockscreen images by closing/opening the cover. I wonder if it's the magnetic catch or the light sensor that's triggering that?)
Maybe there's another set of images. This is just enough like Linux to be trouble - time to buy another book!
Sounds great, Chris - thanks for being conscientious and methodical.
Andy
Click to expand...
Click to collapse
Well, that doesn't make any sense. I have done this with my 1st gen kindle(I made the original guide). The way it works(simplified) is it rotates throughout all of these pictures. If you replace the pictures, it shouldn't show them, as they're not there.
a.k.a. Urahara
The truth! I'm really a girl!
Follow Up - Feedback
Slimepuppy said:
Exactly. There is a set of images in the location specified for this method (framework-res.apk/res/raw) and they have the k2_xxx_l.jpg or K2_xxx_p.jpg name. I created a replacement pair of images, renamed them, and pushed them into the apk with 7zip on a PC.
The replacement images are in the framework-res.apk but after two reboots the Fire HD is still displaying the old image. (I only replaced one image in both portrait and landscape mode. One can quickly cycle through the lockscreen images by closing/opening the cover. I wonder if it's the magnetic catch or the light sensor that's triggering that?)
Maybe there's another set of images. This is just enough like Linux to be trouble - time to buy another book!
Sounds great, Chris - thanks for being conscientious and methodical.
Andy
Click to expand...
Click to collapse
Slimepuppy,
No worries Slimepuppy, I just did not want to see anyone damage there Kindle, so I felt - I had better post a quick
warning before another person waists 1 to 2 hours and finds there hard work has gone down the drain. We actuality
have an option to change the Wallpaper in our next software release:
http://forum.xda-developers.com/showthread.php?t=2096888
The solution is in our software manifest and will be added in version 4.2.4 - the feature will be allow you to make
a change on the fly, so to speak. Either way, I will post the changes tomorrow for the people who like to edit apk's
Jessica said:
Well, that doesn't make any sense. I have done this with my 1st gen kindle(I made the original guide). The way it works(simplified) is it rotates throughout all of these pictures. If you replace the pictures, it shouldn't show them, as they're not there.
a.k.a. Urahara
The truth! I'm really a girl!
Click to expand...
Click to collapse
Yes ma'am - had me scratching my head a bit as well. It was interesting that when I copied the updated framework-res.apk into the file system the the Kindle froze and then rebooted - didn't expect that.
Hmmm...seems there are a couple of different sets of images after all. The set in /res/raw are 1024x600 JPGs at 96 dpi. There's another set of images in /res/raw-hdpi and in /res/raw-land-hdpi. These little puppies are 1280x800 at 96 dpi. The high-res images use the name format xi_arhm.jpg (in both the portrait and landscape directories).
In the Fire HD 8.9, there's only four images in /res/raw and the lockscreen images are in /res/raw/raw-xlarge-land-hdpi/ and /res/raw/raw-xlarge-hdpi/ Filenames are the same in both - xi_arhm.jpg and the rest in xi_xxxx.jpg format. These images are 1920x1200 still at 96 dpi.
Tomorrow I'll change a couple and see what happens - it's been too many hours between now and coffee, and I try not to delete anything after midnight.
Andy
edit...
Ok, since I really didn't have to technically 'delete' anything... Placing the new pictures in the /res/raw-hdpi folders worked perfectly on the 7".
The odd sorta-lockup happened this time as well. Here's the rundown: the Fire's running 7.2.3 and is rooted, Google-app'd, and the OTA updates are defeated. ES File Explorer in root mode. Followed the direction precisely. On the last move - when framework-res.apk is put into the /system/framework/ directory, ES FileEx freezes. I can still highlight the back and home buttons - the machine's responding to the touch screen but there's no response beyond that. Tapping the power button results in an immediate boot screen - exactly as if the machine had powered down but forgot to tell the screen what happened. Once the machine's up, the new lockscreen wallpaper is visible. Any chance that the Fire's processing the framework-res.apk automatically?
Life is good!
Hi
I try to decompile SecSettings by apktool and i get this:
Code:
C:\apktool>apktool d secsettings.apk SecSettings23
I: Baksmaling...
I: Loading resource table...
Exception in thread "main" brut.androlib.AndrolibException: Multiple resources:
spec=0x7f020052 drawable/avatar_default_6, config=-hdpi
at brut.androlib.res.data.ResConfig.addResource(ResConfig.java:65)
at brut.androlib.res.data.ResConfig.addResource(ResConfig.java:58)
at brut.androlib.res.decoder.ARSCDecoder.readEntry(ARSCDecoder.java:196)
at brut.androlib.res.decoder.ARSCDecoder.readConfig(ARSCDecoder.java:165
)
at brut.androlib.res.decoder.ARSCDecoder.readType(ARSCDecoder.java:130)
at brut.androlib.res.decoder.ARSCDecoder.readPackage(ARSCDecoder.java:10
5)
at brut.androlib.res.decoder.ARSCDecoder.readTable(ARSCDecoder.java:82)
at brut.androlib.res.decoder.ARSCDecoder.decode(ARSCDecoder.java:48)
at brut.androlib.res.AndrolibResources.getResPackagesFromApk(AndrolibRes
ources.java:315)
at brut.androlib.res.AndrolibResources.loadMainPkg(AndrolibResources.jav
a:50)
at brut.androlib.res.AndrolibResources.getResTable(AndrolibResources.jav
a:43)
at brut.androlib.Androlib.getResTable(Androlib.java:44)
at brut.androlib.ApkDecoder.getResTable(ApkDecoder.java:148)
at brut.androlib.ApkDecoder.decode(ApkDecoder.java:98)
at brut.apktool.Main.cmdDecode(Main.java:128)
at brut.apktool.Main.main(Main.java:65)
What to do ??
Thanks
Please any help?
Same issue here
osherdadon said:
Please any help?
Click to expand...
Click to collapse
Using a Note 3 from T-Mobile, I pulled the file with the adb command, with root explorer, and extracted it from the stock ROM file all giving me the same error. For some reason I also don't get any smali files out of my SystemUI.apk which has been driving me crazy. I can't seem to find any working answers yet... Fail...
Basically bumping this thread a half a year later...
SOMEONE HELP US
You have the relevant frameworks installed and java in your path?
Learned a lot in 24 hours
DSA said:
You have the relevant frameworks installed and java in your path?
Click to expand...
Click to collapse
Summary/Lessons Learned in the last 24 hours:
I must have been too tired, went to sleep got up again and went at it. I realized a few things, main thing was deodexing, I learned all about that. Converting the .odex file to a class.dex file inside the SystemUI.apk and SecSettings.apk so decompiling would work properly (I was originally missing the smali folder without deodexing my app). Second I needed to pull all the framework files from my device instead of just the two I had, then I used "apktool if framework-res.apk" then "apktool if twframework-res.apk" then "apktool d SystemUI.apk" then "apktool d SecSettings.apk". This time it actually worked, I proceeded to try and re-compile them just to test. The SystemUI.apk worked flawlessly but the the SecSettings.apk had errors then I realized I needed to copy the AndroidManifest.xml and resources.arsc from the original app to the decompiled folder and the SecSettings.apk compiled with no issues. I had to get the original file out of the stock ROM, it had gotten damaged somehow with zipping/raring/7zipping so quicktip no one should be zipping the files you're about to work on get it fresh from the ROM.
Current Issue:
Now that all that's done I'm onto what I was trying to get at when I started this whole project. I need to modify both of these apps which are now perfectly deodexed and on my stock device. Every time I try to modify these files I lose my status bar and my settings stop working, I'm obviously breaking it, this is the XDA guide I was following.
Any help or redirection on where to post would be greatly appreciated, thanks
Easiest thing - put your mod back in and get the status bar to disappear/fc whatever
Then, pull a log (catalog from appstore works fine)
Post that log at pastebin and link it here
We won't be able to solve your issue without knowing what it is, in the first place
Like this?
This was before I restarted: Log 1
Then I recorded for a little after I restarted probably pointless but that's where the error would have been: Log 2
DSA said:
Easiest thing - put your mod back in and get the status bar to disappear/fc whatever
Then, pull a log (catalog from appstore works fine)
Post that log at pastebin and link it here
We won't be able to solve your issue without knowing what it is, in the first place
Click to expand...
Click to collapse
Not sure exactly how to record it and send it to you, I pressed record but when the phone finished rebooting CatLog was closed so I reopened it and it keeps scrolling endlessly.
Research progressed a little
I came across a post here in the Flashlight Mod development thread which made me realize I'm not getting the ID's correct. They suggest compiling the modded SystemUI.apk to get the ID's into the apk file under the /res/values/public.xml file, then decompiling it to read the ID values. I'm missing a step or doing something wrong, I can't replicate it to find the ID values I need so I can add them to the .smali file and recompile a final time. I'm sure this is the only reason for the missing status bar and the force closes. I guess I need help understanding, a different set of instructions or just more detailed?
I can't post in that thread yet so I'm getting my posts up over here, I already posted in the Q&A thread but no one has responded yet, any help is greatly appreciated!
I get this when decompiling the modded apk: Modded SystemUI ApkTool Decompile
All these errors look like the file is broken now or something, I'm just lost at this point. I tried ApkTool 1.5.2 and 2.0 as well.
EDIT:
Additional info below for troubleshooting purposes since it seems my issue recompiling at the end to get the values for my public.xml
STEPS:
1. deodex (universal deodexer v5)
2. decompile (apktool 1.5.2 & 2.0 separate tests)
3. modify (add flashlight .png's and .smali file from 4.4kk flashlight mod files)
4. recompile (apktool)
5. decompile (apktool)
=
Errors <<<<< These errors solved in edit below
EDIT:
I forgot to use "apktool if SystemUI.apk" when loading "framework-res.apk" & "twframework-res.apk" now I get through decompiling and recompiling like I thought I should be and I even located the values int he public.xml, replaced them in the .smali and everything went peachy. Only problem is I never get the status bar after I reboot, not really getting any FC's but the status bar, if my goal were to get it to be invisible I would be so happy omg lol If you're curious I've also tested by signing and even another test with zipalign, nothing zip/zero/zilch...
EDIT... Again I know still no sleep, durp durp:
So my main issue was not using apktool v1.5.2 to decompile and v2.0 to compile EVERY SINGLE TIME, NO EXCEPTIONS. When I followed that simple rule I get it onto my device and she has no status bar... Hmmmmm..... And a logcat for anyone smart enough to help me
EDIT:
Maybe I'm in the right direction with an error I saw in the log at this post? I thought it was so I installed the DisableSignatureVerification Mod from the Xposed Modules and still nothing.
Calling All Developers
It's been like 2 weeks just curious if anyone has even looked at this, I haven't been able to make any progress so I started learning how to develop apps. I made two small apps basic flashlight and a counter app but I really want to know why I'm totally unable to mod a file on my phone. I can't get the ink effect to work with finger input either I've been really trying to get this flashlight mod and the ink effect for months. If I could get pointed in the direction of a developer that can actually help me I don't see why I couldn't donate like $10 or $20 to the one who helps me. I'm on android 4.4.2 (NK3) on my Note 3 from T-Mobile.
Hey guys.
Having some difficulty here with modifying system APKs without leaving them 'corrupt'.
Specifically with SecSettings and SamsungCamera6.
Only looking to simply modify the qmg icons for the time being.
Ticklemyandroid didn't really want to know with SecSettings. Tried using apktool manually after installing the framework-res.apk and still doesn't seem quite right. Also tried apk multi took. Even went as far as simply trying to past the qmg files into the existing APK with winrar but that really broke things.
I believe my issue is partly that things aren't decompiling properly, but also that I'm a little unclear of the correct procedure to recompile them afterwards without any errors or corruption if tapping on them to install (I'm not actually trying to install them this way, but I'm looking to get to package conflicts rather than package corrupt).
Edit: NVM. Seems like some kind of protection to prevent you from modifying and installing said APKS
Has anyone else experienced this? I only have side-loaded books and was thinking of applying @Renate NST's mod for showing metadata for all books when I found that I couldn't get anything with a double-tap. I just get a black screen for a moment and then I'm back where I started. I'm going to have to download a B&N freebie to see if the function is working at all, I guess....
Edit: I can confirm. Even with a B&N book I get a black screen flash on double-tap in the Library. So...either the rooting process in NookManager is not quite right for this FW or something else I've done has rendered this function inoperable Now the "fun" begins.
some additional info and maybe a cause
It turns out there are small discrepancies in the file sizes of three jars often modified, two for NTMM, and one for USB audio microphone recording (and maybe other stuff). The MD5 checksums are different in all three cases between FW 1.2.1 and FW 1.2.2. These are:
android.policy.jar
services.jar
framework.jar
The differences must not be great since the device continues to function in the main, but the issue with needing to resign Opera Mobile and Tasker, along with this new failure of the Library double-tap function suggests all is not quite right "under the hood".
Once upon a time I patched framework.jar myself using files supplied by @Renate NST. I'm guessing I might be able to do that again with the file from the FW 1.2.2. The other two jars would require patching from whatever information can be gathered on the GitHub site where NTMM is documented. Not so sure about that {scratches head and looks woeful}.
The "good" news is that the devices are largely functional and if/when the FW 1.2.2 jars are correctly patched, they can just be copied over without restoring the device to out-of-the-box state and building up (again) from there.
Um... (scratches head).
Is it my Library app that we're talking about?
I don't remember anything else for getting metadata.
I did notice one bug, it will (rarely) not get metadata if the zip is corrupted with different info on the zip global and local headers.
The problem is with the underlying Android zip libraries.
If it's only a single book you can desktop unzip and rezip.
If something is flashing or crashing a logcat will tell us something.
---------- Post added at 07:24 PM ---------- Previous post was at 06:57 PM ----------
I put the latest version Library-1.13.apk up (in the signature).
I made it so that you could dismiss the details with a click (handy if you're using a Glow2 without any soft keys).
Renate NST said:
Um... (scratches head).
Is it my Library app that we're talking about?
I don't remember anything else for getting metadata.
Click to expand...
Click to collapse
No, and so if the patch you have in the 1.2.1 patches zip applies only to meta data showing in your Library app, then at least part of the issue is moot.
I'm in the process of running a back-up even as I type so I can swap out the patched jars for the originals from FW 1.2.2 (one-by-one) to see if that restores the double-tap function in the B&N Library. Probably all three jars should be repatched anyway, but at least this will tell me if I am on the right track.
As for the patching, it's clear what needs to be done with the framework.jar and the audio recording patch you supplied. I've been looking at the patches for NTMM at the GitHub site and those are pretty impenetrable for me. So far.
nmyshkin said:
I've been looking at the patches for NTMM at the GitHub site...
Click to expand...
Click to collapse
Link, please. I've never used or looked at this.
To compare jars, just apktool d them into separate directories and diff them.
You can easily see which classes are different and by looking at the smali exactly what the differences are.
Renate NST said:
Link, please. I've never used or looked at this.
Click to expand...
Click to collapse
https://github.com/doozan/NookTouchPatches
Renate NST said:
To compare jars, just apktool d them into separate directories and diff them.
You can easily see which classes are different and by looking at the smali exactly what the differences are.
Click to expand...
Click to collapse
Yes, I've done this with android.policy.jar from FW 1.2.1 and FW 1.2.2, but I don't see an immediate way to compare them. I come up empty on the "diff" command(?). If I could see the connection between the smali and the info at the NTMM GitHub I guess I might be able to text edit the smali by hand(?) and then recompile the jars? Is that too simple?
windiff is MS's graphical version of the Unix diff command.
You can get it here: https://www.microsoft.com/en-us/download/details.aspx?id=18546
It works on directories or files.
Code:
C:\>windiff thisdir thatdir
Renate NST said:
windiff is MS's graphical version of the Unix diff command.
You can get it here: https://www.microsoft.com/en-us/download/details.aspx?id=18546
It works on directories or files.
Code:
C:\>windiff thisdir thatdir
Click to expand...
Click to collapse
OK, got that. So a quick look at a few smali files from the two firmwares shows only a line number difference. I'm sure there's more as there are about 80 smali files in just android.policy.jar
There are probably more proficient approaches but it seems to me that if I were to compare the original 1.2.1 jars to the patched jars distributed with NookManager I would see the patches pretty clearly. Next, I would have to examine the same smali files in the 1.2.2 jars to find the correct insertion points for the patches. Maybe? Then using something like Notepad++, I do a cut and paste. When all the smali files from the 1.2.2 jars have been patched in the same way as those from 1.2.1, then I baksmali the lot and recompile the jar.
Yes?
It sounds tedious, but I can do tedious and there are only two jars to work on.
Edit: OK, so back at the GitHub for NTMM I examined the patches and made a list of the smali files mentioned in each. Presumably these are the only ones actually patched. That narrows it down a lot! There are only 4 files patched in android.policy.jar and 6 in services.jar
Oh, I'm finally beginning to get what this is all about.
I hadn't ever seen that doozan stuff.
Those patches are difficult because they are diff generated.
There are only two java source files.
The rest of the patches were manually done on smali files which don't seem to be on that GitHub.
It's silly that ModUtils is installed with a patch, you could just copy it over.
My 1.2.1 patches a bunch of stuff which could easily conflict with the doozan patches or even not conflict but make their patches not patch correctly.
They might even conflict with some changes in FW 1.2.2
Renate NST said:
Oh, I'm finally beginning to get what this is all about.
I hadn't ever seen that doozan stuff.
Those patches are difficult because they are diff generated.
There are only two java source files.
The rest of the patches were manually done on smali files which don't seem to be on that GitHub.
It's silly that ModUtils is installed with a patch, you could just copy it over.
My 1.2.1 patches a bunch of stuff which could easily conflict with the doozan patches or even not conflict but make their patches not patch correctly.
They might even conflict with some changes in FW 1.2.2
Click to expand...
Click to collapse
You've given me some good tools (hopefully used correctly) to help see what is going on. Here's what I think I've learned:
I compared the two jars (android.policy.jar and services.jar) from FW 1.2.1 and 1.2.2. They are not completely identical, but the smali files which are to be patched are identical. Next, just to be sure I was correctly interpreting what info I could glean from the GitHub, I compared the original 1.2.1 jars with the patched jars. The only differences were in the smali files I had anticipated.
Unless the situation is more complicated than I think (is that even possible?!), this leads me to conclude that the patched smali files from the 1.2.1 firmware could be copied/added to the 1.2.2 firmware and the lot recompiled (apktool b) to provide patched jars for the 1.2.2 installation of NTMM (from NookManager).
Does that sound right?
nmyshkin said:
Does that sound right?
Click to expand...
Click to collapse
That should do the job.
You still might have to dig down to fix your original problem.
Renate NST said:
That should do the job.
You still might have to dig down to fix your original problem.
Click to expand...
Click to collapse
As usual, you are so right.
I patched the 1.2.2 jars so that NTMM would run and that all seems to have gone OK. But after a hot swap, clearing cache and rebooting (which took an agonizingly long time!), I found no change in the behavior that got me started on this in the first place. Nor was there any difference in the ability to install the few apps that needed resigning before they would install. But...I learned something, and whatever other subtle differences there were in the jars, that is now moot as things are now all updated to 1.2.2
Except framework.jar was not, because I had been lazy and didn't want to repatch for AudioRecord, so I had used the jar from 1.2.1. Since my other work had "no effect" I decided to bite the bullet and patch the framework.jar from 1.2.2 for AudioRecord (your patch). That was, um, fun. And when all that was accomplished and I swapped out that jar and rebooted (another loooooong wait) I still did not have the "fix" for the original issue.
Isn't that interesting? Ugh. Maybe it's a kernal issue. I'm not going there because there are no kernals developed for 1.2.2 and none for even 1.2.1 that have what I want. So I'll keep my kernal for 1.1.5 which does everything I want and hope nothing else shows up wonky. Maybe someday I'll return to an old backup of 1.2.2 before the kernal change and see if that is the issue.
Meanwhile I have a set of patched jars for 1.2.2. Now I need to look at the patches for NTGAppsAttack and try to get those updated, just because.
Thanks for the lesson
Well, you say that a double tap causes action, but not the right action.
(Double tap is kind of unusual, it's usually short vs. long tap.)
If something is dying, it's there in the logcat.
Is an Intent being generated?
B&N uses com.bn.nook.shop.action.show.details
My Library app also covers that. You can try temporarily installing it.
B&N uses a truly goofy Intent style.
This would make it difficult to troubleshoot from the command line with am start -a
It could be that the B&N database is screwed up.
The Intent only tells you to query B&N for the metadata.
Renate NST said:
It could be that the B&N database is screwed up.
The Intent only tells you to query B&N for the metadata.
Click to expand...
Click to collapse
...or, it could be that what's left of my little grey cells are out to lunch
I'm sure if I were to search diligently in this forum I would find myself reminding people about the Law of Unintended Consequences and pointing out exactly this issue IF Shop.apk is disabled. I can now remember that clearly. But I didn't when I started on this wild goose chase
Still, a few new skills, some newly patched jars. Not a bad result overall
Just to clarify:
I meant that it queries on the device the B&N content provider, not over the network to B&N.
Still, you should have seen something on logcat.
Renate NST said:
Just to clarify:
I meant that it queries on the device the B&N content provider, not over the network to B&N.
Still, you should have seen something on logcat.
Click to expand...
Click to collapse
And I did. Something about a missing intent. I think that's what finally nudged my stuck memory loose. BTW, I did do a quick install of your Library prior to remembering about Shop.apk. It cured the "flash to black screen and back" for a double-tap in the B&N Library, resulting in only a suggestion of a screen flicker, but not the desired behavior. Thanks again for all your help.