Having trouble booting into Cynogen. As far as I can tell, everything is flashedd correctly. I got the initramfs and zimage from here. They flashed fine and the system boots into the multi boot screen.
Then I copied the openaos-gingerbread-anoa-gen8_113301.img.gz from here to my device through the USB MSC renaming it to openaos-gingerbread.img.gz
I believe that the menu.lst file should update itself so there should be no need to edit the file. I had to edit the file anyway, not sure why. Tried editing it through np++ and got Ginger-Bread listed in the boot menu. Tried to boot into it but it just sat at the OpenAOS screen and did nothing. I left it on that screen for close to half an hour.
I then tried the menu.lst file that is linked to the post by gbohm but the same thing happened.
When I access recovery and start USB MSC again it shows a ~525MB file called openaos-gingerbread.img and it has a folder called openaos which has a subfolder called disabled. Nothing else.
I tried this off the back of a full wipe so there is nothing on the device at all. No archos FW or anything. Coming from UD 1.5
Any idea what might be going on?
Edit: one last note. This was all done on my Windows machine. Will try it on my ubuntu server tomorrow. That machine is just a little more awkwardly placed
Maybe be you edited the menu.let wrong
Lokk in my "OpenAOS Full Instructions Thread" for tips;-) here in general section
Lenn said:
Maybe be you edited the menu.let wrong
Lokk in my "OpenAOS Full Instructions Thread" for tips;-) here in general section
Click to expand...
Click to collapse
No. Like I already said lenn update your guide or mention that it is outdated and point to the wiki.
This is what I was afraid off, giving people wrong instructions and make it worse for them.
---------
d31b0y you did it correct. Just copy openaos-gingerbread-anoa-gen8_113301.img.gz and rename it to openaos-gingerbread.img.gz
The menu.lst should update itself and create an extra Gingerbread entry in the bootmenu.
Some things that could go wrong is that you didn't safely umount or remove the drive. So the image got corrupted.
Another thing is that you maybe didn't rename it correctly using capital letters perhaps.
However my best guess is that the image got corrupted during download or during copy renaming and not safely remove the drive.
This http://dev.openaos.org/wiki/AndroidInstall_CM7_Gingerbread is the guide to follow and no other.
We from openaos recommend using linux to do the procedure, it is also much easier for us to support when coming for questions on irc http://www.openaos.org/chat
Maurice
Sorry, but stil >> 90% of users have a windows maschine.
Maybee you should also think about your target audience.
fzelle said:
Sorry, but stil >> 90% of users have a windows maschine.
Maybee you should also think about your target audience.
Click to expand...
Click to collapse
Yes, I know. Windows shouldn't be a problem for the procedure. It is only easier for us when answering questions, because we are almost all on linux machines. That is why I said we recommend it, not that we say you must use it.
Some issues for windows users. It hides known file extensions by default which could be a problem when renaming files. Windows doesn't care about cap letters, Linux does. A file named foo.img.gz is different from Foo.img.gz .
Maurice
divx118 said:
No. Like I already said lenn update your guide or mention that it is outdated and point to the wiki.
Click to expand...
Click to collapse
Sorry divx i really respct your works, but i know it.
I work at the momet on a honeycomb theme, and i said he should look there because of the menu.lst (the most makd faults, ...) and this part isnt outdated.
I will update the tutorial when i have enough time
Greets
Lenn
I know all that, as my first Unix was Minix followed by SCO and Eurix and then Linux 0.14 yggdrasil.
But if i see the questions postet here and elsewhere in android forums,
most of the people barely get their TV switched on, and to tell them that Linux is prefered might set back a few so much that they don't do anything.
On the other side, might be a good idea ;-)
Thanks for getting back to me. For some reason when I copy the file to the archos and reboot, it doesn't show up in the menu.lst
I decided to gunzip first and moved the file openaos-gingerbread.img to the archos. This showed in the list but when I tried to boot from it, the same thing as before happened. Hopefully I am just doing something silly. I'll try jump on the irc channel tomorrow. My main "comfy" computer was taken up by the oh this evening.
A couple more points.
My external SD slot is broken so I have no external SD. Although it installs onto the internal right? So that shouldn't make a difference.
I don't have stock fw installed at all. Just the SDE.
Edit: oh by the way, when I tried to move the .img file I got the following error:
mv : failed to preserve ownership for '/media/A101IT/openaos-gingerbread.img': Operation not permitted
It was moved with root privelages in terminal.
Edit2: I even did a sync before my umount to make sure everything was hunky dorey.
Sent from my R800i using Tapatalk
You need the stock to be installed, as during boot they extract some things.
I could be wrong but none of the above post seem to have noticed you haven't extracted the .gz img file. If you put that on you device it will do nothing as its the wrong file format and still compressed. You need to extract it using winrar or similar then rename that file to openaos-gingerbread.img and that should do it. nothing to do with capital letter you just missed a small but crucial step in the instructions.
ben.cordy said:
I could be wrong but none of the above post seem to have noticed you haven't extracted the .gz img file. If you put that on you device it will do nothing as its the wrong file format and still compressed. You need to extract it using winrar or similar then rename that file to openaos-gingerbread.img and that should do it. nothing to do with capital letter you just missed a small but crucial step in the instructions.
Click to expand...
Click to collapse
I'm pretty sure you don't and I have tried that anyway as per my second post...
Sent from my R800i using Tapatalk
fzelle said:
You need the stock to be installed, as during boot they extract some things.
Click to expand...
Click to collapse
That'll do it I'm sure. Will try to tonight.
Sent from my R800i using Tapatalk
Like fzelle said you need stock firmware, that is why it hangs. It needs to copy some libs and drivers over from stock. We can't include them in the release, because of license issues.
I don't think we check in the script if the original firmware isn't there. Another todo ...
I will update the wiki about having original firmware installed is essential.
@ben.cordy: The initramfs will gunzip the image when it is not done already, so no need to gunzip or unrar it yourself.
Still strange why it wouldn't show up in menu.lst while gzipped... I will check the script in initramfs.
Maurice
---------- Post added at 09:05 PM ---------- Previous post was at 08:47 PM ----------
fzelle said:
I know all that, as my first Unix was Minix followed by SCO and Eurix and then Linux 0.14 yggdrasil.
But if i see the questions postet here and elsewhere in android forums,
most of the people barely get their TV switched on, and to tell them that Linux is prefered might set back a few so much that they don't do anything.
On the other side, might be a good idea ;-)
Click to expand...
Click to collapse
At the moment, our target is the more advanced user, so we can get some good bug reports. That is why we have that big red warning on the wiki. So might be a good idea --> It is one .
Maurice
Related
Can't post in the Dev section yet. That's what I get for trolling around since you guys showed me how to root my OG Droid. Thanks, btw.
Now, I'm trying to root my Tbolt, and when I click on the downgrade RUU file to see the contents it says the file is invalid. So, then I tried to extract it, to see what would happen, but same message.
I also downloaded the exploits.zip and the final PG05IMG.zip and was able to view both their contents. Plus, I had to extract the exploits file to the SDK directory, and it worked fine.
So, I then downloaded from all three mirrors, but same result. And then I went to the rom.galaxysense.com site and downloaded from there, but same result. Am I the only one having retarditis? Is the file jacked, or just run-of-the-mill incompetence on my part???
Thanks to whomever takes the time to help out. And thanks for all the help everyone puts out there for the rest of us.
I am confused by your massive amount of words in this post. You need to say maybe, 20 things total.
First, you don't need to open anything, you simply need to put the ZIP onto your SD card and reboot into Hboot.
The only ZIP you need to unzip is the exploit.zip.
I don't need to extract them, I get that. I was looking in the zip files out of curiosity, but when the one file said it was an invalid file type I didn't want to put it on my SD card. That's closer to 20 words, hope that makes sense.
drweltman said:
I don't need to extract them, I get that. I was looking in the zip files out of curiosity, but when the one file said it was an invalid file type I didn't want to put it on my SD card. That's closer to 20 words, hope that makes sense.
Click to expand...
Click to collapse
haha, I was feeling like being a smart ass. The RUU needs to be renamed to PG05IMG.ZIP and put on the sd card, then you need to reboot into bootloader.
Also to add, I came into the problem where I renamed to PG05IMG.zip It was already zipped so just had to name it PG05IMG Then it worked for me.
Thanks for the help. I guess no one understood what I was saying, but since no one else has mentioned the file being corrupted I guess I'll use it and hope for the best.
That's why I mentioned that the other two zip files would let me look at their contents, but the third one said invalid file type. I thought it was clear, but my bad...
Either way, here's another post towards getting out of noob post restrictions!
drweltman said:
Thanks for the help. I guess no one understood what I was saying, but since no one else has mentioned the file being corrupted I guess I'll use it and hope for the best.
That's why I mentioned that the other two zip files would let me look at their contents, but the third one said invalid file type. I thought it was clear, but my bad...
Either way, here's another post towards getting out of noob post restrictions!
Click to expand...
Click to collapse
I'm pretty sure that the RUU downgrade is not something you can open. Just make sure the checksum is valid and you're good to go.
I had tried to flash the RUU after I first rooted becuase I was having location issues. It would check the PG05IMG.ZIP and go back to the Hboot screen. I had flashed another rom so I didn't mess with it any further.
drweltman said:
Thanks for the help. I guess no one understood what I was saying, but since no one else has mentioned the file being corrupted I guess I'll use it and hope for the best.
That's why I mentioned that the other two zip files would let me look at their contents, but the third one said invalid file type. I thought it was clear, but my bad...
Either way, here's another post towards getting out of noob post restrictions!
Click to expand...
Click to collapse
Finally! I've been looking through threads forever in search of this very issue. I was all set on rooting last night, and just like you, the Mecha_RUU file wouldn't unzip, said it was invalid, etc. I stopped right there out of fear that I'd get burned pressing on with one of the key files "broken." Have you rooted since with no trouble?
The best thing to always do is get an MD5 sum for the file and compare it to the root post. I have rooted my thunderbolt twice now and never had a problem.
If the md5sum is correct then you should be fine. Also remember in Windows, it hides the extensions. So when you rename your files do not add the extension as it is already there.
You can show the extensions by changing the folder settings.
Downgrade wont flash
1) Power down phone
2) Power up phone holding volume down
3)No option to upgrade just starts checking files
4) Third check is the downgrade file, starts loading
5) Fails because the file is Older than the main
Ive seen other threads touch on this but no one answer it. Any help with this would be greatly appreciated. Also I have already updated to the 7/8/11 OTA.
Thanks,
JDBSC1 said:
1) Power down phone
2) Power up phone holding volume down
3)No option to upgrade just starts checking files
4) Third check is the downgrade file, starts loading
5) Fails because the file is Older than the main
Ive seen other threads touch on this but no one answer it. Any help with this would be greatly appreciated. Also I have already updated to the 7/8/11 OTA.
Thanks,
Click to expand...
Click to collapse
as in "MAIN VERSION HIGHER" error while flashing?
Not sure what exactly you are trying to do but read this post where it discusses about getting that error.
http://forum.xda-developers.com/showthread.php?t=1008824
Absolute_Zero said:
as in "MAIN VERSION HIGHER" error while flashing?
Not sure what exactly you are trying to do but read this post where it discusses about getting that error.
http://forum.xda-developers.com/showthread.php?t=1008824
Click to expand...
Click to collapse
I appreciate the thread link. That's exactly the error I'm getting. Problem is I'm supposed to downgrade to obtain root ( or at least that's one of the steps). I have downloaded this downgrade file from multiple links and verified its the correct one to use in this step and I always receive the "main version higher" issue. Should I be using a different file to downgrade or is this no longer an option for root since the 7/8/11 ota?
Sent from my ADR6400L using Tapatalk
Interesting..
I wiped everything ADB and Thunderbolt related from my PC.
Then I downloaded the easy root from this link
http://forum.xda-developers.com/showthread.php?t=1005292&highlight=easyroot
Then I downloaded and opened the pdf instructions on the same page.
Then I followed the written directions to a T!
Worked like a charm. Steps 1, 2, and 3 hung up and had to be done multiple times but I finally got through it. Some other links if found with this same method were misleading as to doing the steps over again but he accounted for this in his pdf instructions and if you follow it to the letter you should be good.
Does anyone know where I can find a copy of this? I've done a search and all I can find is one from the international version and that's based on the 2.3.1 build.
TIA
check here http://forum.xda-developers.com/showthread.php?t=1286432
daraj said:
check here http://forum.xda-developers.com/showthread.php?t=1286432
Click to expand...
Click to collapse
Nothing there about stock system dump.
BigBolo said:
Does anyone know where I can find a copy of this? I've done a search and all I can find is one from the international version and that's based on the 2.3.1 build.
TIA
Click to expand...
Click to collapse
Entropy512 started with a stock system dump that someone, (maybe Jivy26), made after installing a custom kernel. But I don't remember he ever posted a link to it. He may still have it hanging around, though. That's what he used to make his stock plus root package.
BigBolo said:
Nothing there about stock system dump.
Click to expand...
Click to collapse
Um, what do you think a flashable stock system image is? (Other than being a sparse ext4 image, if you want something loop-mountable use simg2img...)
Seriously - spend just a LITTLE more time reading before you post in a Development thread. This device has been out for only 2 weeks so it's not like the Dev forum has tons of threads.
There's also a dd-derived system dump in page 5 of codeworkx's CWM kernel thread. I used jivy26's tar dump, although I should probably do a consistency check against seattleboi1982's dump.
Entropy512 said:
Um, what do you think a flashable stock system image is? (Other than being a sparse ext4 image, if you want something loop-mountable use simg2img...)
Seriously - spend just a LITTLE more time reading before you post in a Development thread. This device has been out for only 2 weeks so it's not like the Dev forum has tons of threads.
There's also a dd-derived system dump in page 5 of codeworkx's CWM kernel thread. I used jivy26's tar dump, although I should probably do a consistency check against seattleboi1982's dump.
Click to expand...
Click to collapse
I'm actually looking for the system dump in a zip where I can extract it into folders. Not as a image. I want to basically get the media files. I did do a search in several forums trying to find it but came up with nothing.
Maybe I should of been more detailed and specific in my OP.
BigBolo said:
I'm actually looking for the system dump in a zip where I can extract it into folders. Not as a image. I want to basically get the media files. I did do a search in several forums trying to find it but came up with nothing.
Click to expand...
Click to collapse
Can't you just extract the stock system image?
eep2378 said:
Can't you just extract the stock system image?
Click to expand...
Click to collapse
I don't know how to do that...
Then you probably don't belong in android development (yet).
Use 7zip to extract the zip/tar/whatever.
In general, you're not supposed to put requests in Development. This should have been posted in General.
And a stock system dump IS an image dump. Zip files don't preserve permissions, and tar files only do if you prepared them carefully (good thing jivy26 did). The only way to be sure is to dd the partition.
If you want a nice easy to use zip, use paylyhoffman's stock deodexed CWM zip.
Entropy512 said:
In general, you're not supposed to put requests in Development. This should have been posted in General.
And a stock system dump IS an image dump. Zip files don't preserve permissions, and tar files only do if you prepared them carefully (good thing jivy26 did). The only way to be sure is to dd the partition.
If you want a nice easy to use zip, use paylyhoffman's stock deodexed CWM zip.
Click to expand...
Click to collapse
Thanks for clearing it up. My bad I thought this was the section to post requests like that.
Also folks before jumping on the guy, what he is asking for (at least with the .7z file posted) isn't as straightforward as everyone thinks.
If you first extract the 7z file, you'll get a PDA.tar file. Extract that and you'll get the kernel (zImage) and the lovely factoryfs.img.
Try extracting factoryfs.img with your favorite tools and see what happens.
Extracting the factoryfs.img is a real pain unless you are pretty hardcore -- in fact, there was another thread going on the in international SGS II forum with some pretty well known devs (who know their stuff) trying to figure out how to extract that bad boy.
So before everyone starts throwing rocks...you know the story.
Does this look easy to you?
http://forum.xda-developers.com/showthread.php?t=1054836 (relevant discussion starts around post #7)
and another solution (which also is not as simple as "right-click and extract")
http://forum.xda-developers.com/showthread.php?t=1081239
Now -- with that said, if one was really looking for an easy way to pull some media files from a ROM, you best bet would be to try and find a CWM flashable ROM (in a zip format) and do a regular extract on those, and you may find it much easier. They may not be stock, but if it's close, you may get lucky and find some of the stock media in them.
pinoymutt said:
Also folks before jumping on the guy, what he is asking for (at least with the .7z file posted) isn't as straightforward as everyone thinks.
If you first extract the 7z file, you'll get a PDA.tar file. Extract that and you'll get the kernel (zImage) and the lovely factoryfs.img.
Try extracting factoryfs.img with your favorite tools and see what happens.
Extracting the factoryfs.img is a real pain unless you are pretty hardcore -- in fact, there was another thread going on the in international SGS II forum with some pretty well known devs (who know their stuff) trying to figure out how to extract that bad boy.
So before everyone starts throwing rocks...you know the story.
Does this look easy to you?
http://forum.xda-developers.com/showthread.php?t=1054836 (relevant discussion starts around post #7)
and another solution (which also is not as simple as "right-click and extract")
http://forum.xda-developers.com/showthread.php?t=1081239
Now -- with that said, if one was really looking for an easy way to pull some media files from a ROM, you best bet would be to try and find a CWM flashable ROM (in a zip format) and do a regular extract on those, and you may find it much easier. They may not be stock, but if it's close, you may get lucky and find some of the stock media in them.
Click to expand...
Click to collapse
Thanks for clarifying that pinoymutt. Yea basically I know a lot of people don't like the finished charging notification but I don't mind it and I figured it's as simple as just placing the ogg file back in the ui folder. I'm on DG's Cog X2 and he had removed that.
BigBolo said:
Thanks for clarifying that pinoymutt. Yea basically I know a lot of people don't like the finished charging notification but I don't mind it and I figured it's as simple as just placing the ogg file back in the ui folder. I'm on DG's Cog X2 and he had removed that.
Click to expand...
Click to collapse
Doubt it's that simple. I removed the notification by modifying code. I would bet dg did the same.
Well as many of you know we're over most of the hurdles we needed to jump with the CM7 build for Nook tablet.
Updates for the internal version are simple via CWM, the SD version is not so simple of course.
I'm assuming that it should be possible to built an APK that gains superuser permissions then copies the new files to the system. Can anybody confirm this is possible please?
We need to know that we can tell our SD user that they can update their version just as easy as the internal user
Thanks in advance for your help again everyone!
Well presumably this is how ROM Manager and Metamorph both do their thing, just in a slightly more round about way (as they don't come with the files they need to copy). I'm almost 100% sure this is possible, but I've never tried it personally.
EDIT: Looks like this is how you'd do it: http://developer.android.com/reference/java/io/File.html. Specifically the renameTo() method.
CelticWebSolutions said:
Well as many of you know we're over most of the hurdles we needed to jump with the CM7 build for Nook tablet.
Updates for the internal version are simple via CWM, the SD version is not so simple of course.
I'm assuming that it should be possible to built an APK that gains superuser permissions then copies the new files to the system. Can anybody confirm this is possible please?
We need to know that we can tell our SD user that they can update their version just as easy as the internal user
Thanks in advance for your help again everyone!
Click to expand...
Click to collapse
Well there are about a dozen ways to do this. First of one of the hardest things is comming up with the commands/script. I can defiantly do this. If you want an apk, there are a few guys whom could port my script to an apk. I'm going to make a script here that will format, and create partitions and extract directly from the nook, no need to go through the fancy formatting and such, just go into terminal and run the script. Ill post a prototype for you to have the testers test!
Do you think something like BacksideUpdater inside custom ROM for LG Optimus V?
made by JerryScript
JerryScript i very nice guy, I bet if you ask him, he will let you play with his code
if is it what you looking for
Yes, this is possible. I wrote an app that flashes the recovery partition for my older Froyo phone in the very rudimentary Basic4Android. Copying files under root privileges was part of this process. Fairly easy if you find the right coding examples in whatever your development platform of choice.
xdajunkman said:
Yes, this is possible. I wrote an app that flashes the recovery partition for my older Froyo phone in the very rudimentary Basic4Android. Copying files under root privileges was part of this process. Fairly easy if you find the right coding examples in whatever your development platform of choice.
Click to expand...
Click to collapse
So one of the problems is its not really copying. Its more of an extraction from one place to another. We are required to use dd, and fdisk(for formatting).
GREAT! I was worried updates would be to complicated for people
Sent from my Nook Tablet using xda premium
... and I was worried that I might have to wipe my NT clean again to get the updates. After a week with this wonderful upgrade, I've got a LOT of customization I don't want to lose...
Whoops, wrong button with the thanks. Anyway, it occurs to me you could just have people run a script from a terminal emulator. That would probably be the simplest way to do it. Make an Update folder on the SD card, add it to the PATH by default, and users could just copy over the update files and run the script. Just a thought.
Sycobob said:
Whoops, wrong button with the thanks. Anyway, it occurs to me you could just have people run a script from a terminal emulator. That would probably be the simplest way to do it. Make an Update folder on the SD card, add it to the PATH by default, and users could just copy over the update files and run the script. Just a thought.
Click to expand...
Click to collapse
Has to be simple, something like copy an update.zip onto the SD card then run the apk which will automatically run the update in the zip But my knowledge of such things is limited so I need help there
Same process. With the above method, the user would only have to copy over the file, open a terminal, and type 'update'. With the apk idea you just have to add a little more time for someone to actually write the app (not that it would take too long).
Sycobob said:
Same process. With the above method, the user would only have to copy over the file, open a terminal, and type 'update'. With the apk idea you just have to add a little more time for someone to actually write the app (not that it would take too long).
Click to expand...
Click to collapse
Hmm.... that sounds good.
Anybody know how to actually implement it ?
Dammit, idk why I keep hitting the thanks button thinking it's reply >.>
Anyway, it's just a matter of setting the PATH variable to include /sdcard/Update/ or something similar. To make an actual update, make a folder called Update, fill it with all the files that need to be copied over (probably in a directory structure), and write a script that actually copies everything over. You'll need to make sure sh is in /system/bin (I think it is by default).
You could zip the the files as well, using gunzip (busybox?) to extract them before copying them, then deleting them when you're done, just to keep it cleaner for the user.
The only downside to all this is that I don't know how you would flash a kernel.
Sycobob said:
Dammit, idk why I keep hitting the thanks button thinking it's reply >.>
Click to expand...
Click to collapse
That makes two of us!
Sycobob said:
Anyway, it's just a matter of setting the PATH variable to include /sdcard/Update/ or something similar. To make an actual update, make a folder called Update, fill it with all the files that need to be copied over (probably in a directory structure), and write a script that actually copies everything over. You'll need to make sure sh is in /system/bin (I think it is by default).
You could zip the the files as well, using gunzip (busybox?) to extract them before copying them, then deleting them when you're done, just to keep it cleaner for the user.The only downside to all this is that I don't know how you would flash a kernel.
Click to expand...
Click to collapse
I'm guessing you'd just flash it as usual, surely that one is the easiest? Copying stuff to boot partition would hopefully be just as simple, I was mainly worried about updating system files. I could do with building one for the current update to test the theory!
Enable Copy & Paste on the Nook Tablet
Background
The lack of copy & paste functionality on the Nook Tablet is one of the most annoying "features" of the B&N firmware and it affects not just geeks like me but also the average user. This thread and this thread are two of many, many threads complaining about the missing copy & paste. This thread proposes a "fix" by combining the Hacker's Keyboard and Swype, but is still really lame.
The method I will describe here solves the problem by replacing /system/framework/framework.jar which contains the code for Android widgets like text fields. I have merged into the stock /syste/framework/framework.jar the code responsible for copy & paste from the Android source code.
Instructions
Video walkthrough: http://www.youtube.com/watch?v=7V70a3FYbt4
0. Before you proceed, know that THIS IS EXPERIMENTAL SOFTWARE THAT PROBABLY VOIDS YOUR WARRANTY AND MAY PERMANENTLY OR TEMPORARILY BRICK YOUR TABLET. Even though it worked for me, it may not work for you, and worse, it is quite possible that it could cause your tablet to boot-loop or die. I AM NOT RESPONSIBLE FOR ANY POSSIBLE DAMAGES TO YOUR TABLET / ANYTHING ELSE CAUSED BY THIS METHOD. BY USING IT YOU AGREE TO ASSUME ALL RESPONSIBILITY FOR YOUR ACTIONS.
1. Your tablet needs to be rooted for this to work. If you have not rooted it yet, search this forum for instructions.
2. Since we will be copying files to /system, you will need to install ES File Explorer or Root Explorer or whatever other app that allows you to do that.
3. Download the file that corresponds to your OS version from below:
1.4.2 (16GB/8GB): http://www.mediafire.com/?5pf2aegq02194lq MD5: ef35d35daffd0d9574f48a43ccc4b58c1.4.0 (16GB): http://www.mediafire.com/?es6gd31wzr7yk8a MD5: 99d2e7eff173fbdc77c79b4f4a6ff53c
The 1.4.0 version has been reported to cause boot loops for some people, while it has worked for others. You have been warned.If you're on a different OS version, post the file /system/framework/framework.jar form your tablet and I will make a package for it.
4. Extract file contents to microSD card, and insert microSD card into the tablet.
5. Using ES File Explorer / Root Explorer, copy the extracted file framework.jar.new to the directory /system/framework/. (If you're using ES File Explorer, make sure "Up to Root", "Root Explorer", and "Mount File System" are checked in settings.)
6. Copy the extracted file uim-sysfs to /system/bin/.
7. Go to /system/bin/, and change the permissions of the file uim-sysfs to executable. (If using ES File Explorer, long press -> Properties -> Change -> Check everything under "execute".)
8. Power off tablet and power on again. The tablet should take much longer to boot this time than normally, so no need to worry. When the tablet boots up, you will most likely see lots of force close dialogs. This is normal.
9. Wait one minute. You could be stuck in a boot loop if you don't wait.
10. Power off tablet and power on yet again. This time it should also take much longer to boot; the boot times will return to normal after several reboots.
11. Profit.
Force close issues
The first time you run some (read most) apps after applying this hack would likely result in force closes. While annoying, there is no way to get around it due to how the Dalvik VM caches references to /system/framework/framework.jar. In addition, every time you install new apps or update apps, you will have to reboot the machine before those apps are usable; you will get a force close when you try to use those apps until you reboot.
The solution is simply to reboot your tablet each time you get a force close error from an app that worked fine before this hack. The force close error for that particular app should go away following a reboot. If you get a force close from another app after that, just reboot again.
How it works
The information below is for people interested in understanding how this stuff works. If you just wanted to enable copy and paste on your tablet, you can stop reading.
This hack is based on the exploit explained at http://forum.xda-developers.com/showthread.php?t=1534518. The uim-sysfs script in the attached file saves the stock /system/framework/framework.jar, copies over my modified framework.jar.new, and restarts the zygote process. After the zygote process has loaded my framework.jar.new, the uim-sysfs script restores the stock /system/framework/framework.jar so that /init will not bail on the next boot.
To enable copy & paste in /system/framework/framework.jar, I decompiled the stock implementation and merged in related code from AOSP. The two classes I changed are android.widget.TextView and android.widget.EditText. For android.widget.EditText, I simply used the AOSP implementation because the only difference between the two was in the enabling of copy & paste. I manually merged android.widget.TextView because there appears to be B&N enhancements in it in addition to disabling copy & paste.
The exact steps I took as well as a diff of my modifications are documented in post #12.
Disclaimer
Again, this is experimental software. That it worked for me does not mean it will work for you, or that it won't brick your tablet. I am not responsible for any possible damages resulting from using this method.
Here i post framework.jar from stock 1.4.0 rooted
~ Veronica
lavero.burgos said:
Here i post framework.jar from stock 1.4.0 rooted
Click to expand...
Click to collapse
OK. Looks like the framework.jar from 1.4.0 is different from 1.4.2; I've merged in the same changes. If you're feeling brave, the package I've made for 1.4.0 is here.
MD5: 99d2e7eff173fbdc77c79b4f4a6ff53c
Can you confirm whether this works?
16gb Nootlet with 1.4.0 rom, rooted, OTA blocked yada yada.
Stayed at the "read forever" screen almost forever, then finally started up. Fellow victims take note, it isn't dead so be patient.
Lots of FC, the last persistent one was the launcher (ADW ipaidforthis version)
Powered off and on again after waiting way longer than 1 minute.
Second boot forever at "read forever" screen so far.
If it comes back to life I'll try the 1.4.0 version & let you know.
[Edited to add}
... time passes ...
Any way out of the "ADWLauncherEX" force-close loop? Does Android have a "safe mode" boot option like Windows? (sorry)
No, I haven't installed CWM recovery yet. Remind me to do that if this thing ever gets over its mental breakdown.
jichuan89 said:
OK. Looks like the framework.jar from 1.4.0 is different from 1.4.2; I've merged in the same changes. If you're feeling brave, the package I've made for 1.4.0 is here.
MD5: 99d2e7eff173fbdc77c79b4f4a6ff53c
Can you confirm whether this works?
Click to expand...
Click to collapse
Thanks can't test right now 'cause im finishing another project and then i have to test the tun.ko module for CM9 busy bee .
~ Veronica
cellhead said:
Stayed at the "read forever" screen almost forever, then finally started up. Fellow victims take note, it isn't dead so be patient.
...
Second boot forever at "read forever" screen so far.
Click to expand...
Click to collapse
Thanks for mentioning this. Will add to instructions.
cellhead said:
Any way out of the "ADWLauncherEX" force-close loop?
Click to expand...
Click to collapse
Getting FC's is normal - as the instructions state you probably have to reboot a number of times before all FC's disappear. Any luck so far? If not, please let me know and I will post a recovery SD card image that will allow you to undo this hack.
Also - as I said clearly in the instructions (Compatibility section), before you try this out on your 16GB, you should post your /system/framework/framework.jar so I can verify that this works on the 16GB. I don't have the 16GB tablet so I don't know if this works on it at all. Anyone?
Thanks. You may want to feature the version info prominently in the OP. I got my issue solved in a roundabout way when it finally went into a boot loop and triggered the factory reset. That got me back to 1.4.0 unrooted, and without the FC problems. Reran indirect's rooting script and I'm back to some semblance of normality.
Ain't complaining, I took on the risk of trying your copy/paste fix and went on an unplanned adventure. Such is life as a RL software tester ;-)
I'll wait and see how things shake out. You're onto something good here, so once it's a little safer for the normals to apply it, I'll give another go.
For the record, 16g Nook tablet, rooted via indirect, OTA blocked, v1.4.0
cellhead said:
You may want to feature the version info prominently in the OP.
Click to expand...
Click to collapse
You're right...really sorry about that.
On the other hand, did you try the files in the original post, or did you use the files for 1.4.0 I posted in the 3rd post?
The ones in the original post. Then I read the third post, but was unable to get it to boot far enough that I could replace the files and try again.
Sent from my BNTV250 using xda premium
cellhead said:
The ones in the original post. Then I read the third post, but was unable to get it to boot far enough that I could replace the files and try again.
Click to expand...
Click to collapse
The files in the original post are modified from 1.4.2 and would most certainly not have worked on 1.4.0...I should have made that clearer. Sorry.
The files in the 3rd post though are modified from 1.4.0 (thanks to lavero.burgos) and should work for you. Any chance you could test them out?
--- EDIT ---
Also - I've made a bootable SD card that will remove this hack and fix the tablet even if something goes wrong and you cannot boot into the system to remove the files directly. I can post it if someone needs it.
Cool hack, but why all these doubts and asks for 16gb's framework.jar ? What users have on devices comes from vendor firmware package(s), and you can see at http://www.barnesandnoble.com/u/Software-Updates-NOOK-Tablet/379003187/ that there's no separate versions for 8gb vs 16gb. That page (and pages for other releases) should be also the authoritative place for getting framework.jar .
On the related note, would you care to provide exact instructions how to make framework.jar with c&p functionality? That would help to keep it updated across vendor upgrades, and also for making sure that new framework.jar contains only changes related to c&p and nothing else ;-). Granted, such instructions would be long and boring, so writing them in the shell script language rather than English would be a good idea ;-).
pfalcon said:
Cool hack, but why all these doubts and asks for 16gb's framework.jar ? What users have on devices comes from vendor firmware package(s), and you can see at http://www.barnesandnoble.com/u/Software-Updates-NOOK-Tablet/379003187/ that there's no separate versions for 8gb vs 16gb. That page (and pages for other releases) should be also the authoritative place for getting framework.jar .
Click to expand...
Click to collapse
Thanks for the link! I went and downloaded the update archive and extracted it, and can confirm that the /system/framework/framework.jar in that archive (which I'd assume is the same as on the NT 16GB/1.4.2) is different from the same file on my NT 8GB/1.4.2., which confirms my hypothesis in posts #11 and #14 in http://forum.xda-developers.com/showthread.php?t=1517513&page=2. The bizarre thing is that if you unzip the files they produce the exact same content; it looks like they differ only in some sort of signature. But this means that my framework.jar will work on both the 8GB and 16GB on 1.4.2. So thanks again for the link!
pfalcon said:
On the related note, would you care to provide exact instructions how to make framework.jar with c&p functionality? That would help to keep it updated across vendor upgrades, and also for making sure that new framework.jar contains only changes related to c&p and nothing else ;-). Granted, such instructions would be long and boring, so writing them in the shell script language rather than English would be a good idea ;-).
Click to expand...
Click to collapse
What I did was this. You need zip, unzip and a tool called apktool. I'm assuming the framework.jar from the Nook is called ~/framework.jar.nook and the framework.jar from vanilla Android (AOSP) is ~/framework.jar.aosp.
1. Extract framework.jar into a directory z:
Code:
$ unzip framework.jar -d z
2. Use apktool to disassemble framework.jar.nook:
Code:
$ apktool d ~/framework.jar.nook
3. Disassemble framework.jar from AOSP.
Code:
$ apktool d ~/framework.jar.aosp
4. Compare and modify framework.jar.nook.out/smali/android/widget/{TextView,EditText}.smali against framework.jar.aosp.out/smali/android/widget/{TextView,EditText}.smali. My diff file can be downloaded here. Apply diff with
Code:
$ cd framework.jar.nook.out; patch -Np1 < jichuan89_nook_text_hack.diff; cd ..
5. Recompile Nook's framework.jar:
Code:
$ apktool b framework.jar.nook.out
6. Repackage modified Nook's framework.jar into ~/framework.jar.new
Code:
$ cp framework.jar.nook.out/build/apk/classes.dex z/classes.dex
$ cd z; zip -r ~/framework.jar.new META-INF classes.dex preloaded-classes; cd ..
framework.jar in that archive (which I'd assume is the same as on the NT 16GB/1.4.2) is different from the same file on my NT 8GB/1.4.2
Click to expand...
Click to collapse
I just tried to compare framework.jar I have on my device after 1.4.2 OTA update vs downloaded from B&N site - they turned out to be the same, md5sum is 795ae49e2b05b05c999a424a7d84b36b. Anyway, good news that contents were the same in your case too. It might be that 8Gb's initial in-flash 1.4.2 indeed was packaged differently than 16Gb's 1.4.2 update (that's idea somehow backed by the fact that 16Gb's initial in-flash 1.4.0 is not available on B&N site). Again, good to know that actual contents are the same, so 1.4.3 would be common either (which makes full sense, otherwise B&N just makes it harder on themselves).
What I did was this.
Click to expand...
Click to collapse
Thanks for the instructions and the diff! I with that all hacks posted on the forum came in such form ;-)
pfalcon said:
I just tried to compare framework.jar I have on my device after 1.4.2 OTA update vs downloaded from B&N site - they turned out to be the same, md5sum is 795ae49e2b05b05c999a424a7d84b36b.
Click to expand...
Click to collapse
Nice - thanks for confirming this. That's really helpful to know.
pfalcon said:
It might be that 8Gb's initial in-flash 1.4.2 indeed was packaged differently than 16Gb's 1.4.2 update (that's idea somehow backed by the fact that 16Gb's initial in-flash 1.4.0 is not available on B&N site). Again, good to know that actual contents are the same, so 1.4.3 would be common either (which makes full sense, otherwise B&N just makes it harder on themselves).
Click to expand...
Click to collapse
Right - it would make economic sense for B&N to make the software on the two tablet models to be as close as possible. I do hope they'll make their and our lives easier by just using the same version of the same damn files in the next update for the two models, as you said.
Sent from my Nook Tablet using XDA
I can make CWM flashable zip with original framework.jar for the ones having troubles until is fully tested. Tomorrow i'll jump back to stock 1.4.0 to test this hack and report back.
~ Veronica
A flashable zip would be cool if for no other reason than simplicity and reduced panic on the part of newcomers and when re-flashing the stock ROM.
I'm going to try this, so with me luck, but first: Do I need to boot into CWM to do this?
CRE said:
A flashable zip would be cool if for no other reason than simplicity and reduced panic on the part of newcomers and when re-flashing the stock ROM.
I'm going to try this, so with me luck, but first: Do I need to boot into CWM to do this?
Click to expand...
Click to collapse
No - this is for the stock firmware. CWM should have copy & paste already because it doesn't use B & N's framework.jar.
CWM as in ClockWorkMod not CM7 as in CyanogenMod v7.
EDIT:
To clarify, I didn't know if I could do this while the NT was booted normally or if I needed to boot with ClockWorkMod to ensure that the OS didn't try to access that file.
CRE said:
CWM as in ClockWorkMod not CM7 as in CyanogenMod v7.
EDIT:
To clarify, I didn't know if I could do this while the NT was booted normally or if I needed to boot with ClockWorkMod to ensure that the OS didn't try to access that file.
Click to expand...
Click to collapse
No. If there were requirements I would have put them in the instructions. It doesn't matter how you boot.
Sent from my Nook Tablet using XDA
Thank you. I guess I'll repartition first then get this out of the way too.
Ok, this may be answered elsewhere, I don't know. "Search is temporarily unavailable" I am trying to understand how I am supposed to work with the backup from CWM. I understand that I should have a System image that I can work in, but what I have is 3 files in its place. System.ext4.tar, System.ext4.tar.a, and System.ext4.tar.b. All three files are broken to some degree.
System.ext4.tar is a zero byte file.
System.ext4.tar.a appears to be a spanned tar file that 7ZIP/WinRAR simply think was cut-off (never asks for the second file, and complains of unexpected End of Archive)
System.ext.4.tar.b appears to be the second part of the archive, but nothing will open it.
So, how do I get to a point I have a complete archive that I can edit? Or do I need to use different software than CWM to back up the phone?
Thanks for the help guys.
waldojim said:
Ok, this may be answered elsewhere, I don't know. "Search is temporarily unavailable" I am trying to understand how I am supposed to work with the backup from CWM. I understand that I should have a System image that I can work in, but what I have is 3 files in its place. System.ext4.tar, System.ext4.tar.a, and System.ext4.tar.b. All three files are broken to some degree.
System.ext4.tar is a zero byte file.
System.ext4.tar.a appears to be a spanned tar file that 7ZIP/WinRAR simply think was cut-off (never asks for the second file, and complains of unexpected End of Archive)
System.ext.4.tar.b appears to be the second part of the archive, but nothing will open it.
So, how do I get to a point I have a complete archive that I can edit? Or do I need to use different software than CWM to back up the phone?
Thanks for the help guys.
Click to expand...
Click to collapse
Well, I found a solution for now. Fire up Linux, use cat to combine all three files, then use tar to extract the contents. Not sure why this needed split in the first place, but at least the files can be extracted.
I have managed to remove the APKs I do not want, and made a new system.ext4.tar file (all in Linux), but need to know what else I have to do to make the system image usable.
I found several guides on making a ZIP file, but I didn't want to necessarily go through all that. I backed up everything, so what I would like to know, is what all needs to change so that I can use the separate files as they are, and simply do a CWM "restore" function?
I know I sound like a complete noob at this point, and will deal with the related comments. However, please understand, I don't want the heavily modified rom packs. I simply wanted a rom VOID of all the Verizon bloatware, and have the Verizon tethering restraints removed. I have them all disabled now, and 3rd party tethering is working quite well. So I would rather not have that garbage wasting space. Right now, it looks like I may save 250MB or so.
Any help would be appreciated. Thanks.
waldojim said:
I have managed to remove the APKs I do not want, and made a new system.ext4.tar file (all in Linux), but need to know what else I have to do to make the system image usable.
I found several guides on making a ZIP file, but I didn't want to necessarily go through all that. I backed up everything, so what I would like to know, is what all needs to change so that I can use the separate files as they are, and simply do a CWM "restore" function?
I know I sound like a complete noob at this point, and will deal with the related comments. However, please understand, I don't want the heavily modified rom packs. I simply wanted a rom VOID of all the Verizon bloatware, and have the Verizon tethering restraints removed. I have them all disabled now, and 3rd party tethering is working quite well. So I would rather not have that garbage wasting space. Right now, it looks like I may save 250MB or so.
Any help would be appreciated. Thanks.
Click to expand...
Click to collapse
Backups really aren't meant to be unzipped and played with. Usually bloat removal is done while booted into the system or you can unpackage a Rom and remove the bloat there and then repackage it and flash it then make your backup that doesn't contain any bloat. Using the xda kitchen tools from dsxda I believe is the name
Sent from my HTC6435LVW using XDA Premium HD app
.torrented said:
Backups really aren't meant to be unzipped and played with. Usually bloat removal is done while booted into the system or you can unpackage a Rom and remove the bloat there and then repackage it and flash it then make your backup that doesn't contain any bloat. Using the xda kitchen tools from dsxda I believe is the name
Sent from my HTC6435LVW using XDA Premium HD app
Click to expand...
Click to collapse
I think this is where some of my confusion comes from - it was never zipped. There was a group of tarred files, an MD5sum and a few other items. But nothing there was zipped.
waldojim said:
I think this is where some of my confusion comes from - it was never zipped. There was a group of tarred files, an MD5sum and a few other items. But nothing there was zipped.
Click to expand...
Click to collapse
I guess what I meant to say by "zipped" was just in general they are compressed by the recovery in a way that it knows how to go and use them to restore data to the device.