Related
this from rad131304 not me, thank you
Windows 7 Sideload Instructions
Hope this helps some people - I tried to be very step-by-step about it.
Again, thank you Pokey9000, the guys and gals from the IRC channel, and everybody else for all of your hard work! 99.9% of this is an aggregation of what is already in this thread; some of it comes from nookdevs also.
You will need the following applications on your Windows 7 computer:
- cygwin (www dot cygwin dot com)
- Android Debug Bridge (ADB) - this comes with the android SDK
- Android USB Drivers - this comes with the android SDK
-- (WOQ) stands for without quotes, it means that I am giving you something between quotes to copy and paste.
-- if you see <some_odd_name> inside quotes, it means you MUST replace this with something from your specific OS instance (e.g. a drive letter, or something)
1. make sure your NC is disconnected from you computer
2. make sure your SD card is mounted on your computer (readable/browsable in explorer)
3. Install cygwin - you only need the base install AFAICT (YMMV), don't worry about the options for now.
4. download nooter at http //www dot mediafire dot com/?hugt8uxcfffpdvg
5. extract the contents to a folder in your cygwin install (standard install path is c:\cygwin)
6. Go to: Start, type in (WOQ) "compmgmt.msc" - this may require UAC elevation
7. Select "Disk Management" under storage
8. note the drive letter of the SD card and the disk number
9. Go To: Start > All Programs > Cygwin > Cygwin Bash Shell
10. At the prompt, type (WOQ): "mount //./<f>: /dev/sd<c>"
Where <f> is your drive letter, and
<c> is the letter you would get if you zero-indexed the disk number into the alphabet (i.e. 0 = a, 1 = b) **
11. press enter - there should be no output
12. at the prompt, type (WOQ): "dd if=<path_to_nooter_from_cygwin_install_folder>/nooter_sdcard_40MB.img of=/dev/sd<c>"
It will sit at this for a few minutes seeming to do nothing, be patient; you should get a response eventually that looks like:
80326+0 records in
80326+0 records out
41126912 bytes (41 MB) copied, 174.525 s, 236 kB/s
13. remove the sd card from the computer and plug it into the NC
14. power down the NC (hold power button for 15 seconds)
15. connect the NC to the computer
16. Wait for a "Composite Device" to be recognized by Windows and fail to install drivers
17. Wait for 15 seconds after the recognition
18. power down the NC
19. remove SD card ***
20. Find your android_winusb.inf file - this is located in your android-sdk install directory in the usb_driver folder. (NOTE: if you installed this in the program files folder, you will need to UAC elevate your editor to edit this file)
21. Paste the following lines into the file below both occurrences of the line ";Moto Sholes" after the ADBInterface definitions:
;B & N Nook Color
%SingleAdbInterface% = USB_Install, USB\VID_2080&PID_0002
%CompositeAdbInterface% = USB_Install, USB\VID_2080&PID_0002&MI_01
22. save the file and close
23. find your adb_usb.ini file - it is usually located in c:\users\<username>\.android\
24. add (WOQ) "0x2080" on its own line
25. power on NC - at this point, the NC should boot normally, but ADB won't be able to recognize it
26. Go To: Start > Devices and Printers
27. Right-click on Nook and select properties
28. Select the hardware tab
29. If you have something that says "Nook" and has a yellow yield sign with a "!", then continue, if not skip to 38
30. Click on "Nook"
31. Select Properties
32. Click Change Settings (may require UAC elevation)
33. Click update driver
34. Select "browse for driver software on your computer"
35. Browse to the android-sdk/usb_driver folder
36. click next
37. You should be done; skip to 47 (I have no idea if this is correct - i pieced it together from somewhere in this as I did not get Nook to appear in the Device Functions List)
38. If you don't have a "Nook" Device Function, click on "USB Mass Storage Device"
39. Select Properties
40. Click Change Settings (may require UAC elevation)
41. Select the Driver Tab
42. Click Uninstall
43. Click OK
44. Disconnect NC
45. Reconnect NC
46. You should be done (this is different from my previous instructions on how to uninstall the NC USB drivers, I have not tested it so YMMV)
47. Go To: start > run > cmd
48. type (WOQ): "cd <path_to_android_sdk>\tools"
49. type (WOQ): "adb.exe kill-server"
You should get something like:
* server not running *
50. type (WOQ): "adb.exe remount"
You should get something like:
* daemon not running. starting it now *
* daemon started successfully *
remount failed: No such file or directory
51. You are done configuring to sideload
From here you should be able to sideload from ADB.
by rad131304
Just to throw it out there...
Does this cause a PERMANENT change to the Color Nook?
Edit: thank you for posting this
I believe it was mentioned in a previous post that if you did a factory reset (power off completely, then hold power, nook button and vol up) that it would reset the Nook back to non rooted factory defaults. Can anyone else confirm this?
HeroHTC said:
Just to throw it out there...
Does this cause a PERMANENT change to the Color Nook?
Edit: thank you for posting this
Click to expand...
Click to collapse
Are these instructions for Win 7 64 or 32 bit?
BTW, how does one go back or to menu without those buttons?
RichTJ99 said:
Are these instructions for Win 7 64 or 32 bit?
BTW, how does one go back or to menu without those buttons?
Click to expand...
Click to collapse
believe this was done on win 64, some buttons are located in or below menu bar, some will depend on launcher.
I also wanted to mention this
http://forum.xda-developers.com/showpost.php?p=9517050&postcount=863
NOTE: I have not even opened my nook box yet, its still sealed but I am getting ready. Just waiting on an email solution.
Do you think a partitioned SD card woul dprevent this from working?
I'm pretty sure my card is partitioned....I read something in the BIG THREAD about departitioning a card.....
I can't get this to work for me and I just thought my card might be the culprit.
Thanks
I cannot find the file listed in step 23. This is the only thing keeping me from root. Also when I plug my nc in, the light on the cord is amber instead of green. It tells me that adb drivers are installed. But it won't show up as a folder in my computer any more. How do I add files without removing the SD card and plugging it into my computer.
Sent from my HERO200 using XDA App
RichTJ99 said:
Are these instructions for Win 7 64 or 32 bit?
BTW, how does one go back or to menu without those buttons?
Click to expand...
Click to collapse
I did this on 32 bit - AFAIK, they don't support cygwin on 64 bit yet (it might run though, but YMMV).
The back and menu buttons are soft-buttons. The nook for some reason hides them by default in a bunch of apps.
sudermatt said:
Do you think a partitioned SD card woul dprevent this from working?
I'm pretty sure my card is partitioned....I read something in the BIG THREAD about departitioning a card.....
I can't get this to work for me and I just thought my card might be the culprit.
Thanks
Click to expand...
Click to collapse
IIRC, somebody said that in the big thread, too.
oakleyrdc said:
I cannot find the file listed in step 23. This is the only thing keeping me from root. Also when I plug my nc in, the light on the cord is amber instead of green. It tells me that adb drivers are installed. But it won't show up as a folder in my computer any more. How do I add files without removing the SD card and plugging it into my computer.
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
It could be hidden (so you'll have to change the hidden files and folders setting), or installed in another user directory (like Admin).
If I run Windows XP, how many of these steps would change? I'm thinking it might need its own thread.
I did mine on Win 64bit using winimage. Everything is working fine.
rad131304 said:
I did this on 32 bit - AFAIK, they don't support cygwin on 64 bit yet (it might run though, but YMMV).
Click to expand...
Click to collapse
XP
cabbieBot said:
If I run Windows XP, how many of these steps would change? I'm thinking it might need its own thread.
Click to expand...
Click to collapse
plus 1 for XP
So once your rooted, do you need to do anything special to install apk files that you download from dropbox? Is superuser ready?
i cant find the android_winusb file in the windows XP version of the android SDK. is there a different one that does the same?
EDIT: it appears the sdk is not split between versions of windows
im going to reinstall the sdk and see maybe if i accidently deleted it at some point
cabbieBot said:
If I run Windows XP, how many of these steps would change? I'm thinking it might need its own thread.
Click to expand...
Click to collapse
Very little changes; the only thing I can tell you off the top of my head is that
C:\users\<username>\.android\
Becomes
C:\documents and settings\<username>\.android\
Also, I don't know where, besides device manager, that you could locate the nook like you do in devices and printers - it may show up in my computer, also in scanners and cameras in the control panel - you can always right click a drive, select properties, select the hardware tab, select the b&n storage device, click properties, select the driver tab and uninstall from there....
HTH
EDIT: To delete the NC through device manager:
start > run > compmgmt.msc
browse to Device Manager
Expand Universal Serial Bus Controllers
Select USB Mass Storage Device (there may be multiple)
Right-Click and select "properties"
select the details tab
in the dropdown, select "Hardware Ids" - if this says "USB\VID_2080&...." then this is the NC
click ok
right Click again and select uninstall
disconnect NC from computer
reconnect NC to computer
NC re-finds all drivers, including ADB
start > run > cmd
cd <android-sdk-dir>\tools
adb.exe remount
Fixed instructions!
that's what I get for writing this crap at 1 in the AM ... I left out two INSANELY important steps at step 11.
SORRY!!!!
Windows 7 Sideload Instructions
Hope this helps some people - I tried to be very step-by-step about it.
Again, thank you Pokey9000, the guys and gals from the IRC channel, and everybody else for all of your hard work! 99.9% of this is an aggregation of what is already in this thread; some of it comes from nookdevs also.
You will need the following applications on your Windows 7 computer:
- cygwin (http://www.cygwin.com)
- Android Debug Bridge (ADB) - this comes with the android SDK
- Android USB Drivers - this comes with the android SDK
-- (WOQ) stands for without quotes, it means that I am giving you something between quotes to copy and paste.
-- if you see <some_odd_name> inside quotes or a code block, it means you MUST replace this with something from your specific OS instance (e.g. a drive letter, or something)
make sure your NC is disconnected from you computer
make sure your SD card is mounted on your computer (readable/browsable in explorer)
Install cygwin - you only need the base install AFAICT (YMMV), don't worry about the options for now.
download nooter at http://www.mediafire.com/?hugt8uxcfffpdvg
extract the contents to a folder in your cygwin install (standard install path is c:\cygwin)
Go to: Start, type in (WOQ) "compmgmt.msc" - this may require UAC elevation
Select "Disk Management" under storage
note the drive letter of the SD card and the disk number
Go To: Start > All Programs > Cygwin > Cygwin Bash Shell
At the prompt, type:
Code:
mount //./<f>: /dev/sd<c>
Where <f> is your drive letter, and
<c> is the letter you would get if you zero-indexed the disk number into the alphabet (i.e. 0 = a, 1 = b) **
press enter - there should be no output
REMOVE SD CARD FROM PC
INSERT SD CARD INTO PC
at the prompt, type:
Code:
dd if=<path_to_nooter_from_cygwin_install_folder>/nooter_sdcard_40MB.img of=/dev/sd<c>
It will sit at this for a few minutes seeming to do nothing, be patient; you should get a response eventually that looks like:
80326+0 records in
80326+0 records out
41126912 bytes (41 MB) copied, 174.525 s, 236 kB/s
Click to expand...
Click to collapse
IF THIS COMPLETES ALMOST IMMEDIATELY, YOU PROBABLY HAVE AN ERROR
remove the sd card from the computer and plug it into the NC
power down the NC (hold power button for 15 seconds)
connect the NC to the computer
Wait for a "Composite Device" to be recognized by Windows and fail to install drivers
Wait for 15 seconds after the recognition
power down the NC
remove SD card ***
Find your android_winusb.inf file - this is located in your android-sdk install directory in the usb_driver folder. (NOTE: if you installed this in the program files folder, you will need to UAC elevate your editor to edit this file)
Paste the following lines into the file below both occurrences of the line ";Moto Sholes" after the ADBInterface definitions:
Code:
;B & N Nook Color
%SingleAdbInterface% = USB_Install, USB\VID_2080&PID_0002
%CompositeAdbInterface% = USB_Install, USB\VID_2080&PID_0002&MI_01
save the file and close
find your adb_usb.ini file - it is usually located in c:\users\<username>\.android\
add (WOQ) "0x2080" on its own line
power on NC - at this point, the NC should boot normally, but ADB won't be able to recognize it
Go To: Start > Devices and Printers
Right-click on Nook and select properties
Select the hardware tab
If you have something that says "Nook" and has a yellow yield sign with a "!", then continue, if not skip to 40
Click on "Nook"
Select Properties
Click Change Settings (may require UAC elevation)
Click update driver
Select "browse for driver software on your computer"
Browse to the android-sdk/usb_driver folder
click next
You should be done; skip to 49 (I have no idea if this is correct - i pieced it together from somewhere in this as I did not get Nook to appear in the Device Functions List)
If you don't have a "Nook" Device Function, click on "USB Mass Storage Device"
Select Properties
Click Change Settings (may require UAC elevation)
Select the Driver Tab
Click Uninstall
Click OK
Disconnect NC
Reconnect NC
You should be done (this is different from my previous instructions on how to uninstall the NC USB drivers, I have not tested it so YMMV)
Go To: start > run > cmd
type:
Code:
cd <path_to_android_sdk>\tools
./adb.exe kill-server
You should get something like:
* server not running *
Click to expand...
Click to collapse
if adb.exe is not in tools (or tools does not exist), try:
Code:
cd <path_to_android_sdk>\platform-tools
./adb.exe kill-server
type:
Code:
./adb.exe remount
You should get something like:
* daemon not running. starting it now *
* daemon started successfully *
remount failed: No such file or directory
Click to expand...
Click to collapse
You are done configuring to sideload
From here you should be able to sideload from ADB.
To sideload an app, simply do the following:
Code:
./adb.exe install <app_name>
Thanks Rad!
im going insane, ive completely updated the SDK but i cant find this damn android_winusb file
When you updated the SDK, did you install the USB drivers also? If you did, that file should be in whatever directory you installed the SDK in under the usb_driver subdirectory.
cabbieBot said:
im going insane, ive completely updated the SDK but i cant find this damn android_winusb file
Click to expand...
Click to collapse
I'm an idiot, I was certain the USB Drivers were installed. Done and done now, sheesh what a waste of time!
now to hunt for adb_usb which is being a pain to find too. Has anyone found adb_usb on XP?
I can see the folder C:\documents and settings\<username>\.android\ but theres two folders in there for AVD and AndroidDesktopNotifier. Maybe if someone can upload the adb_usb file I can just throw it in the folder and cross my fingers?
Current version: !IMEIme 2.2.0.4
Bug Fix
Fixed bug in use previous patch that could result in variable used before declared error.
Changed processing order when custom patches were to be used
The program will now process custom patches prior to editing framework.jar and build.prop edits. With new kernel patches requiring a new build.prop users would lose build.prop edits if the kernel was included in custom patches, the program will now patch any user modifications, then process IMEI generation and build.prop edits.
Updated to work with ROMs that do not include GSMPhone.smali
Recently, many ROMs are not including GSM phone utilities in framework.jar. I have added testing for missing GSMPhone.smali and patching via TelephonyManager.smali if necessary.
UPDATED FILES UPLOADED
MANY of the support files have been updated to the newer versions (smali, baksmali, adb and components).
I encourage you to delete all files in your existing IMEI Generator folder and use the new !IMEIMe.exe to generate the files necessary.
The devices.dat file if you've used the previous version has several issues that prevents the device model from being correctly patched on many of the devices. This has been fixed here and in the device list thread.
There is a known issue with the GUI when your screen settings are set at 125% in Control Panel - Appearance and Personalization - Display... I will work on fixing that in the next release.
Bug reporting thread for !IMEIme
Device list thread
New features:
Will patch GSMPhone.smali if present in framework... patches TelephonyManager.smali otherwise.
I chose this method since more ROMs are coming out for wifi tablets that do not have GSM phone information included in framework.jar. I was playing with CM10.1 and discovered GSMPhone.smali is not present, thus I was getting unable to patch GSMPhone.smali error, and there was no patching for an IMEI. In all honesty... this should be irrelevent, since IMEI is only utilized in cellular communications on GSM phones... however... some applications MAY (xda free does) require an IMEI to work, even on wifi only devices.
ODEX files still in the works
odex file support... I think this solution will work on odex file systems as long as the patching is done on the ROM prior to flashing to device (anyone using odexed system please let us know) and I am working on in place patching on odexed systems... however, I am not completely comfortable since there is a lot of work done by the device itself during odexing of the modified files... I am very hesitant since any mistake could render a bricked device and I don't have a system to test with prior to release.
Previous Important Changes
The new version of the IMEI Generator will no longer overwrite your existing devices.dat file with the current. To use new devices.dat file, delete the old one prior to running the program, or download the new one and unzip it in the IMEI Generator directory.
Device Communications not necessary in certain situations
If you select to Update ROM, using Serial Number based IMEI and do not select Encrypt IMEI, the program will no longer need to communicate with the device when performing its tasks. The framework.jar patch will not hard patch the IMEI in this situation as before. This is useful for patching a ROM for distribution to multiple people, since they will all maintain unique IMEI's. This is accomplished with the following change in the framework.jar
Code:
/com/android/internal/telephony/gsm/GSMPhone.smali
.method public getDeviceId()Ljava/lang/String;
[b]changed[/b] iget-object v0, p0, Lcom/android/internal/telephony/gsm/GSMPhone;->mImei:Ljava/lang/String;
[b]to[/b] sget-object v1, Landroid/os/Build;->SERIAL:Ljava/lang/String;
prior to patching in code to prepend "0"
.method public getDeviceSvn()Ljava/lang/String;
[b]changed[/b] iget-object v0, p0, Lcom/android/internal/telephony/gsm/GSMPhone;->mImeiSv:Ljava/lang/String;
[b]to[/b] sget-object v1, Landroid/os/Build;->SERIAL:Ljava/lang/String;
prior to patching in code to prepend "0"
To try to explain the above a little...
The above is always changed, no matter what IMEI generation method you select...
If you select Serial Number and New Type IMEI and not Encrypt: no other patching is done for the IMEI... this can be implemented on many devices, since each will have a unique serial number.
If you select Serial Number and do not select New Type: additional code is added to format the IMEI to the old standard ("00-" and "-"s)... this can be implemented on many devices for same reason.
If you select MAC Address or Encrypt (or both): additional code is added that results in the IMEI being hard coded, this makes it very much device specific.
If you select MAC Address or Encrypt (or both) and do not select New Type: additional code is added that results in the IMEI being hard coded as well as code to format the IMEI, this makes it very much device specific.
Use Custom Patch NOTE: This is only used when patching a ROM
This is going to take some major explanation, since I ran into so many possible scenarios...
One thing of note... the only additional lines added to updater-script will be for files in the base directory
The order of processing is:
1. Original ROM updater-script and files
2. Custom Patch zip file
3. Custom Patch folder
The program will utilize folders (from Patch zip file or Patch folder itself) named modboot, modsys, or system (not case sensitive in windows) as well as files in the base folder
Any files in modboot will be moved to the root of the **ROM**-IMEI.zip file and lines added to updater-script as needed
Any files in modsys will be moved to the system directory of the **ROM**-IMEI.zip file
If Custom Patch is checked...
/META-INF/com/google/android/updater-script is extracted from the ROM
the program will ask you to select the Custom Patch Folder
If there is a zip file present in the folder the program will ask if you want to use it
You have 3 options, "Yes", "No" or "Cancel"
Yes = Use the zip file
No = Don't use it, select another
Cancel = Don't use a zip file
If you use a zip file, it will extract the zip file and process the updater-script in it for any additional lines needed
After the above, any non-zip files and modboot, modsys and system directories in the Patch Folder will be processed
I chose this order so you can have a "go to" patch zip file, and test other additions by using the file, folder options prior to including them in the zip.
Example here:
I have my custom patches in folder /CM7/UserMods with these contents:
/META-INF
/modboot
/modsys
patch.zip
The program processes patch.zip first, then overwrites any files with the files in modboot and modsys
It also processes /META-INF/com/google/android/updater-script for any lines extracting files to /boot and adds them to the original ROM updater-script if not already there.
It then adds lines for any files originally in /modboot to updater-script to extract them to /boot
"New IMEI Type" of IMEI which no longer has the "-"s in it, but maintain backward compatibility for those who already have IMEI's generated or prefer the old style. When the new type is selected in the GUI:
NOTE: Per the IMEI standards... Using a single 0 prepended to the IMEI indicates a TEST IMEI for a country with 3 digit international code... while it should have no implications to us since we are not on a cell... it may provide potential country validity issues... I will monitor this and resort to 00 prefix in the new type of IMEI if necessary.
ADDITIONAL NOTE: Per the IMEI standards... For devices without an IMEI, they are to provide a unique serial number to be used... This program modifies framework.jar to allow this.
I am now patching framework.jar in the /com/android/internal/telephony/gsm/GSMPhone.smali file instead of /android/telephony/TelephonyManager.smali (this change is what allows the information to display in the about tablet information)
I am renaming and patching 2 functions... getDeviceID() and getDeviceSvn()
By patching the two functions in this file... the IMEI now shows in Settings... About Tablet... Status... no longer have to use external program or dial *#06# to verify the device is patched.
getDeviceID() shows it in IMEI
getDeviceSvn() shows it in IMEI SVN
You can rename or copy !IMEIme.ini to IMEIme.ini and the program will work.... useful for *nix users and probably mac users... since they have issues with special char actors (!)... While I like to use it in windows to keep the executable and ini file at the top of the file list in windows explorer... anyway...
The program looks for IMEIme.ini first and uses it if present... if it is not... it then looks for !IMEIme.ini (which will be there... because the program installs the generic !IMEIme.ini if it isn't ) This also provides a good way to keep your ini.. and see the new settings in the compiled in ini.
GUI selection and related ini setting
GUI: New IMEI Type
INI Setting:
New_Type =
; If 0 then the old type of "00-XXXXXX-YYYYYY-ZZZ" will be used
; If 1 then the new type of "00XXXXXXYYYYYYZZZ" will be used
BUG FIX
No known or reported bugs to work out.
!IMEIme.ini file default settings and explanation:
Code:
;The setting options are 1 (use the option) or 0 (don't use the option)
;WiFi IP Address can be set to your Nook's IP address here to a default to use
;IMEI can be set to a default here... you can also set the seed you use for generation
;Setting Device_Manufacturer to anything will result in an edit to build.prop setting the entered manufacturer
;IF Device_Manufacturer is NOT blank then:
;Setting Manufacturer_Device to anything will result in an edit to build.prop setting the entered device
;
;NOTE: ONLY Device_Manufacturer is necessary for this edit... there have been no software that appears to
; require a device edit
;
;Setting LCD_Density will result in build.prop edit for this setting regardless of Device_Manufacturer setting
;
;Set all options in [Settings] section at the bottom
[Settings_Explained]
Use_In_Place = 1
; If 0 Disable In Place patching... useful for those who always update AOSP ROM files and never patches on device framework.jar
; If 1 Enables In Place patching if ADB is working
Use_Previous_Patch = 0
; If 0 Ignore IMEI.fix
; If 1 AND IMEI.fix exists... use it for patching
Use_Serial_Number = 1
; If 0 then do not base IMEI off of Device Serial Number
; If 1 then base IMEI off of Device Serial Number
; NOTE: This takes priority over Use_MAC_Address
Use_MAC_Address = 0
; If 0 then do not base IMEI off of Device MAC Address
; If 1 then base IMEI off of of DeOvice MAC Address (last 5 hex words) (2 bytes = 1 hex word)
; 0A is converted to 010, FF is converted to 255 etc.
; NOTE: Use_Serial_Number takes priority
Use_Manual_Input = 1
; If 0 then Manual Input disabled
; If 1 then Manual Input enabled
Encrypt_IMEI = 1
; If 0 then uses actual data for IMEI... i.e. Serial Number (last 15 digits) or MAC Address (last 5 hex words) is actual IMEI
; If 1 then program encrypts data for IMEI generation... hiding actual Device data
New_Type = 1
; If 0 then the old type of "00-XXXXXX-YYYYYY-ZZZ" will be used
; If 1 then the new type of "00XXXXXXYYYYYYZZZ" will be used
Use_ADB = 1
; If 0 then ADB is disabled... this will prevent In-Place updating from working all together
; If 1 then ADB is enabled... In-Place will work... IF adb is working on your device
; NOTE: This takes priority over Use_ADB(usb) and Use_ADB(WiFi)
Use_ADB(usb) = 1
; If 0 then ADB via USB connection is disabled... I use this since some ROM's have Debug Mode issues
; If 1 then ADB via USB is enabled and attempted first
; NOTE: Use_ADB takes priority over Use_ADB(usb) and Use_ADB(WiFi)
Use_ADB(WiFi) = 1
; If 0 then ADB via WiFi connection is disabled
; If 1 then ADB via WiFi is enabled... I use this since some ROM's have Debug Mode issues
; NOTE: Use_ADB takes priority over Use_ADB(usb) and Use_ADB(WiFi)
Clean_Up = 1
; If 0 then the program will leave all support files when cleaning up and exiting
; If 1 then the program will delete all support files when cleaning up and exiting if none of them
; existed at program start
Include_Patch = 0
; If 0 then custom patches is disabled
; If 1 then the program will prompt for custom patches to include
Device_Manufacturer =
; If blank then the program will not edit build.prop
; If anything other than blank the program will edit build.prop to include manufacturer
Manufacturer_Device =
; If blank then the program will not include device in build.prop edit
; IF anything other than blank the program will include device in build.prop edit
; NOTE: No build.prop edit will occur if Device_Manufacturer is blank
Device_Model =
; If blank then the program will not include model in build.prop edit
; IF anything other than blank the program will include model in build.prop edit
; NOTE: No build.prop edit will occur if Device_Manufacturer is blank
Build_Fingerprint =
; If blank then the program will not include Build Fingerprint in build.prop edit
; IF anything other than blank the program will include Build Fingerprint in build.prop edit
; NOTE: This edit will occur even if Device_Manufacturer is blank
LCD_Density =
; If blank then the program will not include LCD Density in build.prop edit
; IF anything other than blank the program will include LCD Density in build.prop edit
; NOTE: This edit will occur even if Device_Manufacturer is blank
WiFi_IP_Address =
; You can enter the default Device IP address here... especially useful if you are only using this on one device...
; or if you keep seperate folders for each device you use (!IMEIme.exe and !IMEIme.ini must be in each folder)...
; i.e. folder for "sister" containing the program and ini file at minimum.
; If blank the program will prompt you for the IP address of the device to establish ADB WiFi connection
IMEI =
; Enter a base 10 (integer) and it will be used as the IMEI (duplicated until 15 digits is reached)
; Enter your "seed" and the program will generate an IMEI based off of it
; NOTE: If you try to generate the old GENERIC IMEI the program will not do it
[Settings]
Use_In_Place = 0
Use_Previous_Patch = 0
Use_Serial_Number = 1
Use_MAC_Address = 0
Use_Manual_Input = 1
Encrypt_IMEI = 0
New_Type = 1
Use_IMEI(15) = 0
Use_ADB = 1
Use_ADB(usb) = 1
Use_ADB(WiFi) = 1
Clean_Up = 1
Include_Patch = 1
Device_Manufacturer =
Manufacturer_Device =
Device_Model =
Build_Fingerprint =
LCD_Density =
WiFi_IP_Address =
IMEI =
Credits:
mthe0ry: Credit for the original IMEI patches released for us Nookers(TM). His original thread is here...
martian21: Took mthe0ry's work and maintained it for releases of CM7, upeating it for each nightly that needed a new one. Martian21's thread.
HacDan on irc.freenodes.net #nookcolor for helping me figure out patching GSMphone.smali instead of TelephonyManager.smali
Thank you's:
paleh0rse: I believe was the first to download and test this program... I think the first bug report too... helped many users with suggestions regarding their apps.
mr_fosi: Continues testing and reporting despite no need to. Tested a few private beta builds to help iron out a significant issue. Also providing information regarding Phone App *#06# IMEI test.
martian21: Set the wheels turning. Provides invaluable feedback and suggestions. He is an invaluable tester and Q&A guy. Thanks for dangling that bait
mellopete: Provided the very first bug report... prompted me to include necessary files in the program itself.
TheMainCat, 12paq and frankusb: Provided bug reports leading me to look at why some Windows versions didn't run the program initially.
Nayla1977: Bug report regarding a mistyped EndIf in my source.
jdexheimer: Bug report that lead me to find a problem with folders with spaces in them.
LinuxParadigm: Bug report regarding missmatching If - EndIf's.
BitingChaos: first public post to get me back on target.
dillweed, garrisj and many others: for PM's indicating the importance of this solution.
lemdaddy for reporting the bug that we tracked down to the java version and reporting back that it was the java version causing issues.
adusumilli for reporting the bug where IMEI was generated as "00-cat: c-an't o-pen"
topcaser for being persistent enough with the bug causing In-Place to fail in certain situations.
HacDan on IRC for leading me in the right direction to impliment the patching of GSMphone.smali.
We are all adults, if we break our toys... we only have ourselves to blame and we may have to buy new ones... (this will NOT break your Nook... I PROMISE you that! but it may break some of your apps... more on that later in post)
BUG REPORTING:
This program was initially ineteded to generate a unique IMEI based on your device S/N and update Dev's install zip files... it has become so much more, and as such there are many functions involved in this process.
Due to the complexity the program has taken on... far beyond what I initially intended... to report bugs please try to use the following as a template:
Function attempting: i.e. Updating ROM... In Place Upgrade... Update framwork saved on computer... etc.
Error Messages: any error message you receive... or the last message you saw prior to the issue.
End result: i.e. GSMphone.smali updated, ROM not... GSMphone.smali updated framework.jar not... etc....
Environment: ROM in same folder as IMEIme.exe... ROM on same drive as IMEIme.exe... ROM on different drive... etc. (same for framework if updating framework instead)
!IMEIme.ini settings: you can put your entire ini file if you'd like.
If you could take notes of EXACTLY what which selection in the GUI you have selected and any buttons you click on which prompt it would be EXTREMELY helpful...
As I said, this program has taken on functions I initially had not imagined including... the more features added, the more complex testing and tracking bugs becomes... I don't want to include a bunch of messages just for the sake of letting you know where in the code you are... would not be beneficial to you... more buttons to click for no reason, etc.
The more detailed you can be, the quicker I can see what is happening... otherwise I have to try to duplicate what I think you are doing when you get the error.
mr_fosi and martian21 have been very tedious in reporting bugs... I greatly appreciate their testing despite not needing to, and the manner in which they document what is going on....
Everyone should click "Thanks" on their bug report posts... they have been instrumental in getting the program where it is so far.
Background:
Some developers require a unique number that is supposed to be provided by hardware manufacturers that is unique to every device. This unique number (IMEI) is extremely important in devices utilizing cellular communications.
Since B&N has not registered IMEI numbers for the Nooks, the AOS's we are using do not acquire it as they do in other Android devices.
The developers that require a unique IMEI have been less than receptive of our devices and past methods to provide functionality to utilize their apps.
I decided to provide what I believe to be a viable solution to this problem.
What this program is:
It is a method to provide a unique IMEI (with reasonable certainty) for our Nooks.
It IS intended to be a supplement until IMEI is addressed in dev's ROM's.
It IS viable for Froyo... CM7... CM9... CM10...Honeycomb... MIUI.... AOKP... and others.
I can't think of any reason it will not work with ANY ROM you choose to utilize... if you run across one... just let me know and I'll see if I can't fix that.
What this program is not and does not do:
This is not a perfect solution to our Nook specific issues. Let me make it PERFECTLY CLEAR there is NO PERFECT SOLUTION We are generating an IMEI from something else... I use TEST IMEI patterns based off of our device serial number, to ensure apk devs wouldn't come down on us.
It is not targeting any specific AOS.
It is not guaranteed to be accepted by any other developers.
It is not intended to be the end all, beat all solution.
It is not intended to dissuade other developers from providing what they feel is a better method.
It will not cause any programs to show in the market. That has to be dealt with via APK developers and/or build.prop Manufacturer strings.
Potential issues:
There is NO legitimate solution to the IMEI issue we Nookers (TM) face... unless a group desires to register a block of them for our use... thus I am generating TEST IMEI's... ideal... no, but the only method available to us.
While I feel, with significant certainty, there will be no negative consequences from apk devs in general, I cannot speak for them, or their logic. This can easily be disabled by them again. That is on them, not me or us. By the same token, they can decide to stop providing their service for cause, I still have no control over that.
Above, I emphasize “with reasonable certainty” due to the fact that, in theory, you can wind up with an IMEI that 9 other Nooks that use this software has. That can only happen if the other 9 owners use this program and have a serial number within the same 10 as yours. This is even less likely with the New IMEI Type since it is using the right most 16 digits of a device serial number (and we know they all start with 2)
If everyone who has the same beginning 15 digits utilizes this program to generate an IMEI, you will all wind up with the same IMEI. Given the number of Nooks out there compared to the number of user's hacking them.... I find it extremely difficult to believe, with a reasonable certainty, that any 2 (much less 10) devices would ever wind up with the same IMEI generated by this program. This is prevented when using the New IMEI Type
What this program does/is capable of:
It allows you to extract framework.jar from a developers update zip file.
It will allow you to pull framework.jar from your Nook or use an existing framework.jar already stored on your computer.
It will generate an IMEI based on your Nook's serial number (or MAC Address) if adb is working on your system. If you have issues running adb via USB (ADB(USB)), it provides the opportunity to utilize adb via WiFi (ADB(WiFi)) for any computer-device communications.
It will provide you a method to manually input your serial number if you cannot connect to the device via adb. You can also input a “seed” (easy to remember word or phrase) and generate an IMEI based on the ASCII codes of the text you enter.
It will edit /com/android/internal/telephony/gsm/GSMPhone.smali to rename any existing getDeviceId() and getDeviceSvn() function to getDeviceId2() getDeviceSvn2() and append the patch to end of that file. NOTE: When the program "smali's" the resulting GSMphone.smali... it relocates the appended function to be before the renamed function.
It will save the patch as IMEI.fix, thus allowing you to utilize it for subsequent runs of the program. A caveat to this is... if you run it from the same folder on a friend's Nook... it will overwrite your original one if it is in the same folder or they will have the same IMEI as you do if you use Previous Run.
It will offer to push the patched framework.jar to your Nook... IF you opted to pull framework.jar from your Nook AND adb successfully worked to do that. This facilates in place upgrading.
It will backup the existing developers zip file appending “-IMEI” to it, distinguishing it is one this program has been used on. It will update this file, not the original developers file.
If there are issues with file names that become duplicate in a case insensitive OS such that windows is, it will warn you of this case and not remove the updated framework.jar to facilitate manual updating of the zip file.
Caveats:
This program is known to work on Java version 1.6.0_23 and known NOT to work on version 1.6.0_17 or earlier. If your system seems to work fine... but the nook does not give you an IMEI number... check your java version by typing this in a DOS window (start-run and type in cmd):
java -version
this will tell you the version of java you are running.
Java must be on your system. It must be in your system's path statement, or this program must be in the java/bin folder. It is possible that you must have java 32 bit version, this is being researched.
It will very likely break your swype, or any other app that utilizes IMEI for validation and you have used previous methods to circumvent their validation process.
It will likely break the same software if/when developers include a fix to the Nook IMEI situation in their AOS. Unless you opt to use this method again on their AOS to ensure you maintain the IMEI you used my program to generate.
Since I have opted to utilize test formed IMEI's to prevent duplicating someone's “real device” IMEI, software developers can easily shut us down again. That is their option. I am trying to provide a solution that is acceptable to both sides of the fence.
Closing statement:
As I desire to make this program as beneficial as possible... PLEASE provide any feedback and/or bug reports... just don't continue to push your ideals once it has been discussed... beating dead horses gets tiresome and just wastes precious time.
112 downloads of 2.2.0.3 with bug when pervious fix was selected
1686 downloads of 2.2.0.2 with no bugs reported
141 downloads of 2.2.0.1 with CM10 in place bug that would cause BBSOB and never boot
197 downloads of 2.2.0.0 (that actually appeared to be 2.1.0.4 in the zip) with a few minor bugs... mostly in custom patching
648 downloads of 2.1.0.3 with known GT for GameLoft issues
1123 downloads of 2.1 with no known bugs
182 downloads of 2.0a with a Generic IMEI bug
1919 downloads of 1.9 with no bug reports
3131 downloads of 1.8 with all bug reports being for non-nook devices
80 downloads of 1.7 with no bug reports
600 downloads of 1.6 with a couple of reports of In-Place update bug
880 downloads of 1.5a with 0 bug reports
148 downloads of 1.5 with a bug that could result in IMEI being generated without being properly formed.
36 downloads of 1.4 with a bug that could result in IMEI of "cat: can't open".
258 downloads of 1.3 with 0 bug reports... time to move on with next feature.
1618 downloads of 1.1 and the only bug noted has been tracked to the user's Java version.
12,758 downloads prior to the current version.
Bug reporting thread for !IMEIme
Device list thread
Looks like I have something new to mess with tomorrow night... thanks for working this, we owe ya!
Been looking forward to this! Thanks for your hard work DizzyDen.
Tested it out however it isn't finding 7zip. I've tried both the 64-bit and the 32-bit version (on 64-bit Windows 7). I'm probably doing something wrong if so please feel free to enlighten me
Martian21
martian21 said:
Been looking forward to this! Thanks for your hard work DizzyDen.
Tested it out however it isn't finding 7zip. I've tried both the 64-bit and the 32-bit version (on 64-bit Windows 7). I'm probably doing something wrong if so please feel free to enlighten me
Martian21
Click to expand...
Click to collapse
It wasn't you... there's something weird with the API to the fileopendialog that changes the working directory... a TEMPORARY work around is to copy the zip file to the folder you are running the program from.
Updating to beta 2 to auto extract support files on run.
Beta 2 is up... OP updated... note the bold text... for now the zip file must be in the same folder as IMEIme.exe
That will be fixed shortly.
Updated to beta 3. OP updated.
Fixed file browse for update file.
Improved cleanup behind itself before exiting...
removes helper files
removes framework.jar
removes classes.dex
removes out folder
removes system folder (the one used to add framework.jar to the zip file)
Still debating ability to allow manual input of the IMEI or a serial number... but those that want to do it will probably figure out how to do it manually... its REALLY not that hard.
Will add random IMEI generation as an option. The only purpose I see for this is for those who don't want to use the generic IMEI and cannot get adb working... even with the included adb in this program.
Feedback and bug reports are welcome and will help improve the program.
Thank you for this
I had to copy my AdbWinApi.dll for it to work. It did not put the new framework.jar in the zip though. It made the files, but didn't update the zip. I moved it to the root of my drive and ran it as administrator, but it still didn't update the zip. I am using Windows 7 x64. I used the IMEI.fix file and updated the zip myself. Thanks again for this nice tool.
mellopete said:
I had to copy my AdbWinApi.dll for it to work. It did not put the new framework.jar in the zip though. It made the files, but didn't update the zip. I moved it to the root of my drive and ran it as administrator, but it still didn't update the zip. I am using Windows 7 x64. I used the IMEI.fix file and updated the zip myself. Thanks again for this nice tool.
Click to expand...
Click to collapse
Did you use something prior to b3 ?
There was an issue I discovered that was preventing appending IMEI.fix to TelephoneProvider.smali that was fixed in b3.
I did my development on windows64 so that shouldn't be an issue.
As for the dll... I hadn't experience issues with that... but I can certainly add it to the program.
Both adb dll's will be included in all releases after b3.
Good job!
Can you explain more about how rom is being affected?and what to check?
Sent from my phiremod for Nook using Tapatalk
DizzyDen said:
Did you use something prior to b3 ?
There was an issue I discovered that was preventing appending IMEI.fix to TelephoneProvider.smali that was fixed in b3.
I did my development on windows64 so that shouldn't be an issue.
As for the dll... I hadn't experience issues with that... but I can certainly add it to the program.
Both adb dll's will be included in all releases after b3.
Click to expand...
Click to collapse
b3 is the first one I tried. I didn't look at the classes.dex before it was deleted. I will check.
RASTAVIPER said:
Good job!
Can you explain more about how rom is being affected?and what to check?
Sent from my phiremod for Nook using Tapatalk
Click to expand...
Click to collapse
Read here http://forum.xda-developers.com/showthread.php?t=1004102
TelephonyManager.smali did not change.
mellopete said:
TelephonyManager.smali did not change.
Click to expand...
Click to collapse
Please make sure b3 is the one you are using. When you originally posted... the thread was showing 0 downloads of that file.... or just wait a few minutes... beta 4 is on its way shortly.
To ensure TelephonyManager.smali is not changed you need to look in two places.... the easiest way is to search for getDeviceID
If it worked correctly you should find 2 instances... the first is the original function and my program renames it to getDeviceID2()... the second should be the one !IMEMe adds to the end of TelephonyManager.smali
Additionally... could you check and see if your run is actually overwriting update zip file.... see if there is a update ".zip.tmp" file left over... if it is there... the zipping is running into an issue overwriting the original file... I thought I had that issue worked out... but may need to add a check for that within my program.
I d/l b4, dropped it in a directory with just the .zip for n87 and ran it (win7 pro 64-bit). It errored out and here's the play-by-play of each of the windows which popped up one immediately after the other:
- I was warned about you being an unverified software publisher, which I OKed.
- "Windows cannot find 'java'. Make sure you typed the name correctly, and then try again." I OKed this one as well.
- window titled "DizzyDen's IMEI Generator" containing: "Return Code is:0 and Error Code is: 1"
- window titled "DizzyDen's IMEI Generator" containing: "Java is required on your system. You can download the current version from http://java.com"
I have JRE6 on my machine, though it is not in the system PATH.
Oh, and there were files for 7za, adb, .dll's and .jar files left behind.
mr_fosi said:
I d/l b4, dropped it in a directory with just the .zip for n87 and ran it (win7 pro 64-bit). It errored out and here's the play-by-play of each of the windows which popped up one immediately after the other:
- I was warned about you being an unverified software publisher, which I OKed.
- "Windows cannot find 'java'. Make sure you typed the name correctly, and then try again." I OKed this one as well.
- window titled "DizzyDen's IMEI Generator" containing: "Return Code is:0 and Error Code is: 1"
- window titled "DizzyDen's IMEI Generator" containing: "Java is required on your system. You can download the current version from http://java.com"
I have JRE6 on my machine, though it is not in the system PATH.
Oh, and there were files for 7za, adb, .dll's and .jar files left behind.
Click to expand...
Click to collapse
java will need to be in your path... I have no way of including all possible locations of where it could be installed... and it is way too big to include with my program.
The left over files is due to the program exiting when it did... I will fix that in next beta... should have waited until java was tested to extract them... or have it perform cleanup before exiting on any errors... sorry bout that.... you can leave them... when you have successful run (or run beta 5 or later) it will clean them up.
For now you may have to run as administrator.... I will try to add code to avoid this in the short future.
BTW. Nowhere does getDeviceID does it say that it must be a well formed IMEI.
nemith said:
BTW. Nowhere does getDeviceID does it say that it must be a well formed IMEI.
Click to expand...
Click to collapse
As much as I admire your work... I am honored that you are even checking this out.
I do understand that as of now it is not required... but I figure if I utilize standards (as much as there are anyway) we may avoid future issues if dev's start checking for well formed IMEI's.
I figure if I'm going to make this... I might as well make it right.
As far as I can determine... if a sw dev implemented IMEI checks, the only thing that could cause them to shut down someone using this would be to check that it is a "TEST" IMEI... but I don't see that happening, because hardware manufacturers do use these in testing.
DizzyDen said:
java will need to be in your path... I have no way of including all possible locations of where it could be installed... and it is way too big to include with my program.
Click to expand...
Click to collapse
Roger that. Should the instructions then note either the required change to PATH or that the file must be run in the user's jre#\bin directory?
DizzyDen said:
The left over files is due to the program exiting when it did... I will fix that in next beta...
Click to expand...
Click to collapse
I figured as much, but thought you should know.
DizzyDen said:
For now you may have to run as administrator...
Click to expand...
Click to collapse
I ran it this way and got the same behavior.
I'll keep a lookout for further versions, test them and report.
Beta 5 is up... OP updated to include Java requirements... thank you mr_fosi for pointing this out.
RASTAVIPER said:
Good job!
Can you explain more about how rom is being affected?and what to check?
Sent from my phiremod for Nook using Tapatalk
Click to expand...
Click to collapse
Did you find the information in the thread linked in response to your questions?
TY mellopete for that.
- Plugged NC into USB port.
- Copied new B5 exe and n87 zip to java\jre6\bin directory.
- Ran exe as admin.
- Prompted for .zip check ("is this correct") and it was, so I OKed it. Not OKing it gave me the option to browse for the file, which I cancelled, resulting in a termination of the prog with a few more dialogs. Any extracted files were cleaned up an prog close, except for adb.exe (which I deal with below).
- Re-ran, exe, chose the detected n87 .zip.
- Displayed correct serial.
- Displayed correct generated 17-digit IMEI.
- Dialog contents "Modifying" gave error "Unable to open file", which I OKed.
- Several more dialogs flew by in rapid succession without error, ending with "Updating ROM" overlaid by "Updated ROM file has been saved as: cm_encore_full-87-IMEI.zip".
- Not all ancillary files were cleaned up. Two files remained: 1) IMEI.fix, a plain txt file containing the correct code to insert the generated IMEI and 2)adb.exe which could not be removed because it was still running the devices server. Running "adb kill-server" in the java\jre6\bin directory allowed me to remove adb.exe.
- A check of the modified smali showed only one instance of "getDeviceId" indicating that the smali had not been modified to add the code to spoof the IMEI.
I would also not have been able to eject my NC, had I tried, until I killed the adb server. Looks like one more line of code to add before cleanup.
Hey guys,
This is my first time developing apps for a device, please don't be too callous.
Prior to the release of Android Studio I was having a crack at eclipse with the android SDK and attempting to utilise the AVD simulator rather than the actual Galaxy Nexus I have right beside me. My issue was in fact the same as to when I converted to Android Studio, a rather consistent error:
Code:
Waiting for device.
C:\Android\android-studio\sdk\tools\emulator.exe -avd GalaxyNexus -netspeed full -netdelay none
Device connected: emulator-5554
Device is online: emulator-5554
Target device: emulator-5554 (GalaxyNexus)
Uploading file
local path: C:\Ryan\Android\MyFirstApp\build\apk\MyFirstApp-debug-unaligned.apk
remote path: /data/local/tmp/com.example.myfirstapp
Adb Transfer Protocol Error.
No such file or directory
The AVD Simulator boots up, Android Labels displays then fails after a matter of seconds. i understand the issue is obviously not related to the IDE hence why both eclipse and Android Studio are doing the same thing.
I Created an AVD with the following Properties:
Code:
Name: GalaxyNexus
Device: Galaxy Nexus (4.65"...etc
Target: Android 4.2.2 - API Level 17
CPU/ABI: greyed out as "ARM..."etc
Keyboard enabled
Skin enabled
Front Camera None
Rear Camera None
Memory options
- Ram: 512
- VM Heap: 64
- Internal Storage: 8 GiB
- SD 128MiB
Emulation options both left unchecked
Greyed out button for "Override the extisting AVD with the same name"
The basic default hello world app actually runs fine on my galaxy nexus on 4.2.2.
Not sure of my issue, I would assume configuration, though couldn't be sure.
Thanks ahead.
ryanspacef said:
Not sure of my issue, I would assume configuration, though couldn't be sure.
Thanks ahead.
Click to expand...
Click to collapse
Go to SDK Manager and hit the Install button. Mine still had 5 missing packages, including the ARM ABI, which would also explain why the AVD didn't boot. Hope this helps.
ryanspacef said:
Hey guys,
This is my first time developing apps for a device, please don't be too callous.
Prior to the release of Android Studio I was having a crack at eclipse with the android SDK and attempting to utilise the AVD simulator rather than the actual Galaxy Nexus I have right beside me. My issue was in fact the same as to when I converted to Android Studio, a rather consistent error:
Code:
Waiting for device.
C:\Android\android-studio\sdk\tools\emulator.exe -avd GalaxyNexus -netspeed full -netdelay none
Device connected: emulator-5554
Device is online: emulator-5554
Target device: emulator-5554 (GalaxyNexus)
Uploading file
local path: C:\Ryan\Android\MyFirstApp\build\apk\MyFirstApp-debug-unaligned.apk
remote path: /data/local/tmp/com.example.myfirstapp
Adb Transfer Protocol Error.
No such file or directory
The AVD Simulator boots up, Android Labels displays then fails after a matter of seconds. i understand the issue is obviously not related to the IDE hence why both eclipse and Android Studio are doing the same thing.
I Created an AVD with the following Properties:
Code:
Name: GalaxyNexus
Device: Galaxy Nexus (4.65"...etc
Target: Android 4.2.2 - API Level 17
CPU/ABI: greyed out as "ARM..."etc
Keyboard enabled
Skin enabled
Front Camera None
Rear Camera None
Memory options
- Ram: 512
- VM Heap: 64
- Internal Storage: 8 GiB
- SD 128MiB
Emulation options both left unchecked
Greyed out button for "Override the extisting AVD with the same name"
The basic default hello world app actually runs fine on my galaxy nexus on 4.2.2.
Not sure of my issue, I would assume configuration, though couldn't be sure.
Thanks ahead.
Click to expand...
Click to collapse
Have you tried to push your apps apk manually using the adb push command? If that does not work its probably a driver issue. Also you may try changing the sdcard size to >200mb or removing it altogether and only using internal. I would also use a much smaller internal size unless your app needs it. My AVD has an internal of 256mb and no sdcard and runs fine. The AVDs are very picky and have strange issues sometimes.
Friends.
I put a sdcard in the device. The sdcard is recognized, but only with permission to read. I can not write files, create folders, delete, etc.
When I have tried, with X-Plorer app, the following message appears:
No activity found to handle Intent
{act = android.is.storage.action.OPEN_EXTERNAL_DIRECTORY (has extras)}
And then:
Error!
Some files could not be copied!
I put a pendrive (udisk) and the same thing happened.
I already tested the mentioned sdcard 32GB Class 10 in 2 other Android TV BOX successfully! On PC,too, the sdcard works 100%.
Question: Does anyone have any tips? Why are both sdcard and udisk only available for reading? ll applications are enabled to use storage.
Note: I am using Android 7.
Every time an application asks to authorize through the application "OPEN FROM" gives error. The application tells you which action to take, but does not open the "OPEN FROM" application, as it appears in the image below.
I can only write if go through the physical path and not direct in the "unit" SDCARD or USB DISK. Example: / mnt / sdcard or / storage / usb disk etc ...
Is it!
Thanks for your attention.
@paramparmatma Thread closed as a subject matter related thread already exists:
"This PC can't run Windows 11"
like many, i am getting this error. i have a built PC with a Ryzen 7 2700X. I think there might be a BIOS setting to enable TPM, but I haven't checked yet. Anyone else run into this? this is the link to the Windows 11 compatibility checker...
forum.xda-developers.com
All important posts of this thread have been copied to there. However, I suggest to review the XDA Forum Rules with special emphasis on rule no. 5 and in future to post in existing threads before creating new ones. Thanks for your cooperation!
Regards
Oswald Boelcke
Senior Moderator
1: Create your own installation media
2: The steps necessary to remove the "Secure Boot" and "TPM 2.0" requirements error when attempting to install Windows 11
3: Obtain the newest available Windows 10 ISO from Micro$0ft;
Already have made your Windows 11 USB Installer using Rufus;
Mount Windows 10 ISO;
Find and locate the folder named Sources on the mounted ISO;
Copy all of the files in the Sources folder of the mounted ISO except for install.wim/install.esd;
Navigate to the Windows 11 bootable USB Installer that you have previously created in your File Manager;
Open the Sources folder on the Windows 11 bootable USB Installer;
Paste the previously copied contents/files from the Sources folder on the mounted Win 10 ISO to the Sources folder of the Windows 11 bootable USB Installer, and make sure to replace the files present in the Windows 11 USB Installer Sources folder;
Boot from Windows 11 USB Installer;
Profit from not having the requirements of Secure Boot and TPM 2.0 being enabled in place.
For more deatils hereis detailed tutorial. Link.
Interesting. Has anyone actually tried this method with success?
I'll give it a try
I remember very similar pains when Windows 10 first released. I think everything will be fine for the most part as long as your machine can run Windows 10. Not much is different between the two.
Thank you thank you thank you I thought I was screwed too I've got an old optiplex 790 with a Intel i5 4 series and I just booted all I did was change the registry through the BIOS on the front end during the install which means I made the ISO file for USB UEFI boot I got the error saying that my machine hardware was not suitable for Windows 11 so I hit shift and F10 to command prompt and entered notepad because I already copied the registry into a text document that's accessible from the file menu in the notepad never done that before and that was pretty cool..copied it and then went back to the command prompt and went to the regedit.exe... copy what I had on the the text document into the actual local registry and then started the install process all over and Golden... I had to actually download the ISO file from Android host file of all places checksum good worked out everything's even better when I can beat the status quo
svetius said:
Interesting. Has anyone actually tried this method with success?
Click to expand...
Click to collapse
I am using it through leaked win 11 iso
Yes. I did it pretty much the same but unpacked/repacked install.wim, and renamed to install.esd with just the target version.
TPM 1.2 I never enabled secure boot and it's a 6th gen. Windows update is being a sore loser.
You may need to edit the registry after. Lookin' around myself.
The simplest solution that worked for me:
How To Remove or Replace appraiserres.dll in Windows 11 Setup
October 12, 2021: A big update! Please note that you no longer need to replace the appraiserres.dll file in order to bypass the TPM check and fix the installation error when installing Windows 11. …
nerdschalk.com
Download Mirror: https://www.dllme.com/dll/files/appraiserres_dll.html
Here's more info on installing Windows 11 on unsupported machine:
How to install Windows 11 on almost any unsupported PC
Want Windows 11 but have an unsupported computer? Here's how to install Windows 11 even if your PC doesn't meet the minimum requirements.
www.xda-developers.com
This Link helped me out, hope it fixes your problem too.
Thank you guys!
Will try it out
To install Windows 11 on an old PC by bypassing TPM and Secure Boot using registry
1. Boot Windows 11 from USB media and select your preferred language.
2. On the next page, click Install Now.
3. On Activate Windows page, Press Shift + F10 to open a command prompt window.
4. Type notepad on the command prompt and hit enter.
5. Copy the following and save it as a .REG file format tpmbypass.reg in the source folder.
Code:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\Setup\LabConfig]
"BypassTPMCheck"=dword:00000001
"BypassSecureBootCheck"=dword:00000001
6. Once saved, select File > Open and specify All Files for the file type.
7. Find tpmbypass.reg, right-click, and select Merge.
8. Voila, Windows 11 will be installed on your old PC.
If you are stuck on Getting devices ready progress
1. Hold the power button of your PC in 5 seconds to turn it off forcefully and turn it back on.
2. If you see The computer restarted unexpectedly error message, press Shift + F10 to open a command prompt window.
3. Type regedit and hit enter to start Registry Editor.
4. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\ChildCompletion and double-click the setup.exe on the right pane.
5. Change the Value Data from 1 to 3 and click OK to save changes.
6. Close Registry Editor and click OK on the error message restart your PC and is now fixed.
Modifying registry while installing3.1 Boot from the Windows 11 installation media
3.2 Start to install, we will see the Error “This PC can’t run Windows 11”
3.3 Use Shift + F10 to open command prompt window
3.4 Type regedit then Press Enter key
3.5 Find HKEY_LOCAL_MACHINE\SYSTEM\Setup
3.6 Create Item New Key: LabConfig
3.7 Inside of LabConfig,
Create DWORD 32, BypassTPMCheck, Value 00000001
Create DWORD 32, BypassSecureBootCheck, Value 00000001
3.8 Save and Exit Registry Editor
Continue to install/upgrade, we may have another hardware compatibility error during the process, Click Exit, ignore the error and roll back, Use Win + E to open file explorer, Delete C:\$WINDOWS.~BT\Sources\AppraiserRes.dll , Launch Windows update again.
orb_selektor said:
Thank you guys!
Will try it out
Click to expand...
Click to collapse
did it work?
svetius said:
did it work?
Click to expand...
Click to collapse
No luck yet, I will give a second try this weekend.
Saludos amigo!
Having a look