Related
I know many of us are new to the whole rooting thing. I'm coming from the Windows Mobile world of custom ROMs, kitchens, etc., but I do have some linux experience. However, I can't for the life of me figure out how to do a lot of what comes "standard" in MoDaCo's ROM. Obviously it would be easier to simply install Paul's ROM and be done with it, but I'd really like to learn how to do it on my own too.
So, that being said, maybe we can pull together some tutorials, guides, and/or links to existing guides which explain how to go about setting up our Rooted phones manually. Here are some of the built-in mods the MoDaCo ROM comes with which would be nice to be able to do manually or on a one-off basis:
Included in MoDaCo 1.1 'core':
Rooted with 'adb remount' permission and superuser APK
A2SD included (fully automatic thanks cyanogen!) create a EXT2 partition as your second partition to use. dalvik-cache remains on device.
Added Jbed Java
Added Dropbear SSH running by default, check 'About' screen for password (port 2222). You can now remove this by running /system/bin/removedropbear.sh
Added Notes app from Dragon
Added Spare Parts (run it and switch the 2 animation types to 'fast' for an even better experience!)
Added android-wifi-tether 1.60 pre3 (props to the developer, this is a great app!)
Added WiFi Status indicator, with kind permission of Andrew Schwimmer
Added busybox 1.15.2 tweaked such that 'get information' in Swapper now works as desired
Added nano 2.09 text editor for use in shell mode
Added parted and sqlite tools
Added terminfo and settings to boot.img to allow nano etc. use
Added files required for Debian linux including loxley's updated bootdeb script
Moved Quickoffice to data partition to allow easy uninstall
Moved Google Maps and Google Voice Search to data partition to allow easy update
Silenced boot sound (it's still there and can be reactivated with a file edit)
Click to expand...
Click to collapse
*********
*********
!Working!
Wireless Tethering:
http://android-wifi-tether.googlecode.com/
Go to the "Downloads" tab and download version 1.61-pre
!Not Working!
Superuser Whitelist App
I found two threads here that describe how to install Superuser.apk.
http://forum.xda-developers.com/showthread.php?t=582140
http://forum.xda-developers.com/showpost.php?p=4897587&postcount=5
Using the first one, I was able to get the files onto the phone and I used the chmod commands found in the second file in the hopes this would work; however, whenever I try to use it, nothing happens. The ES File Explorer, in particular, used to work with MoDaCo. When I'd try to browse as root, Superuser would pop-up and ask if I wanted to grant the app permissions. Now it just hangs there (black screen) and ES File Explorer says I don't have root access. Other Root apps work fine though, it's just they don't seem to be dependant on Superuser Whitelist.
'adb remount' permission
This requires that the default.prop file be edited from ro.secure=1 to ro.secure=0. Unfortunately, I can't seem to get this file to stick. If I use the mv command using adb shell, I get some kind of permissions error. If I use the cp command when booting into the recovery menu and using adb shell, the file reverts to the original on boot. Or maybe it's simply not being overwritten, but not throwing any errors either
I think I may have found a thread that will help with the default.prop changes. Looks like this has to be done in the recovery.img which apparently overwrites any modifications in the root of the device on each reboot. I'll post an update if/when I figure it out.
HOWTO: Unpack, Edit, and Repack Boot Images
http://forum.xda-developers.com/showthread.php?t=443994
The adb remount permission issue is driving me crazy. Please keep us updated if you figure out a way of resetting that without installing a new ROM.
I ended up modifying one of the MoDaCo update scripts to set up ADB Remount, Superuser.apk, and Busybox. It's been working fine for me, but be sure to do a backup before you apply the update. Check it out here:
http://forum.xda-developers.com/showthread.php?t=593952
Hi all,
i often noticed people(including me) who tried to modificate their framework-res.apk resulting in boot loops(e.g. looping at white/green quietly brilliant screen).
So i tried to find out a fast way to get back to my(original) framework-res.apk without usage of recovery console each time my framwork-res.apk did not work as expected.
How it could help you:
It's a fast way to:
check out your moddings when doing numerous modifications in different versions of your modded framework-res.apk on your way to get it to work.
if you want to get back to your original/working framework-res.apk, even when it boot loops!
Click to expand...
Click to collapse
When you do numerous modifications on framework-res.apk and your modded apk leads to a boot loop you will be able to replace the current apk through e.g. the original apk.
At this boot point(boot loop screen) Android nearly finished booting and you have access on ADB commands.
What do you need to do this:
Download and extract/install QtADB from the link below:
QtADB
to replace the erroneous(current) framework-res.apk by the original or a fixed one.
Click to expand...
Click to collapse
There's no need to describe how to get a copy of your untouched framework-res.apk from device, since there are numerous tutorials around here.
Please check this tutorials to get a copy of your apk.
Please note before beating your device:
this probably will work with the most visual moddings of framework-res.apk - but i can't guarantee it works 100%.
It probably will not work when you play around with hardware or connections setting, other apk's or other stuff in other folders, so i am not responsible if it does not work.
always backup your current ROM/settings/whatever and save a copy of your untouched framework-res.apk
There is a little catch in it in comparsion with using recovery:
After you did like described, you have to set your background image and your (google) accounts anew.
But this is just a little work and it's not necessary until your framework-res.apk is doing the modded stuff correctly - or if you want to set the original framework-res.apk back.
Click to expand...
Click to collapse
So let's start to revive your original framework-res.apk.
(Of course you can use this method to push a modded to your device, to check out if your modding works):
Boot your device and let it load until you're at boot loop
(Download, extract,) run QtADB
Navigate in left window(Computer) to your copy of original framework-res.apk(e.g. in root directory of SD card, but i recommend a folder on your computer)
Navigate in right window(Phone) to device folder /system/framework/
Use in left window(Computer) context menu on your original framework-res.apk and select copy or drag&drop it to right window to copy the original framework-res.apk to your device
(just ignore that your device is doing strange stuff then, since it cannot access your framework-res.apk correctly at this point)
Then enter shell of QtADB(at left toolbar of QtADB) and enter the following commands to set the apk's prermissions:su
cd /system/framework/
chmod 777 framework-res.apk
Reboot your device( e.g. by using top menu->tools-ADB->reboot)
Set your background image and your (google/HtcSense) accounts anew.
Hope it helps you a bit on modding,
Greetings, brush2(Stephan)
error
hey man, Im getting an error on this. I changed my transitions effects ( folder anim on framework-res.apk) using the app metamorph. well, now every time I open an app the phone ( xt920) reboot. I ask my friend that have the same phone to send me his framework-res.apk. I try to replace using this method but dont got. I draged and droped the new apk and when I would type the shell's code the last code dont work because it said that the file is a "read-only system". What can I do to have my phone back? Please help.
Thanks.
Hi,
I'm new to the business and I spent some time to learn the environment trying different applications and different approaches for almos every action I took. Today, I have not much bigger knowledge, but I finally decided to take few things in my own hands because existing software is not fulfilling my wishes.
I started with this simple script which eases the pain of reinstalling all applications after ROM upgrade. There are few such tools already, but I found those quite bloated with unnecessary thing for my own approach.
With this script I assume:
1. There is/was SSHDroid installed (or any tool with busybox and you can access shell command line) both in old and new ROMs and your ROM have bash installed in /system/bin/.
2. Backup/restore operation includes only INTERNALLY installed applications, it completely ignores SYSTEM and SDCARD installed ones.
3. This is TEMPORARY backup so it should be as fast as possible not caring about occupied space (!). Althought I added -zip parameter to enable compression if you are running out of space on your sd.
4. Installed ROM is clean with no additional apps installed (excluding those needed by the script)
5. You have basic knowledge about bash scripting, because I take NO RESPONSIBILITY of the script behavior or data loss it can do.
So, basically it is simple. It runs like this:
1. On old ROM type: sbackup -backup
2. Flash your ROM
3. On new rom type: sbackup -restore
Just like that. The applications data is tar'ed in one file per application so if you want to get rid of any, just delete it from backup directory. The directory name is same as script name on sdcard but you can change it adding a parameter without a '-' sign at runtime (first non-option parameter is treated as backup directory path). The file is zipped because this forum disallows files without an extension so... it is zipped ;D
It was tested on my fresh LeeDroid 3.3.3 GB AFTER i installed some apps. I backed them up and then restored. All seems to be perfect right now, but I will test it more thoroghly very soon because I'm planninig to have CM7 based ROM too just to choose that I need Sense or not (two nandroids for fast switch weekly ;P).
With this script and MyBackup functionality of backing up contacts, sms, history and similar it should be quite complete approach to restore all the data needed on the fresh ROM. In the future maybe I will look at the MyBackup part too. Maybe.
Feel free to comment, use, suggest or anything you like, and have fun ;P.
How do I run this script? Do i run it from sdcard or from system /bin? When i do it from system bin it says cannot create directory. When i run it from sdcard/sbackup it says permissions denied?
Sent from my ADR6400L using Tapatalk
jgrimberg1979 said:
How do I run this script? Do i run it from sdcard or from system /bin? When i do it from system bin it says cannot create directory. When i run it from sdcard/sbackup it says permissions denied?
Sent from my ADR6400L using Tapatalk
Click to expand...
Click to collapse
And thats why I mentioned in topic about not being a newbie (and I meant not forum newbie but more a linux newbie). The thing is, it's a simple script - without any user-proof capabilities, comments inside or something BUT...
But ok, I will try to help you run it. First of all, you have to set permissions to the script. It has to have executable permission to be run by the system (and I mean filesystem permission). This can be done by chmod instruction of busybox. Most of the times it's done like this:
chmod 755 filename
This is a reason of not running form sdcard if your sdcard is NOT ext filesystem (it is usually windows fat filesystem not to generate problems with reading it under windows).
Second thing to run is to have /system/bin/bash because first line of the script (a comment like this: #!/system/bin/bash) instructs busybox to execute script using bash. This can be simply changed by modifying this line, but you have to remember that changing the shell executing script have consequences. Differens shells have sometimes different syntax, althoght i wrote this script simply so it should run on most of them, especially sh.
Third thing is to have write permissions to the directory in which the backup will be created. In original version of the script it is /sdcard, because backup is made in /sdcard/sbackup. So, you have to check it (second error - problems with creating directory).
And a last tip - it can be run from ANYWHERE. Even if your partition does not alolow executing, you can do it like this:
bash-3.2# /sdcard/test
bash: /sdcard/test: /system/bin/bash: bad interpreter: Permission denied
bash-3.2# . /sdcard/test
OK
bash-3.2#
First try does not succeded, but second did. The trick is a dot which means to execute file with a shell not caring about why or permissions.
And thats most simple introduction I could write. It applies to ANY script you want to run.
Please anyone - if you want me to help, paste your results here because without a precise error message it can be very hard to deduce what caused for example permission denial or anything usual.
For now, I won't add any more error handling, but if there will be more users caring about, I will add it.
There is an interesting discussion on the Russian forum the-ebook.org (paste this link into Google and select the translation; item is on page 2) regarding those annoying invisible menu options in many apps. Although the translation is a little rough around the edges, the gist seems to be that the default text and background colors for the app menus are not exactly what the e-ink display has in mind, often resulting in light or near-white text on a white background--hence, invisible text.
The "solution" used is to change some background color settings in framework-res.apk. I have no idea what the outcome looks like but it seems like a really good idea, although beyond my abilities, and the example used is 1.10 firmware. I'm using 1.21. Any attempt I have made to modify apk files has always failed
Does anyone have a fool-proof set of steps for doing this?
I remember reading about what you're talking about somewhere on the forums but I could never get it to work either...
Here's what I'm talking about:
http://forum.xda-developers.com/showthread.php?t=1356514
http://forum.xda-developers.com/showthread.php?t=1512846
OK, well.....I've got the adjusted background images extracted from the framework-res.apk file that I got from the Russian site (I'm working with the lighter background option at this point). And...I've found the setting in WinRar to simply "store" (not compress) the updated png files. So far, so good. My altered apk file is the same size as the original.
The clincher is to get it back on the Nook without disaster ensuing. I'm going to follow Renate's method for pushing back framework-res.apk via ABD (from this thread):
C:\>adb shell
# stop
# mount -o rw,remount /dev/block/mmcblk0p5 /system
# ^C
C:\>adb push framework-res.apk /system/framework
C:\>adb shell
# reboot
Keep your fingers crossed. If it works, I'll report back with step-by-step and files.
[Report: in concept this "works". On reboot I could see the slightly grey background color in menu options and going to a few apps where I knew the menus were invisible, I could see white text on the slightly grey background. BUT...almost no apps will work. The B&N side seems to function OK, but the App drawer is useless. Back to the drawing board. The Russian site has a method for installation using RootExplorer. I'll try that next.]
OK...day 2. Here's what does NOT work:
1. method in post above using ADB
2. method using RootBorwser as adapted from Russian site and detailed below:
a. Change permissions in /system, /system/etc and /system/framework folders so that all users have write access
(note this is my kludge to get around not knowing how to "mount" the /system partition as r/w--maybe it's wrong?)
b. Use ADB wireless to move modified framework-res.apk into /system/etc
c. Use RootBrowser to check ownership of modified framework-res.apk (should be and was already owner: 0-root, group: 0-root)
d. Use RootBrowser to change permissions on modified framework-res.apk to rw-r--r-- (664)
e. Use RootBrowser to move (cut/paste) modified framework-res.apk into /system/framework (overwrite)
With Superuser permission, this all went off without a hitch.
f. Use RootBrowser to reset permissions of folders listed in (a)
g.Shut down Nook and restart.
The result is the same as the ADB-only method described before. The Nook starts up just fine. You can see that the background color of menus is slightly gray. Those changes have obviously worked. But the vast majority of apps will not run (ADW Launcher is an exception). At one point while I was fiddling with things the Nook spontaneously rebooted.
I guess that's better than spontaneously combusting
SIGH. Clearly, despite my best efforts, something I did in handling the framework-res.apk has damaged it in some subtle way, OR, my inability to properly "remount" the /system as R/W is causing the problem, although using ADB this is accomplished without difficulty and since the result is the same...it must be the modified apk file.
And this is why I have a dedicated SD card backup......
Method 3 that does NOT work:
1. Install Ninjamorph and BusyBox from Market
2. Follow instructions for altering framework-res.apk found here.
Two ways to Finish Project, with zip-align and without. Both yield the same result which is the same as the other methods above, i.e., the B&N stuff mostly works and the desired contrast of the menus is achieved so you can actually see what used to be invisible, but most apps will not run. Really frustrating.
I have to say that while this method seemed promising it is tedious in the extreme as each of the 28 png files must be replaced individually and that means each must be located in a much larger list (which reverts to the top after each replacement....). Ugh.
I simply don't believe anyone who says they can make these modifications with the instructions they have provided. It must be that people who are more familiar with this stuff are leaving out information which is so obvious to them that they don't even think to mention it
framework-res.apk is an apk and therefore it must be signed.
It's a system apk so it must be signed with the system signature.
Modifying a few things doesn't annoy the signature matching, other stuff does.
When you have problems, please quote from logcat because that tells you exactly what the problem is.
Using ADB:
Code:
logcat
Whatever.9.png are special files.
The are usually created thusly:
http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch
When they get packed into an apk they are turned into a PNG graphic with alpha channel.
aapt handles this.
If you take a PNG with sidebars and just zip it, it will not work.
Renate NST said:
When you have problems, please quote from logcat because that tells you exactly what the problem is.
Using ADB:
Code:
logcat
Whatever.9.png are special files.
The are usually created thusly:
http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch
When they get packed into an apk they are turned into a PNG graphic with alpha channel.
aapt handles this.
If you take a PNG with sidebars and just zip it, it will not work.
Click to expand...
Click to collapse
I just tried again and this time after pushing the amended framework-res.apk file (yes, all 28 amendations are nine-patch files) I typed in logcat before rebooting.
Whoosh!!! Lines of information went streaming by faster than I could follow, so much that some of the earliest disappeared from the top of the console window. I have no clue how to extract the text from the console window
The top-most complaint I saw was a reference to system error 1248 in association with the CleanMaster app. Then there seems to be a periodic (15 second) dhcpcd renewal. Eventually there is a section that says "Framework disconnected, eof, failed to read size, closing connection". Then comes a long list of notifications from the Service Manager about all the services that have just died. After that it just continues with the 15-second dhcpcd renewal cycle. Then I gave up and rebooted.
The result is the same as before. The new image backgrounds have been incorporated into the system, but most of the app drawer is just pretty icons. ADW runs--at least the drawer and home page appear. The B&N Home and Library pages load but you can't access any of the books shown. Wi-Fi can be accessed but no apps that use it will run. Occasionally the CleanMaster app throws up an error message.
Here's what I've learned so far:
1. In the original amended framework-res.apk file (for FW 1.10) viewing the archive reveals that the files which have been changed all have an "archive " attribute. None of the original files show any attribute. I don't know whether that is important. I've searched on this topic and have come up with nothing.
2. In moving the amended *.9.png files from the original Russian example for FW 1.10 into a copy of my own framework-res.apk for FW 1.21, those "archive" attributes came along for the ride and the resulting amended file does show "STORE" for the method so I think I got that part right and didn't recompress any files when moving from one apk to another (I dragged the files from one instance of WinRAR to another--I tried 7zip as well...).
But I have no idea why people report that this procedure works just fine. For me, it is predictable, but not successful.
I've just completed yet another restore from backup. I'm going to uninstall CleanMaster and try again. Perhaps it's background activities are driving the process into the ground. I have no clue.
Here's the logcat session file (learned how to get that done!) after a re-try, having removed CleanMaster first.
No change in the outcome but no bleating from the Nook about CleanMaster errors.
I wonder--is it the modified apk that is causing the system to malfunction, or....is it the way it is being pushed back to the Nook?
So..an experiment: I pulled a copy of the stock framework-res.apk from my Nook. I didn't do anything to it at all. Then I pushed it back to the Nook via wireless ABD:
C:\>adb shell
# stop
# mount -o rw,remount /dev/block/mmcblk0p5 /system
# ^C
C:\>adb push framework-res.apk /system/framework
C:\>adb shell
# reboot
This is supposed to work, yes? It does not. It leaves me in the same condition that all of the other attempts by this and other methods have. The Nook boots normally and displays Home but you can't access the "currently reading" book. I can get to the app drawer via the quicknav buttons, but very few apps will work (including ADB). There is no way to examine the file system because RootBrowser will not work (although ES File Explorer does, but it doesn't have root access).
So....whether the modified apk is OK or not, I would never know because all of the methods I have tried to get the framework-res.apk back onto the Nook have been unsuccessful.
That procedure should work fine.
Have you checked using the stock framework-res.apk ?
Renate NST said:
That procedure should work fine.
Have you checked using the stock framework-res.apk ?
Click to expand...
Click to collapse
Yes, that's what I just tried. Just pulled it via ADB and then pushed it right back. I also installed a copy of Root Explorer (I generally used Root Browser) because that's what was used in the original thread on the Russian site where I got started with the whole project. That also yields the same results. The Home screen loads but you can't access the book currently being read from it or from the little button at the top left. You can access any of the QuickNav options. The Library "functions". But you can't access books from their covers and the double-tap does not work.
In the app drawer, ADW seems to work fine but you can only run a very few apps, and none that require wi-fi (although wi-fi works). Too much fiddling around and the Nook spontaneously reboots.
When I have tried to move in the modified apk with the slightly gray background 9.png files I can see that the new image backgrounds have been used in the drop-down menus. This suggests to me that the problem is not in how the 9.png files have been moved from the FW1.10 apk obtained from the Russian site into my FW1.21 apk but rather in the integration of the modified apk into the system. I've checked permissions, etc. Everything is OK but the system is just screwed up.
I'm running FW1.21 which has been rooted using Nook Manager with Gapps added. I've done the multi-touch modification and have swapped in a modified internal.db file which seems to have solved the confusion of the "reading now" button. I have some apps that run along in the background, like Tasker and Clean Master (probably others that I don't realize). Do I need a completely clean system to make this change?
I saw the logcat and it showed that it's unhappy and killing the Android.
I couldn't see exactly where the problem is.
I think that you are doing too many things at once.
If there are specific things that do not work, a logcat when you do that should show.
Renate NST said:
I saw the logcat and it showed that it's unhappy and killing the Android.
I couldn't see exactly where the problem is.
I think that you are doing too many things at once.
If there are specific things that do not work, a logcat when you do that should show.
Click to expand...
Click to collapse
Yes, I was probably a little unclear. The ONLY thing that I did when I produced the logcat was attempt to push the modified framework-res.apk file back to the Nook. All those other things mentioned have long ago been successfully accomplished and included in my current backup (which I've had to use dozens of time in the last week or two as I struggle with this framework issue).
The ONLY change to the stock framework-res.apk is the overwriting of 28 *.9.png images with ones copied from another framework-res.apk which, unfortunately, is from FW1.10 (or I'd just use it "as is" without the copying). However, even pushing back an unmodified stock apk results in the same mess.
Like I say, based on what functionality remains when the modified apk file is pushed over, it is clear that the new images are being used, but the system function is severely degraded.
I don't know much about the process, but from what I've read I'm wondering if it would be better to use a zip via CM to deliver this modified file? That way the Android system is not even running (right?) during the replacement procedure.
When you say "stop" Android is no longer running.
Try clearing the cache:
Code:
rm -R /data/dalvik-cache/*
Renate NST said:
When you say "stop" Android is no longer running.
Try clearing the cache:
Code:
rm -R /data/dalvik-cache/*
Click to expand...
Click to collapse
Before pushing? After, but before rebooting?
Anytime that Android is stopped you can clear the cache.
I tried this with a copy of the stock apk:
Code:
C:\>adb shell
# stop
# rm -R /data/dalvik-cache/*
# mount -o rw,remount /dev/block/mmcblk0p5 /system
# ^C
C:\>adb push framework-res.apk /system/framework
C:\>adb shell
# reboot
It put me in an very long chase of the black and white dots that I almost thought would be endless but eventually it finished booting and is in the same condition as all the previous methods. Very crippled.
I can't figure it out
First, get the 1.2.1 update off B&N's website and unzip.
Get framework-res.apk out of that and push it.
The stuff in /system/framework should all be chmod 644.
An ADB push probably leaves it with wider access.
None of this should make any difference.
I'd guess that you are either missing a resource in your fw-r or else you modified something else.
Find an app that crashes. Get a logcat of just that crashing.
Renate NST said:
First, get the 1.2.1 update off B&N's website and unzip.
Get framework-res.apk out of that and push it.
The stuff in /system/framework should all be chmod 644.
An ADB push probably leaves it with wider access.
None of this should make any difference.
I'd guess that you are either missing a resource in your fw-r or else you modified something else.
Find an app that crashes. Get a logcat of just that crashing.
Click to expand...
Click to collapse
I got a copy of the FW 1.21 zip from B&N and extracted the framework-res.apk. I didn't try to push it yet. Instead I got the checksum for the current file on the Nook and compared it to the newly minted file. They were identical. I don't think there is any point in trying yet again with the same procedure. If my reasoning is incorrect, I'm certainly game to try anyway.
All files in /system/framework are chmod 644. The Framework folder itself (and the system folder) are something else, but the contents are all 644.
The only modifications I have made after rooting with Nook Manager are the installation of Google Apps, the implementation of multi-touch (I have to go back and look that up to see what all I did, but surely nothing with framework-res.apk or it never would have worked....), editing settings.db to relabel the QuickNav buttons after programming with NTMM, and pushing a modified copy of internal.db to fix the schizo "reading now" button. As i say, these are all long-established changes and the Nook has been stable with them. I think Google apps may modify framework.jar, but I'm not sure.
[I checked on multi-touch. I flashed a new kernal image and added one line to /etc/permissions/required_hardware.xml in order to enable multi-touch...have no idea what "flashed a new kernal" actually did, but it worked]
Two really noob questions: 1) how can I get a logcat of an app crashing when ADB will not run once a copy of framework-res.apk has been pushed? 2) if the Android system is actually stopped when I type "stop"in ADB shell, how does ADB continue to function?
And, actually, apps do not so much "crash" once I've attempted to put in a "new" framework-res.apk--most just refuse to run. But maybe there is something going on in the droid brain while the screen flickers a little and nothing else happens.
ADB runs under Linux, not the Android subsystem.
You should always be able to access ADB.
If ADB isn't running continuously and reliably you have problems.
If some app does not run, give the specific section in logcat where it doesn't run.
Forgive me if I have a gross misunderstanding about the hardware in the NST, but in my eyes it should be possible for the Nook to sleep but retain the screen, perhaps with a small banner indicating it's in sleep state and you need to press the 'n' to wake. It just seems silly having the benefit of an e-ink display only for the screensaver to kick it when it sleeps. If it didn't do this, I could (for example) leave a map open in OsmAnd and refer to it still while the Nook is sleeping. The only 'solutions' to this I've found involved plain and simply keeping the Nook awake! A hack I can think of would be to somehow bodge something together to take a screenshot just before the nook sleeps and set it as the screensaver image. Seems silly though... I've had a search around and can't find anything related to this specifically, more either people wanting to keep the nook awake or disable the slide to unlock.
Any thoughts welcome!
I had the exact same thought,
so I'm making an app that takes a screenshot every 1:50 minutes and saves it at a screensaver,
to be displayed when the nook goes to sleep.
hopefully it will be ready this weekend so stay tuned
It should be be simple enough.
Modify /system/framework/android.policy.jar
The class is com.android.internal.policy.impl.LockScreen
What puts up the "screensaver" is updateBackgroundImage()
The layout is in /system/framework/framework-res.apk,
res/layout/keyguard_screen_gossamer_unlock.xml
I'm not sure if changing the layout to transparent and not updating the image should be enough.
Renate NST said:
It should be be simple enough.
Modify /system/framework/android.policy.jar
The class is com.android.internal.policy.impl.LockScreen
What puts up the "screensaver" is updateBackgroundImage()
The layout is in /system/framework/framework-res.apk,
res/layout/keyguard_screen_gossamer_unlock.xml
I'm not sure if changing the layout to transparent and not updating the image should be enough.
Click to expand...
Click to collapse
Oh I wish you would have said that two days ago...
It seems a far better solution than my app, maybe I'll try playing with that later.
I tried replacing updateBackgroundImage()
with a stub, but the screensaver still comes up as usual,
Only difference is the "slide to unlock" screen now has black background, so that's what this function is doing.
Time for plan B (or C, really):
If I were to modify framework-res.apk as you suggest, Will I need to resign the whole system, as here?
Update -
The function that sets the screensaver is createScreensaver(), in class com.android.server.PowerManagerService, found in /system/framework/services.jar
I modified it to make the screensaver invisible, but unfortunately it also means there's no indication that the nook sleeps.
Anyway, it's better than constantly taking screenshots, so I'll stick with that.
nivieru said:
Update -
The function that sets the screensaver is createScreensaver(), in class com.android.server.PowerManagerService, found in /system/framework/services.jar
I modified it to make the screensaver invisible, but unfortunately it also means there's no indication that the nook sleeps.
Anyway, it's better than constantly taking screenshots, so I'll stick with that.
Click to expand...
Click to collapse
How did you do that? I'm using the screenshot sreensaver app for that and I find it very useful. But the above mentioned way seems to be less power consuming. Could you explain it for somebody with very little knowledge about manipulating apk, though I know how to manipulate apk with xdaAutotool.
I don't know xdaAutotool, I use apktool but you can probably use whatever tool you like.
First you need a patched /system/framework/services.jar
the one I attached here is for firmware 1.2.1 rooted with NookManager, so it also includes the NookManager patches.
if this is your setup as well, skip to 4
if you run a different firmware or don't want the NookManager patches you will need to patch it yourself
patching /system/framework/services.jar - some vauge instructions:
you will need apktool (or XdaAutotool or whatever) and the android-sdk.
1) use apktool to decompile services.jar
2) modify createScreensaver() in file smali/com/android/server/PowerManagerService.smali according to the attached patch-services.txt
notice - this patch is for firmware 1.2.1 with NookManager patches, it might not be ready for use with other versions - not only the line numbers, also the register v6 might not be a good choice if it is used later in the code without being assigned a new value first.
3) recompile with apktool.
replacing services.jar with patched version - complete instructions:
4) making a full backup before messing with the system is good practice, although the nook is notoriously hard to brick.
you could use NookManager to do the backup.
5) connect to your device with adb
6) apply these commands:
Code:
adb push pathced-services.jar /media
adb shell stop
adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb shell cp /system/framework/services.jar /system/framework/services.jar.backup
adb shell cp /media/pathced-services.jar /system/framework/services.jar
adb shell chmod 644 /system/framework/services.jar
adb shell reboot
7) relax, first boot takes a few minutes, this is normal.
with this patch the screensaver is invisible, so there is no indication at all that the device is asleep.
also, there's no magic button to change behavior - if you want to the screensaver back you need to replace services.jar with original version
Thanks for that extensive description. I'll try the next days to implement it in my system which differs from yours, since I'm using the custom rom from pinguy1982.
Got it.
I compared your PowerManagerService.smali with the one in my services.jar and made the changes.
Recompiled the services.jar.
Exchanged the original classes.dex with the new compiled classes.dex in 7zip.
Signed the jar file.
Had a lot of problems with adb, which didn't recognize my device.
Lost my temper, packed it into a ZIP-file and replaced it via CWM.
Everything is working now. Thanks!
nhedgehog said:
Got it.
I compared your PowerManagerService.smali with the one in my services.jar and made the changes.
Recompiled the services.jar.
Exchanged the original classes.dex with the new compiled classes.dex in 7zip.
Signed the jar file.
Had a lot of problems with adb, which didn't recognize my device.
Lost my temper, packed it into a ZIP-file and replaced it via CWM.
Everything is working now. Thanks!
Click to expand...
Click to collapse
Hi @nhedgehog
I also use the custom rom from pinguy1982.
Can you share your zip file to flash with CWM
Thanks
tebra said:
Hi @nhedgehog
I also use the custom rom from pinguy1982.
Can you share your zip file to flash with CWM
Click to expand...
Click to collapse
Here you are:
Patch (nivieru's method) via ZIP, tested only with modded ROM from pinguy1982 and installed Nooter-Part1.zip. Install via CWM, to be safe make a backup before you do the patch.
Services-org.zip=original services.jar
Services-patch.zip=patched services.jar
Hi everyone!
I've patched the jar and now enjoy the last image in sleep mode. But, I'd like to wake app the Nook every few hours, update the page in dolphin and go back sleep. Page in dolphin has a meta refresh. But I can't wake up the Nook on interval. Is it impossible or I missing smth very important on this topic?
If anybody has some experience on topic, please comment.
Update, my solution:
Re-signed the system with personal cert and implemented an app instead of dolphin+web page.
App wakes up every few hours, updates view and throws device to deep sleep. Hope to get an uptime up to 10-15 days.
nivieru said:
I
replacing services.jar with patched version - complete instructions:
4) making a full backup before messing with the system is good practice, although the nook is notoriously hard to brick.
you could use NookManager to do the backup.
5) connect to your device with adb
6) apply these commands:
Code:
adb push pathced-services.jar /media
adb shell stop
adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb shell cp /system/framework/services.jar /system/framework/services.jar.backup
adb shell cp /media/pathced-services.jar /system/framework/services.jar
adb shell chmod 644 /system/framework/services.jar
adb shell reboot
7) relax, first boot takes a few minutes, this is normal.
with this patch the screensaver is invisible, so there is no indication at all that the device is asleep.
also, there's no magic button to change behavior - if you want to the screensaver back you need to replace services.jar with original version
Click to expand...
Click to collapse
I've done exactly as described in points 4-7 on NST firmware 1.2.1 , rooted with Nook Manager.
I used Root explorer for replacement and rename of patched-services.jar.
After rebooting of NST, it works as intended - the screensaver is unseen, but it appears other problem.
When i click at random .apk, nothing happens, only the screen is flickering once and that's all.
I cannot install apk-s, nor uninstall them....? WTF ?
Someone with explanation...?
gsms said:
I've done exactly as described in points 4-7 on NST firmware 1.2.1 , rooted with Nook Manager.
I used Root explorer for replacement and rename of patched-services.jar.
After rebooting of NST, it works as intended - the screensaver is unseen, but it appears other problem.
When i click at random .apk, nothing happens, only the screen is flickering once and that's all.
I cannot install apk-s, nor uninstall them....? WTF ?
Someone with explanation...?
Click to expand...
Click to collapse
Replacing services.jar while the android system is running can cause problems, that's why I suggest doing it through adb after issuing the "stop" command, which stops android while leaving the underlying linux (with adb) running.
You should try that and see if it helps.
I will try, but before that another question from me.
Is there a chance the file "patched-services.jar" to be remade as .zip file and installed thru CWM.
If this can be done, i will be glad somebody to share the .zip file, because i think it is more comfortable for installation than using adb shell....
thanks
P.S. Adb don't work correctly for me, so the only available option is obviously flashable .zip file...
...
Has anyone tried this with FW 1.2.2 yet?
jptiger said:
Has anyone tried this with FW 1.2.2 yet?
Click to expand...
Click to collapse
If the original services.jar was patched, it will break NTMM since that relies on patches. But if you can discern what the additional patches are you could patch the 1.2.2 file used in NookManager.
Edit: but if you just want to see how it might work, you can probably use the 1.2.1 jar without any problems. When I first started working on the update to NookManager I used the original 1.2.0 jars that were provided with FW 1.2.2 and saw no evidence of problems. A diff showed very minor changes. Depending on how extensive the patching is for this mod, it might be easier--if you still want the use of NTMM--to patch the file in post #8 for NTMM since the patches are well documented on github. Otherwise you have a lot of diffs to look at and sort out.