This is a request to all ROM developers to add their ROMS to ROM Manager.
This will make installing ROMS very easy and efficient for users without even touching the computers.
GUIDELINES:
FOR USERS:
1)You need to download and install the latest recovery from this page:
http://forum.xda-developers.com/showthread.php?t=1243133
2)Download ROM Manager from the market.
3)Open ROM Manager >Options>Manual Flash Override>Spice Mi700,Commitiva N700 and more>Clockwork Mod 3.x.
4)To download ROMS go to the download ROMs page.
FOR DEVELOPERS:
Go to the Developer Portal on:http://www.clockworkmod.com/
P.S.-I have already added a ROM on ROM Manager.
Feel free to download and try it.
GH - Keep up the excellent work & thanks.
My Vpad7 (ITE - Hwv 1.7) has been on CWM 3.0.2.8 and I upgraded to 5.0.2.6 - easy & simple with posted instructions in linked site - was running TJ_Style's ROM patched with non-OC kernel before but running EU.V1.7b ITE now.
Once I rebooted Recovery and navigated to Advanced/Debug Menu to Check Log, etc. - there's no "Go Back" option or menu item available, pressing the device's "Back" button does not work (tried other variations too.) Reset via the pin hole and reboot again into Recovery, check the newly reformatted card with partition/ext, and no "Go Back" option or menu item to Cancel/Undo or Escape.
Perhaps I missed the changes and I re-read the latest info posted ....
Otherwise, this is really & truely great - please kindly check and advise, much appreciated.
P.S. Looking forward to get it partner with ROM Manager and to reflash the EU V1.7b ITE ROM, etc. to the device as I've issues with the (DT's A2SD) scripts associated with the SD-Ext3 configuration.
The reason the back button is not working is because i build this ROM usings TJstyle's kernel which is not compatible with your device input hardware
The kernel was built using the source provided by FIH.
This source does not have the touchsreen input driver for the latest Viewpad7.
Only solution to this problem and all other ITE hardware related problems is to contact Viewsonic and ask them to provide the updated kernel source or borrow the driver from a similar Viewsonic device such a Viewpad10.
If you have a root file manager
open the file :sys/devices/virtual/input/input1/name
and post me the contents
googlehome said:
The reason the back button is not working is because i build this ROM usings TJstyle's kernel which is not compatible with your device input hardware
The kernel was built using the source provided by FIH.
This source does not have the touchsreen input driver for the latest Viewpad7.
Only solution to this problem and all other ITE hardware related problems is to contact Viewsonic and ask them to provide the updated kernel source or borrow the driver from a similar Viewsonic device such a Viewpad10.
Click to expand...
Click to collapse
Thanks, understood & it make sense to me. I will contact VS's tech. support with a request & see what they can provide or offer, etc. and post back results. Also, will search around for drivers from VPad10 ....
P.S. Even without the working "Back" button in Recovery, I managed to use it to format the mSD card, wipe & install new ROM, etc. - it's a bit tricky but manageable. And, the EU v1.7b ROM with ITE hardware support loaded ext3 nicely .... Kudo's
googlehome said:
If you have a root file manager
open the file :sys/devices/virtual/input/input1/name
and post me the contents
Click to expand...
Click to collapse
Used Astro File Manager to take a screenshot (attached) and to try to open the "name" file - it appeared to be a blank one, file size 0 or zero. Used ES File Explorer and getting the same ?? Is there anything specific to look for, or should I just try to extract/copy the file and upload it, kindly let me know. Thanks.
Letitride said:
Used Astro File Manager to take a screenshot (attached) and to try to open the "name" file - it appeared to be a blank one, file size 0 or zero. Used ES File Explorer and getting the same ?? Is there anything specific to look for, or should I just try to extract/copy the file and upload it, kindly let me know. Thanks.
Click to expand...
Click to collapse
Uploading the file would be great.
googlehome said:
Uploading the file would be great.
Click to expand...
Click to collapse
Here's the file saved in zip format. If this isn't it and/or you need another file or folder, just let me know or PM. Thanks.
in sys/devices/virtual/input/
how many folders do you have?
can you upload the name file of each folder?
googlehome said:
in sys/devices/virtual/input/
how many folders do you have?
can you upload the name file of each folder?
Click to expand...
Click to collapse
Checking under ....
there are 3 folders - input0, input1, input2
there is a "name" file in each of them, extracted each "name" file & zipping them together for upload.
Big thanks for looking into this for a possible resolution.
** Attached zip file has 3 name file:
name.input00 (renamed from name - for the input0 folder)
name.input01 (renamed from name - for the input1 folder)
name.input02 (renamed from name - for the input2 folder)
Changing them back to just name & putting them where they belong should do it. Please let me know if this isn't working and/or you need something else. Thanks.
I did some searching online and checked the kernel config of both the ITE and non ITE and came to the conclusion that:
The ITE and the non ITE devices differ by only one aspect i.e. touchscreen.
all other aspects are the perfectly the same.
The driver source file for the ite touchscreen hardware which should have a name similar to ite_i2c.c
is not being used by any other device.(Yet to confirm)
The only solution is to ask viewsonic to release the driver source file which they should under the GNU General Public License
googlehome said:
.... solution is to ask viewsonic to release the driver source file which they should under the GNU General Public License
Click to expand...
Click to collapse
Thanks for looking into the ITE driver issues, I will do a live chat with support on Monday - requesting the source file, and let's see what happen next. There's an Escalation Survey that I can fill out in email format for their reference & resolution/followup - will provide them with my Vpad7's serial number. Their download library & database on device drivers, ec. aren't the best - and is actually blank, zero for the Vpad7 here in the U.S. market. Well, one can ask & wish for it.
I reformatted my 16G mSD card & put it back in the pad, formatted it & set up a 1MB partition with zero swap file size, checked it to confirm that ext3 is present - before rebooting it again, then enable USB support, transferred zip files back and proceeded to flash the custom ROM file. I only use the pin method to reset or exit the sub/menu with the "Go Back" button not available, so it's fine. DT's A2SD installed & so forth, but the scripts not loading/running so did the A2SD check, A2SD reinstall and, A2SD cachepart - ran these from terminal, su enabled & all is good. Free of both internal space and memoryfor the pad to run. Most users (since many seemed to be using non-ITE hardware) will not run into problems but a few of us will, hopefully these info will be useful to the newbies ....
Ext4 partition is not supported in the ite kernel and im guessing even ext3 is not.
Try formatting the sd-ext partiton to ext2.
ITE Screendriver
Hello!
I have used es file manager to view the content of sys/devices and in folder
virtual/input1 the "name" file shows "ITE TOUCHSCREEN".
Now i think it would be helpful to zip the whole folder devices because there must be the screendriver in it ?!
Related
I've created an app for dual booting automatically to Android or WM6. V2.3.2 can boot multiple version of Android on a single SD card and can be customized for text content and language. See post #2 for documentation and screenshots.
The "lite" version is a replacement for using a file explorer to run CLRCAD then HaRET, allowing Android to be started with a single tap on an icon. To install the lite version, simply un-RAR the contents to your Android folder then use a file explorer to create a Start Menu shortcut.
Please leave feedback and suggestions/questions.
French translation:http://forum.xda-developers.com/showpost.php?p=13123392&postcount=151
Documentation and Screenshots
RunDroid app v2.3.2 for HTC HD2 by Pop45398 (@ XDA Developers)
This app can start Android on an SD card automatically on boot-up or with a single tap, thus allowing for an easy dual boot to Android or Windows Mobile, and should be compatible with all versions run with CLRCAD/HaRET. It features a setup menu which allows for user customization including setting the timeout before the default OS is started, thus allowing time to access the setup menu or select a non-default OS. It is actually a MortScript and corresponding MortRunner with a custom icon. It may work on other WM6 devices.
CHANGES:
Version 2.3.2 added a new subroutine to rename the Android folder back to its original name when “Enable Builds” is selected if RunDroid had renamed the folder to Android. This eliminates the folder being renamed to Android[1]. (Thanks to crazycranky!)
Version 2.3.1 features language/text customization. By editing RunDroid.ini with a text editor the user can now change all text for desired content and language (with exception of button text, i.e. Ok/Cancel, Yes/No). There is no longer a need to edit the script for non-English ROMs where the SD card is not called “Storage Card”, a directory tree will appear for the user to locate the SD card’s root.
Version 2.2.1 features some minor changes over v2.1.1. A StartUp shortcut is no longer used for auto-launching at boot-up, instead it is launched during the init process before StartUp programs, hence the elimination of creating and deleting shortcuts from the Setup Menu. A new option to Enable Sense has been added so that Sense can be easily re-enabled if somehow not properly re-enabled during script execution. A setup.dll is now used to run Install and Uninstall scripts.
Version 2.1.1 represents a major overhaul from version 1 and features the ability to boot to a basically unlimited number of Android builds and a guided setup that walks through the setup process on initial running. It will scan all folders in the SD card's root for Android builds, indicated by the presence of HaRET.exe. It asks whether to use each build then asks if it requires renaming the folder to Android in order to run (some builds don't require being in the Android folder). A .cab file is used for installation which is now in the RunDroid folder in the root of the device. The folder name is used for displaying the build's name in RunDroid, with one caveat: if there is more than one build and one of them is named Android, that folder will be renamed to Android[1] so that the selected build folder can be renamed to Android (which is renamed back to original when another build is selected), hence descriptive folder names should be used.
INSTALLATION:
Simply copy the .cab file to the SD card and run it with a file explorer to install. Version 2.3.1 MUST be installed to the device due to hard coded addresses required for auto-launching. This also eliminates the occasional possibility of the SD card not being initialized before RunDroid is started during boot-up. If during installation the SD card is not found by the default name “Storage Card” (usually due to a non-English ROM) a directory tree will appear for choosing the correct SD card root, not Android folder (see screenshots below for an example).
OPERATION:
Start RunDroid with the Start Menu icon. On initial running, a guided setup will walk through the settings. Menus are self-explanatory (see screenshots). Selection is done by double-tapping an entry or tapping once then tapping OK. Only the main (Boot Selection) menu is timed for auto-selecting. If auto-running at boot-up is NOT desired, select “Disable AutoStart” during initial setup or later from the Setup Menu. The Timeout Delay may be adjusted to suit the user and system (see ISSUES section below). Whenever another build is added or deleted, one is no longer desired to be run, or a folder name changed, Enable Builds must be selected from the setup menu which will once again walk through the setup of builds and default OS selection (but not other settings). Builds are displayed in alphabetical order and can only be rearranged by renaming folders, like by adding a number at the beginning of folder names.
ISSUES:
Startup programs, including HTC Sense and Notifications, etc, can briefly interfere with the ability to make selections, causing the default OS to be started before menu selections can be made. To combat this, if enabled and not already started, Sense is disabled then re-enabled on app exit. The Timeout can be adjusted to help with this. If the Timeout is set too low and selecting the Setup Menu or Boot to Windows is not possible, simply re-install the .cab. If unable to boot to Windows because Android starts before the menu appears, power off the device, remove the SD card, then power on the device; if not already at the menu, start RunDroid and go to the Setup Menu and adjust the Timeout to allow more time to access the menu, then power down and re-insert the SD card.
CUSTOMIZATION:
The user interface can be customized for text size, font type, language, and size of menu selection entries by editing RunDroid.ini with a (pure text) editor such as Notepad. Once RunDroid is installed, locate the .ini file in the RunDroid folder in the root of the device (not SD card) and open or copy to PC then open.
The following variables control the font and size of menu entries:
FontSize=23
EntryScale=1.3
FontType=Tahoma
Increase or decrease FontSize to make menu selection text larger or smaller. EntryScale controls the size of menu selections, larger size makes selections easier to make. The scale is in percentage of the font size, i.e. 1.3 equals 130% of the font size. To use a different FontType than Tahoma, the desired font must be installed on the device.
In addition to descriptive variable names, to make RunDroid.ini easier for editing text content and language certain conventions are used:
Variables containing “Sel” are for menu selection entries.
......WMsystemSel=Windows Mobile
Variables Containing “Hint” are for the text that appears in the upper portion. Note that “Setup Menu” is preceded by a period and several spaces. The spaces are to center the text; the period is required because leading spaces will otherwise be ignored and the text will begin on the left instead of centered.
......SetupMenuHint=. Setup Menu
Variables containing “Txt” are for messages and questions which pop-up in new windows.
......NoBuildsMessTxt=There were no Android builds using HaRET.exe found on this SD card.
Do not change the actual variable names, for example “TimeoutMessHint=”, only the text following the “=” sign as these names are hard coded into the script and the new text will not appear.
Editing prior to completing the initial setup is preferred. Once editing is complete, copy the modified file to \RunDroid, overwriting the original. A copy of the modified RunDroid.ini file should be saved somewhere besides \RunDroid because if RunDroid is reinstalled or a newer version installed the entire folder will be deleted along with the modified file. Once reinstalled, copy the modified file to \RunDroid before completing the initial setup.
Let me try.
Works Great!
Thanks
shadowburt said:
Works Great!
Thanks
Click to expand...
Click to collapse
78 downloads (and another dozen in another thread) and finally some feedback, was beginning to wonder if it only works for me. Am glad it works for you.
My original intent was just to make a script that runs CLRCAD then HaRET by simply tapping an icon on the Start Menu instead of using a file explorer to run them separately like the chefs all say. That is what the "lite" version does. I then remembered I had routines in other scripts I'd written a few years ago that could be used to spice it up.
Hi, I´m gonna try it i a minute - sounds goode - thank you!!!
pronor
Is there interest in RunDroid having the ability to select different Android builds from the same SD card? If enough interest I can do this but because most builds require being located in the Android folder a small .ini file will be required in each build folder so that folders can be renamed then renamed back when a different build is selected. Sorry, I can't edit the original post to make it a poll so you will have to post your interest in this mod.
Pop45398 said:
Is there interest in RunDroid having the ability to select different Android builds from the same SD card? If enough interest I can do this but because most builds require being located in the Android folder a small .ini file will be required in each build folder so that folders can be renamed then renamed back when a different build is selected. Sorry, I can't edit the original post to make it a poll so you will have to post your interest in this mod.
Click to expand...
Click to collapse
Hooo man i want this +1
Pop45398 said:
Is there interest in RunDroid having the ability to select different Android builds from the same SD card? If enough interest I can do this but because most builds require being located in the Android folder a small .ini file will be required in each build folder so that folders can be renamed then renamed back when a different build is selected. Sorry, I can't edit the original post to make it a poll so you will have to post your interest in this mod.
Click to expand...
Click to collapse
That would be awsome!!!
New version
yesucan said:
Hooo man i want this +1
Click to expand...
Click to collapse
palmbluetooth said:
That would be awsome!!!
Click to expand...
Click to collapse
I've PMd y'all a download link for v2.01. The new version represents a major overhaul from v1.02 and features the ability to boot to an unlimited number of Android builds and a guided setup that walks through the process on initial running. It will scan all folders in the SD card's root for Android builds, indicated by the presence of HaRET.exe, then ask whether to use that build, then ask if it requires renaming the folder to Android to run (some builds don't require being in the Android folder). A .cab file is used for installation which is now in the RunDroid folder (when installing, be sure to select Storage Card) . The folder name is used for displaying the build's name in RunDroid, with one caveat: if there is more than one build and one of them is named Android, that folder will be renamed to Android[1] so that the selected build folder can be renamed to Android (which is renamed back to original when another build is selected). Whenever another build is added/deleted, one no longer desired to run, or folder named changed (in this case the Droid.ini file in that folder should be deleted), Enable Builds must be selected from the setup menu which will once again walk through the initial setup of builds (but not other settings).
I've tried every combination I could think of and the folder renaming process seems to work fine. Please post if you find any issues.
PS> Order of build appearance is by alphabetical order and can only be rearranged by renaming folders, for example by placing a number at the beginning of the folder name; however, more than 1-9 will screw that up because 10 will appear before 2, etc.
Pop45398 said:
I've PMd y'all a download link for v2.01. The new version represents a major overhaul from v1.02 and features the ability to boot to an unlimited number of Android builds and a guided setup that walks through the process on initial running. It will scan all folders in the SD card's root for Android builds, indicated by the presence of HaRET.exe, then ask whether to use that build, then ask if it requires renaming the folder to Android to run (some builds don't require being in the Android folder). A .cab file is used for installation which is now in the RunDroid folder (when installing, be sure to select Storage Card) . The folder name is used for displaying the build's name in RunDroid, with one caveat: if there is more than one build and one of them is named Android, that folder will be renamed to Android[1] so that the selected build folder can be renamed to Android (which is renamed back to original when another build is selected). Whenever another build is added/deleted, one no longer desired to run, or folder named changed (in this case the Droid.ini file in that folder should be deleted), Enable Builds must be selected from the setup menu which will once again walk through the initial setup of builds (but not other settings).
I've tried every combination I could think of and the folder renaming process seems to work fine. Please post if you find any issues.
PS> Order of build appearance is by alphabetical order and can only be rearranged by renaming folders, for example by placing a number at the beginning of the folder name; however, more than 1-9 will screw that up because 10 will appear before 2, etc.
Click to expand...
Click to collapse
Thanks man . will try it out ..
Hello,
Is it possible to have the link to download the latest release?
Thank you
tristano said:
Hello,
Is it possible to have the link to download the latest release?
Thank you
Click to expand...
Click to collapse
Sent you a PM.
Thank you.
Downloading.
Gonna try it
Pop45398 said:
Sent you a PM.
Click to expand...
Click to collapse
Can you please post the download link for v2.01? Thanks.
would like to try it out mate....
thanks
Could I have the link also pls ) to the latest version
Thanks)
I got problem when i install the 2.0.1 version follow the instruction . After doing set up press yes to all folder but i don't see the Android folder in the main screen only window . Reinstall delete RUNDROID folder still the some . thanks.
yesucan said:
I got problem when i install the 2.0.1 version follow the instruction . After doing set up press yes to all folder but i don't see the Android folder in the main screen only window . Reinstall delete RUNDROID folder still the some . thanks.
Click to expand...
Click to collapse
After install was there a RunDroid folder in the root of your SD card? When running the .cab file you must select to install to Storage Card, not to the Device which is the default when installing cabs. It's best if you don't have an Android folder to start with. Each build should have a meaningful name which will be renamed to Android if required, however the original name will appear in the menu, not Android. I found a problem when reinstalling because of the Droid.ini files that were created on the first install but don't think that is your problem. I have now fixed v2.02 to delete all Droid.ini files whenever a setup of builds is done, whether on initial setup or when Enable builds is selected from the setup menu. Sent PM with new link.
Pop45398 said:
After install was there a RunDroid folder in the root of your SD card? When running the .cab file you must select to install to Storage Card, not to the Device which is the default when installing cabs. It's best if you don't have an Android folder to start with. Each build should have a meaningful name which will be renamed to Android if required, however the original name will appear in the menu, not Android. I found a problem when reinstalling because of the Droid.ini files that were created on the first install but don't think that is your problem. I have now fixed v2.02 to delete all Droid.ini files whenever a setup of builds is done, whether on initial setup or when Enable builds is selected from the setup menu. Sent PM with new link.
Click to expand...
Click to collapse
Thanks man ,will try out now .And give feedback . Will hit the thanks button tomorrow. Finish used already .
Edit: It works ! thanks .
HULU FLASH 10.3 PERMANENT FIX
First off thanks to redvexx over at the Epic XDA 4G Forum http://forum.xda-developers.com/showthread.php?t=1153196 from whose flashable zip file I extracted the files and from his explanation of what his zip update does figured out how we can accomplish the fix manually. He also gives credit to imneveralOne for the foundation of his own work. Many thanks to them both!!
The fix redvexx has posted at the above link is meant to be flashed, which I tried doing using our System Recovery and Android recovery without success. After much trial and error this is what I did on my phone to get Hulu to work using Dolphin HD or Boat Mini browser; I am not responsible for what happens on your phone. And in all fairness and full disclosure I AM A SERIOUS NOOB here and this is my 1st “I did this so can you post”… if anyone can create a “cleaner” way to do this for god’s sake go for it…lol
You must have BusyBox installed (I recommend ver 1.18.2 or lower because at some point you’re gonna try one of zeppelinrox’s great scripts and that’s what he recommends and what I’ve got installed and it works)
** When renaming or creating files and folders leave off the “_” marks**
- Install Adobe Flash 10.3 from the market and make sure auto update is DISABLED
- In your Browser (I think Dolphin HD works best) you must change the UA setting to Desktop and I recommend setting “enable plug-ins” to “always on” but not sure if that is strictly required
- Create the folder “flash” in /data (as in /data/flash)
- Download the attached “DX2_GB_Hulu_Flash10.3_fix.zip” file to your phone and extract the 5 files it contains
- Copy or Move “s98fixflash.sh.txt” to /mnt/sdcard, then rename “s98fixflash.sh” (remove the .txt)
- Copy or Move “libflashplayer.so” “libstagefright_froyo.so” “libstagefright_honeycomb.so” and “libysshared.so” to the /data/flash folder you should have already created
- Using Script Manager open “s98fixflash.sh”, check “Run as Root” and “Run at Boot” then click save.
- Reboot and and you should be able to enjoy Hulu in your browser without having to pay for a VIP subscription (you will not be able to watch VIP content only the free content). Most people seem to have smoother video using a setting of 288 in Hulu; mine seems to work fine set at 360.
What does the fix do? Well, from what I understand and have read Flash 10.3 recopies the files located in /data/data/com.adobe.flashplayer/lib during each boot-up; wiping out any fix that may have been in place. The “s98fixflash.sh” script copies the “fixed” files saved in the flash folder back to the /data/data/com.adobe.flashplayer/lib (after Flash 10.3 does it's copy during boot-up) during each boot-up thus putting the fix back on every boot-up. (or I could be totally wrong and just got lucky; see NOOB admission above...)
Of course to undo this (say if it gets in the way of any future GB update) all you need do is delete or change the name of “s98fixflash”; script doesn’t run, files aren’t replaced, it’s like it never happened because, well, it didn’t…lol
In closing i hope I've done well with my 1st post and some of you folks find it useful. But if I've made a mess of it my apologies in advance.
About:
This tool is meant to easily compare the contents of two rom archives and allow easy manipulation by copying files from one rom to another and removing files from a rom archive. The idea is to specify two rom archives which have the same structure, usually something like the following:
[data]
[META-INF]
[sdcard]
[system]
flash_image
modem.bin
zImage
I made it because I would like to know which files/apks might have been removed from one rom compared to another, which isn't always clear from the descriptions. But then thought other people might find it usefull as well, so here it is
It's written in java, just extract the zip and run through run.bat (windows only) or the .jar file.
Update, version 2 added
Ok, I tested it today and seems to work fine... Was able to reflash a rom modded with this tool (file from another rom added, other files removed).
For now it just allows transferring of files between roms and removal of files from a rom archive.
How it works:
1. Load the rom-archives (zip only) using the browse buttons. If one file is selected all contents are simply listed, in case 2 files are supported only the extra files per rom are listed.
You can filter on .apk/.odex files only by using the checkbox and pressing 'Scan'.
2. By using the 'Copy >>' and '<< Copy' buttons you can copy files between roms, these entries will be colored GREEN in the respective table views.
3. By using the 'Remove files' buttons you can remove files from the roms, these entries will be colored RED in the respective table views.
4. Save the rom by pressing the proper 'Save Changes' button and specifying the name of the .zip it has to be saved to.
A progressbar will show the progress and you'll get a message telling you when it's done. It's not the fastest but it does the job. The resulting zip can then be flashed through clockworkmod (at least the one I tested it with could ).
THere are prolly some bugs when you move files back and forth and delete files in between and adding them again, etc... I just tested it with moving a few files from one rom to another and deleting a few form the target rom. This worked fine, but please let me know about bugs and issues.
Update, version 2.1 added
Allrighty, I included the data from the spreadsheet found here:
http://forum.xda-developers.com/showthread.php?t=1069924
To display information about the selected apk's in the table. This gives you a quick overview about what an apk does and whether or not you can and want to remove it. It's displayed in a little text area below the table.
I also changed it so that by default one 'view' is shown, once a first archive is selected the option to select a second one is enabled by displaying the proper buttons. Only after a second file is specified the complete view is shown (two tables, etc).
That's it again for now
Use it at your onwn risk!
Thanks this is very helpful tool.
Would love to see this further developed...two thumbs up!
Sent from my GT-I9100 using Tapatalk
Subscrived to this topic in a hope to see development on it
Sent from my GT-I9100 using xda premium
Woooww, this tool is awesome, how about adding feature like u can copy one or more file from one archive to another one so we can not only remove but also add
I hope u will improve this app further in the future!
Sent from my GT-I9100 using Tapatalk
Thanks for the comments people, good idea about moving apk's to one and another as well indeed To be continued (and always open for suggestions!)
Also updated main post, but...
I rewrote it to allow removal of files and copying of files between two rom packages, I haven't been able to test it myself yet (finished it just now and really need to catch some sleep) but will try to do so tomorrow... However, if anyone else wants to give it a shot as well please let me know and I'll send it (tomorrow evening or monday prolly). I will not put it up before it has been tested and it is about 2:30am here so time to go to sleep. If I get a chance to test and upload tomorrow I'll do so...
Will try to check this topic tomorrow again but can't promise... Busy day.
Clever tool. Will definitely watch this develop
Gr8 work pal. Please continue your development. Is really a handy tool.
Updated 1st post with new version and some instuctions/clarifications
wow. missing that tool.
And another update, added ifnormation display about the apk's using the spreadsheet from this source:
http://forum.xda-developers.com/showthread.php?t=1069924
and changed the UI a bit to make it a bit simpler...
ps. Thinking about adding a feature where you can add seperate apk's/files... Would have to think about how to add that without rewriting too much.
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.
Hi,
when i download some roms, release after release, i saw that, sometimes, only some files are changed.
if i make a little zip with only the differencies comparing two zip, and if i change updater-script
(deleting "delete system" process , deleting flashing kernel lines, generaly, at end of script and managing other things)
can someone confirm that if my updater-script never delete /system/ , i have no risk to "kill" my device ?
i have an idea about the reply but its good to have a thread about this question, no ?
i have test this following when i run a 2nd rom with dorimanx kernel.
- I search about differencies on two spirit releases rom. (using 7zip , good interface to compare and you have the total size of each folder in zip)
- On a structured folder, i keep only the new files from new release.
(apk, binary,priv-app,framework..., comparing them using size files essentialy because using the date as comparison filter never help in this way)
- i run my 2nd rom
1 - Remember us, with dorimanx kernel, when we are dualbooting roms, no matter the position rom you are run at a moment (1rst or 2nd), you will be able to see /system/ and /data/ partitions from the other rom which generaly sleep
2 - On PC, i generaly use WINSCP soft to acces easily on all structured folders of my device. (just let you know)
So,
- i launch WINSCP on PC, then i can log-in as root on my device, 2nd rom runing.
- in the interface gui of WINSCP, on left side, i see my extracted differencies structured with all files and in right side, i can see all folders from my device.
- with the interface gui from WINSCP, i can copy all that i need in /system_pri_rom/ and /data_pri_rom/ , which are the auto-mounted partitons from 1rst rom
- if DEV have moving some apks from /system/app/ to /system/priv-app/ , i move the files too. If DEV have delete some files, i delete too.
- when i reboot my 1rst rom, it booted without any trouble.
result :
the +
i dont flash anything
i dont change kernel
the -
looking for differencies between 2 zip take time
the +/-
i dont format/delete entire system and maybe with time, this can be corrupted.
If someone can help me this way by making a little script which can make the differencies with an output zip , it will be much appreciated
thanks.