Code:
long now = SystemClock.elapsedRealtime();
long nextPrompt = getNextPromptTime(intent, now);
if (nextPrompt == 0) {
Log.i(TAG, "Installing overdue OTA update without prompting");
installUpdate();
return;
}
Basically, getNextPromptTime determines the prompt interval and number of prompts to show. So Google can potentially never prompt and just install without asking permission.
If you want to keep root access, I highly recommend doing the following to disable OTA updates:
Go to a root prompt.
Type the following:
# mount -oremount,rw /dev/block/mtdblock3 /system
# cd system
# cd etc
# cd security
# mv otacerts.zip otacerts.zip.bak
# mv cacerts.bks cacerts.bks.bak
That should disable cert checking by disabling (renaming) all the certs on the device. Someone please verify, but I'm pretty sure those are the certs that are checked.
Alternatively, you can follow the instructions to mod your recovery and boot images:
http://forum.xda-developers.com/showthread.php?t=443041
I have confirmed that leaving a shroot/suroot laying around will not work, as Google formats the system partition and resets all permissions upon an update:
Code:
format SYSTEM:
set_perm 0 3004 02755 SYSTEM:bin/ping
In addition, it is not possible to put the shroot/suroot in another partition besides system, as those are all reverted to noexec or nosuid upon reboot.
Code:
/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block/mmcblk0 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1000,fmask=0711,dmask=0700,codepage=cp437,iocharset=iso8859-1,utf8 0 0
Anyone know where the underlying update code is? I've only seen the Java front end (/packages/apps/Updater).
How do I know if I did this right?
Keep in mind I know next to nothing about Linux.
Ive done it to mine and have yet to see an update
Might want to move telnetd to something, so an app doesnt call it and get root, if you dont want the patch. Also copy sh to something so you can get root, and remove the permissions on sh
Not sure if suid on sh is needed for anything, so beware...
moving telnetd is not necessary, moving cacerts is dumb
Moving telnetd is not necessary, because telnetd does not become root, nor is it setuid root. The bug was that a root shell was listening on the keyboard (so if you type reboot on your phone while the android is pulsing or after you boot - the phone reboots)
Moving the cacerts will make ALL SSL stuff to work incorrectly because you no longer have a list of trusted root authorities.
The only good long-term solution is to reflash your recovery... etc
hmm
the updates are downloaded to /cache what if we touch "nameofupdatefile" or lock down /cache completely and that may prevent updates
or
or we could create a script that kills the update app, deletes any zip files every couple minutes in /cache
My phone gave me an update notification, I immediately killed the com.android.update process then cd /cache ; rm signed-RC30-from-RC29-fat.1582cace.zip then sudo busybox touch signed-RC30-from-RC29-fat.1582cace.zip then rebooted, and so far no more update notification or update process started
Did it, I will inform you what happened....
for some reason signed-RC30-from-RC29-fat.1582cace.zip got deleted, possibly ln -s /dev/null signed-RC30-from-RC29-fat.1582cace.zip will work
RyeBrye said:
Moving telnetd is not necessary, because telnetd does not become root, nor is it setuid root. The bug was that a root shell was listening on the keyboard (so if you type reboot on your phone while the android is pulsing or after you boot - the phone reboots)
Moving the cacerts will make ALL SSL stuff to work incorrectly because you no longer have a list of trusted root authorities.
The only good long-term solution is to reflash your recovery... etc
Click to expand...
Click to collapse
The recovery and boot images both get replaced by patches.
Incidentally, I haven't been prompted yet to update. Has anyone else who followed my instructions gotten prompted? I'll be able to work on a patched update when I get back to work, I've got several G1s at my disposal.
@koush
I did the modifications you mentioned at the begin of the thread, now I want to update to RC30 with the jesus method. Is it necessary to undo the changes I made with your method ? If yes, what do I have to do exactly ?
thanks a lot
PAO1908 said:
@koush
I did the modifications you mentioned at the begin of the thread, now I want to update to RC30 with the jesus method. Is it necessary to undo the changes I made with your method ? If yes, what do I have to do exactly ?
thanks a lot
Click to expand...
Click to collapse
You shouldn't have to, since Jesus has a full update, but you should anyways just to be safe.
Basically, just move the files back:
# mount -oremount,rw /dev/block/mtdblock3 /system
# cd system
# cd etc
# cd security
# mv otacerts.zip.bak otacerts.zip
# mv cacerts.bks.bak cacerts.bks
thanks koush, I will try it !
Why just don't change the update-script of an update to remove any unwanted lines, like formatting root? Why doesn't it work?
Koush said:
You shouldn't have to, since Jesus has a full update, but you should anyways just to be safe.
Click to expand...
Click to collapse
I prefer "JF" as the shorthand for my nick. Just FYI . I'm not Spanish, and I'm not "The Man".
all worked ok, thanks JF
JesusFreke said:
I prefer "JF" as the shorthand for my nick. Just FYI . I'm not Spanish, and I'm not "The Man".
Click to expand...
Click to collapse
Related
Hi All,
The Ash shell provides a few advantages over the Android default sh shell such as command history and cursor handling at the prompt. There are other benefits, but these are the first that come in most handy (to me).
The following tutorial will get you ash as the login shell with as yet no ill effects:
Note: that in my case, I'm using my android2sd construct and thus this modification is being done to my active overlay profile setup, thus to undo it I can simply boot into "safe\\normal" mode and undo the changes without possibly locking me out of the console should it have failed (which it didn't) But you can edit the Android /system/bin/sh file in this manner directly.
Ash as Login Shell:
OK, make the /system fs read-write:
mount -o remount,rw /system
Click to expand...
Click to collapse
Note: that the fs type is not needed, and in my case is not yaffs but ext3, Android will figure it out proper.
Next,
cp -a /system/bin/sh /system/bin/sh0
Click to expand...
Click to collapse
(this is for backup purposes and allows us to undo the change if so desired, or delete it if no longer needed).
Note: I'm using JF1.51 roms, so busybox ash is available as /system/xbin/bb/ash, so that is what I am using here; use ash however you are able to access it.
echo "#!/system/xbin/bb/ash">/system/bin/sh
echo "/system/xbin/bb/ash \[email protected]">>/system/bin/sh
Click to expand...
Click to collapse
Please note the use of (redirect\\overwrite)> and (redirect\\append)>>.
This will overwrite sh with a script to load the desired shell, executing any command-line arguments passed, and preserve the permissions of the original sh file. You can manually set the permissions the same as they are for our sh0 backup if the permissions (root.shell)(0755) don't seem to keep.
Finally reset the read-only state of /system:
mount -o remount,ro /system
Click to expand...
Click to collapse
Now if you shell-in\\telnet-in you should get the ash prompt which unlike the Android sh default prompt, includes the present working directory(pwd) ie: '/#' instead of just '#'.
Note: A reboot should not cause the loss of the modification, but if does, copy the new sh script to your /data/local/bin location or something and copy it back via boot script or something.
Shell Scripts:
If you're like me, you discovered that Android didn't need the interpreter declaration comment in scripts, and thus may not have used them...Well, you will need to update your scripts to include them by adding something similar to the following as the first line of your scripts:
#!/system/xbin/bb/ash
Click to expand...
Click to collapse
Again, please note that I am using JF1.51 roms and the location of the busybox ash shell is what I'm listing; put the full location to the shell you intend to use as this location.
Without the interpreter declaration, ash simply complains 'not found' at the first command, as ash doesn't know how to interpret the script, and doesn't seem to default to the login shell.
Hope someone finds this helpful!
sweet. This is going to be very useful
BAM. thats sexy. i just did this on CM3.6.7.1. works like a charm.
scratches head. i'm lost. what does this do and how does this make my g1 better?
temporizer said:
scratches head. i'm lost. what does this do and how does this make my g1 better?
Click to expand...
Click to collapse
im not sure about the other features, but the one i installed it for is to have your working directory in front of ur prompt. ex:
Code:
/# cd /sdcard
/sdcard # cd /system/sd
/system/sd #
etc...
EDIT: Also, if you use ConnectBot, you'll notice with the regular sh, if u scroll up with tracball, you get BS characters on the prompt. with THIS one, when you scroll up, you get last command entered. VERY handy for when you mistype one character on a long-ass command.
I love you
Couldn't you do this?
Code:
mv /system/bin/sh /system/bin/sh0
ln -s /system/xbin/bb/ash /system/bin/sh
great job, i'm going to get ash working on my G1 (CM-3.6.7.1)
Thanks.
kanstin said:
Couldn't you do this?
Code:
mv /system/bin/sh /system/bin/sh0
ln -s /system/xbin/bb/ash /system/bin/sh
Click to expand...
Click to collapse
I tried this and it worked even after a reboot...
Sweet, I love the scroll back with trackball in the terminal!!! Me thinks this should get absorbed into the next Cyan release.
kanstin said:
Couldn't you do this?
Code:
mv /system/bin/sh /system/bin/sh0
ln -s /system/xbin/bb/ash /system/bin/sh
Click to expand...
Click to collapse
Yes, I reckon you could. Though I had done a few experiments where the symlink failed, but I'm fairly sure it was do to the link: /system/xbin/bb/ash -->../busybox and /system/bin/../busybox not existing...so I did it via script. Many ways to skin a cat they say.
Thank you all... this is fricken awesome!!
temporizer said:
scratches head. i'm lost. what does this do and how does this make my g1 better?
Click to expand...
Click to collapse
It gives a more advanced shell for when you use the command line interface or telnet into your G1. If you don't use the command line a lot, it won't help you.
As for specific benefits to the advanced version, it was listed in the first post.
Hi,
imho this is rather a hack that exposes you to the risk at least on CM to loose your
shell during boot as xbin.sqf the compressed squashfs filesystem containing
busybox is mounted rather late in the boot process. A cleaner solution would be to
move busybox to system/bin and link it to sh. That way you ensure that sh will
always be accessible during boot and also later on, thus not interfering with
further developments. A alternative could be to compile a standalone version
of busybox containing only ash (for size reasons, as size in /system/bin is precious)
copy that to /system/bin and link sh to it.
Seems to work fine on Dude's. Not really sure how it should open, but I type "ash" at the prompt and I get the /$ and /# if superuser. I also get the command history by rolling the trackball, which is a very nice feature.
Can i install this without using my PC?
temporizer said:
Can i install this without using my PC?
Click to expand...
Click to collapse
Should work using terminal.
Tried it on JACHero 2.7.1
I tried the hard link one and I get a read only fs error on the first move command. What should I chmod to get past that?
mugafuga said:
I tried the hard link one and I get a read only fs error on the first move command. What should I chmod to get past that?
Click to expand...
Click to collapse
Do this first before the mv and the symlink.
mount -o remount,rw /system
farmatito said:
Hi,
imho this is rather a hack that exposes you to the risk at least on CM to loose your
shell during boot as xbin.sqf the compressed squashfs filesystem containing
busybox is mounted rather late in the boot process. A cleaner solution would be to
move busybox to system/bin and link it to sh. That way you ensure that sh will
always be accessible during boot and also later on, thus not interfering with
further developments. A alternative could be to compile a standalone version
of busybox containing only ash (for size reasons, as size in /system/bin is precious)
copy that to /system/bin and link sh to it.
Click to expand...
Click to collapse
Is this in any way accurate? I dedicate my g1 to cyan's roms and wouldn't want anything to hinder any of the goodness that is cyanogenMod. Advice?
Load ash when terminal is started?
temporizer said:
Is this in any way accurate? I dedicate my g1 to cyan's roms and wouldn't want anything to hinder any of the goodness that is cyanogenMod. Advice?
Click to expand...
Click to collapse
Safest method will be to change to ash shell once terminal app is started (same as typing "ash" to switch shell from sh to ash). I don't know how to do it in android (in linux you could add it to your login script).
So if someone knows how to execute a command when we login using the terminal app, then switching to ash shell would work without fear of breaking any other functionality.
Hey guys,
My uncle works for Motorola and gave me a prototype phone (which I believe will be called the Motorola Sage, and it's model number is MB508. This thread isn't really about that, I can't post pictures because I don't want to get anyone in trouble). This phone is an AT&T phone, complete with AT&T startup screen, uninstallable AT&T apps and of course the inability to install non-market apps. Also it's running Android 2.1.
Now, I seem to have default root access to this phone. I'm assuming the file system is very similar to that of the Backflip (which I was previously using until I received this one). From what I've read and learned from poking around in /system/etc, non-market apps are blocked by two config files. These are:
/system/etc/motorola/com.android.providers.settings/secure.mkitso
Code:
# cat secure.mkitso
cat secure.mkitso
location_providers_allowed=network,gps
wifi_on=0
data_roaming=1
bluetooth_on=0
install_non_market_apps=0
usb_mass_storage_enabled=1
and
/system/etc/motorola/com.motorola.android.providers.settings/settings.mkitso
Code:
# cat settings.mkitso
cat settings.mkitso
mms_maximum_message_size=614400
auto_scan_on_flip=true
sms_pref_key_emailgateway_num=121
Single_Digit_Dial_Enabled=True
roaming_icon=0
dun_enable=1
force_only_market_apps=1
Bluetooth_Dun_Enabled=true
mms_x_wap_profile_url=http://uaprof.motorola.com/phoneconfi/MotoMB51/profile/MotoMB511.rdf
sms_pref_key_to_email=1
Okay, now it would seem that it's a simple matter of changing the values for "force_only_market_apps" to 0, and "install_non_market_apps" to 1. I did this, and let me quickly tell you how I did it.
- Make /system writable: mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
- Copy mkitso files to sdcard
- Edit mkitso files using Notepad++, changing the values as stated above
- Copy mkitso files back to their original directories
- chmod 644 to the files in order to keep their original permissions
- Make /system read only again: mount -o remount,ro -t yaffs2 /dev/block/mtdblock4 /system
- Restart the phone
However, this did not work, as I still get the warning when I try to install a non-market app.
I was wondering if anyone had any ideas on this, as when the Backflip gets rooted this is one thing that I'm sure we would like to know.
Have you tried adb install? I've heard that works on Backflops. You could download the app to your PC,and install it using "adb install PATH/TO/APP.APK"
Thanks, I know that I can use adb to install non market apps, but I was looking at how to change this setting on the phone. Since I have root on my phone, I figured it was possible.
Check out some of these terminal apps found in /system/bin/ directory of the backflip.Maybe they will help you.
Code:
modemlog
chown
check_prereq
dumpsys
qmuxd
rild
dd
port_bridge
installd
minipadut
vmstat
vold
ioctl
mm-audio-native-test
lsmod
id
mm-adec-omxamr-test
notify
getevent
hciattach
dhcpcd
service
cat
system_server
linker
mm-vdec-omxh264-test
mm-adec-omxevrc-test
wpa_supplicant
netstat
mm-adec-omxmp3-test
ls
wipe
iwpriv
stop
log
mm-vdec-omxmp4-test
top
bt_init
app_process
kill
dumpcrash
iwspy
tcmd_engine
sleep
port-bridge
input
chmod
flash_image
wfa_dut
monkey
dmesg
umount
dalvikvm
sh
sync
ptf
mm-jpeg-dec-test
ime
diag_klog
route
ln
batch
fuel_gauge
iwlist
bugreport
insmod
hcid
svc
rmmod
servicemanager
iwgetid
debuggerd
test_diag
am
renice
applypatch
ps
watchprops
sendevent
reboot
mount
mm-adec-omxQcelp13-test
pm
start
ping
busybox
toolbox
df
touchpad
mediaserver
setconsole
loc_api_app
setprop
logwrapper
rm
dvz
hd
ifconfig
rmdir
printenv
getprop
mm-venc-omx-test
fsck_msdos
iwconfig
iftop
bt_downloader
akmd2
sdptool
disp_util
mm-aenc-omxamr-test
newfs_msdos
gzip
cmp
iwevent
mv
smd
mmclog
mknod
mm-adspsvc-test
bt_test_exec
dexopt
date
set_grp_id
i2c
tcmd_sql
recovery
dumpstate
netcfg
surfaceflinger
mkdir
dbus-daemon
mm-adec-omxaac-test
schedtest
mm-jpeg-enc-test
logcat
mm-aenc-omxaac-test
schedtop
fmradio
EDIT:Also there does not seem to be a com.android.providers.settings in /system/etc/motorola/ only com.motorola.android.providers.settings and the file located in that directory is named secure.mkitso and the market app setting is set up like this:install_non_market_apps=0
So there is a slight difference in how the devices are set up and maybe a bit less security on the backflip =)
Thanks for your suggestion, but if you read above I changed the mkitso files without any changes in the behavior of the phone .
I was thinking that since I changed the settings files and they didn't do anything, maybe they will be applied during a hard reset. I'll try that sometime this weekend and report on the results.
The reason I'm asking for help is because I believe that once the Backflip gets rooted, we will need to know how to disable this setting.
I doubt you have root unless it came already rooted (you did make up some **** about a prototype) I honestly think this wont be a hard issue to tackle or work around when root is achieved on the Lackflip...yes I did Lackflip on purpose because of how crippled it is..so spend your time ANNONYMOUSLY sending www.endgadget.com some nice shiney pics of your supposed prototype codnamed:
"Motorola Sage"
I'm not sure why you're so aggressive, Honestly77. I'm able to "su" in shell and I'm able to modify files in the /system folder, so unless I'm mistaken (which I very well might be), then I believe I have root on the phone.
It is a prototype phone for testing, so it coming rooted isn't too farfetched at all.
When the Backflip does get rooted yes, this will be an easier issue to solve, but I'm trying now. If we're able to figure it out now then no time will have to be devoted to it when the Backflip is rooted.
Alright, I just did a hard reset and it activated a menu toggle under Settings -> Applications -> "Unknown Sources: Allow install of non-Market applications" which can be checked or unchecked.
To summarize, if you have root on your phone, edit secure.mkitso and settings.mkitso and change the variables, then you need to hard reset the phone.
hey met3ora, I too have a backflop, I am currently trying to sell my soul to obtain some sort of root or even simple control over the device, I have 2 questions for you...
1: using the config files and other software availible on this forum, would it be possible to obtain a workaround to be able to install apps from sd? I'm sure you are well aware that the backflip has no memory and won't even allow market apps to be installed via sd.
my second question (its ok if you don't want to answer as we will find out soon enough)
is: the moto sage, how does it compare to the backflip? no specifics needed just, is it better?
Iv'e seen the photos of the sage that appeared a couple weeks ago and it looks good, just incase we need it you should copy the system files as I'm sure the one AT&T will give us will be on lockdown as well. Thanks!
Honestly77 said:
I doubt you have root unless it came already rooted (you did make up some **** about a prototype) I honestly think this wont be a hard issue to tackle or work around when root is achieved on the Lackflip...yes I did Lackflip on purpose because of how crippled it is..so spend your time ANNONYMOUSLY sending www.endgadget.com some nice shiney pics of your supposed prototype codnamed:
"Motorola Sage"
Click to expand...
Click to collapse
THis thread is old but it still helped me with a bravo. Thanks OP.
And to this guy above, wtf, why be such a douche? You are also clearly an idiot or you would know that engineering models always have root.
Calling the OP a liar was way out of line and you should apologize.
Hi, this is my first time posting on this site and I apologizes if this is in the wrong place. I just recently rooted my evo and was wondering when I want to apply a customization such as a new notification bar how do I know to use either flashing the file from the sd card or to run a command in adb? Is there an important difference, or can either be used? Thanks in advance for the help.
rafroehlich2 said:
Hi, this is my first time posting on this site and I apologizes if this is in the wrong place. I just recently rooted my evo and was wondering when I want to apply a customization such as a new notification bar how do I know to use either flashing the file from the sd card or to run a command in adb? Is there an important difference, or can either be used? Thanks in advance for the help.
Click to expand...
Click to collapse
Most files can be flashed, if they are in a .zip form, you should be okay. However for things like the bootscreens, the recommended method is to use ADB and push the bootanimation.zip file to the specified folder on the phone. However, this has been extremely simplified by user-made tools here on the EVO forums, not many people like using ADB (don't know why)... so there are tools to make it easier for people.
Usually the person that is distributing the file should say whether you need to flash or use ADB commands, just read the OP's post.
Thanks so much for your help.
rafroehlich2 said:
Thanks so much for your help.
Click to expand...
Click to collapse
Sure, no problem!
pseudoremora said:
Most files can be flashed, if they are in a .zip form, you should be okay. However for things like the bootscreens, the recommended method is to use ADB and push the bootanimation.zip file to the specified folder on the phone. However, this has been extremely simplified by user-made tools here on the EVO forums, not many people like using ADB (don't know why)... so there are tools to make it easier for people.
Usually the person that is distributing the file should say whether you need to flash or use ADB commands, just read the OP's post.
Click to expand...
Click to collapse
If I use the flashing method will the files be moved to the correct system folder or will it just deposit it in the ROM? When you use adb you specify the target, if I'm not mistaken. I just don't want my system to get cluttered with random files. Sorry if this isn't worded well.
rafroehlich2 said:
If I use the flashing method will the files be moved to the correct system folder or will it just deposit it in the ROM? When you use adb you specify the target, if I'm not mistaken. I just don't want my system to get cluttered with random files. Sorry if this isn't worded well.
Click to expand...
Click to collapse
When using ADB, the system won't get "cluttered"... mainly because when you're are using the adb push (copy) command, you will be overwriting the file that is currently residing on your phone.
For example, if I wanted to replace my bootanimation -- I would type:
Code:
adb push bootanimation.zip /system/customize/resource
This would copy the new bootanimation.zip over to the directory being specified (/system/customize/resource -- where the bootanimation resides), upon copying, it explicitly overwrites any file/folder with the name "bootanimation" -- unless you set a parameter when typing the command to ask you if it should overwrite. You don't need to worry about this though, almost always you'll overwrite the files.
As long as you push (copy) any and all files to its correct directory, nothing should ever get cluttered and if it does, then you can always remove it just as easily.
pseudoremora said:
When using ADB, the system won't get "cluttered"... mainly because when you're are using the adb push (copy) command, you will be overwriting the file that is currently residing on your phone.
For example, if I wanted to replace my bootanimation -- I would type:
Code:
adb push bootanimation.zip /system/customize/resource
This would copy the new bootanimation.zip over to the directory being specified (/system/customize/resource -- where the bootanimation resides), upon copying, it explicitly overwrites any file/folder with the name "bootanimation" -- unless you set a parameter when typing the command to ask you if it should overwrite. You don't need to worry about this though, almost always you'll overwrite the files.
As long as you push (copy) any and all files to its correct directory, nothing should ever get cluttered and if it does, then you can always remove it just as easily.
Click to expand...
Click to collapse
Thanks for taking the time to answer. I'm new to this and any time I see command line I get hesitant. Thanks again for the thorough answer.
rafroehlich2 said:
Thanks for taking the time to answer. I'm new to this and any time I see command line I get hesitant. Thanks again for the thorough answer.
Click to expand...
Click to collapse
Yup, no problem. I try to usually give a detailed answer, as I'm sure not everyone will understand vague answers.
pseudoremora said:
Yup, no problem. I try to usually give a detailed answer, as I'm sure not everyone will understand vague answers.
Click to expand...
Click to collapse
Since you seem to be knowledgeable what is the difference between flashing a rom by its name.zip as opposed to renaming it update.zip? Does the former start new and the latter maintain all apps/settings?
Sent from my PC36100
rafroehlich2 said:
Since you seem to be knowledgeable what is the difference between flashing a rom by its name.zip as opposed to renaming it update.zip? Does the former start new and the latter maintain all apps/settings?
Sent from my PC36100
Click to expand...
Click to collapse
No difference.
The naming conventions don't mean anything really. There used to be a time when all packages had to be called "update.zip", but the Devs that built the recoveries made it so you could name the .zip files whatever you wanted.
You'll see ROM's/theme's/etc with fancy names -- that's just so its easier for the end user to identify what he/she is actually going to flash.
When I say "update.zip", I just mean that the file can be flashed via recovery and won't require command line/terminal/ADB.
However, there are certain files that will always have a static name (bootanimation.zip) -- that can't change because the phone is programmed to look for that specified file. So whenever someone uploads a bootanimation and calls it: "Nexus-bootanimation.zip" --- this should be renamed to bootanimation before adb pushing or flashing to its specified directory.
Now I understand the idea behind flashing a radio, however I don't understand flashing a kernel. How do I know when to do this and do the risks of radio apply to the kernel? Also, are there any other major components that I'll eventually have to flash? Thanks for answering my many questions.
Sent from my PC36100
rafroehlich2 said:
Now I understand the idea behind flashing a radio, however I don't understand flashing a kernel. How do I know when to do this and do the risks of radio apply to the kernel? Also, are there any other major components that I'll eventually have to flash? Thanks for answering my many questions.
Sent from my PC36100
Click to expand...
Click to collapse
There are risks with both.
Flashing a kernel or radio has the potential to brick your phone. The radio is used for controlling all the "wireless" functions (3G, 4G, x1 connections (texting/calling)) -- pretty much anytime the phone connects to the Sprint towers, the radio is playing its part. So if you flash it incorrectly; the consequences are obvious.
The kernel is the heart of the Android. The kernel itself is actually Linux. Android is built upon Linux, so pretty much Google took the already existing Linux kernel and built Android on top of it (the UI, the apps, etc) and made Android into a Mobile OS, which can run on virtually any platform or device.
How do you know? You don't -- it's a matter of wanting to be curious enough to test. Some devs will put out kernels that overclock your device, others will add different features (screen fixes, loopback interface, underclocking, etc). The kernel controls all the hardware on the phone and how everything functions -- so when devs mess with source code, they are essentially making the hardware function differently for your device.
Some of the major components? -- The biggest ones so far are the wireless driver and 4G driver. When the EVO came out -- the battery life wasn't great; but after the new update (1.47 and the accompanying radio's); battery life on the device have improved significantly and people have experience better WiFi reception and such.
Hope that helps.
pseudoremora said:
There are risks with both.
Flashing a kernel or radio has the potential to brick your phone. The radio is used for controlling all the "wireless" functions (3G, 4G, x1 connections (texting/calling)) -- pretty much anytime the phone connects to the Sprint towers, the radio is playing its part. So if you flash it incorrectly; the consequences are obvious.
The kernel is the heart of the Android. The kernel itself is actually Linux. Android is built upon Linux, so pretty much Google took the already existing Linux kernel and built Android on top of it (the UI, the apps, etc) and made Android into a Mobile OS, which can run on virtually any platform or device.
How do you know? You don't -- it's a matter of wanting to be curious enough to test. Some devs will put out kernels that overclock your device, others will add different features (screen fixes, loopback interface, underclocking, etc). The kernel controls all the hardware on the phone and how everything functions -- so when devs mess with source code, they are essentially making the hardware function differently for your device.
Some of the major components? -- The biggest ones so far are the wireless driver and 4G driver. When the EVO came out -- the battery life wasn't great; but after the new update (1.47 and the accompanying radio's); battery life on the device have improved significantly and people have experience better WiFi reception and such.
Hope that helps.
Click to expand...
Click to collapse
That does help. This is my first time with android and my first time attempting to actually mess with it.
rafroehlich2 said:
That does help. This is my first time with android and my first time attempting to actually mess with it.
Click to expand...
Click to collapse
There will be a lot more "firsts", believe me. Some things will be harder than others; but if you stick with it and actually take the time to learn, you'll realize that working Android can be a helluva lot of fun and unbelievably addictive!
pseudoremora said:
There will be a lot more "firsts", believe me. Some things will be harder than others; but if you stick with it and actually take the time to learn, you'll realize that working Android can be a helluva lot of fun and unbelievably addictive!
Click to expand...
Click to collapse
The bug has already bit me. I appreciate the help. It's nice to know there is a community to get good answers from when needed.
Sent from my PC36100
pseudoremora said:
There will be a lot more "firsts", believe me. Some things will be harder than others; but if you stick with it and actually take the time to learn, you'll realize that working Android can be a helluva lot of fun and unbelievably addictive!
Click to expand...
Click to collapse
Instead of posting a new thread perhaps you can help me on this. When I attempt to use adb to remove a bundled app.
adb shell
cd /system/app
ls
rm app.apk
I get Disk space read only. I have full root and NAND I assume. I used the OTA method and am able to flash custom ROMs. I am using the rooted stock 1.47.651.1
rafroehlich2 said:
Instead of posting a new thread perhaps you can help me on this. When I attempt to use adb to remove a bundled app.
adb shell
cd /system/app
ls
rm app.apk
I get Disk space read only. I have full root and NAND I assume. I used the OTA method and am able to flash custom ROMs. I am using the rooted stock 1.47.651.1
Click to expand...
Click to collapse
When a "read-only" message is returned, it usually means that you don't have RW (read-write access), to circumvent this, run this command:
Code:
adb remount -- Should always be run if you plan on changing something that requires RW access
Then:
adb shell
cd /system/app
ls
rm app.apk
If for some reason you get a error message with adb remount (most likely due to permissions), then you'll need to use the full "remount" command, for that, run:
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
Hope that helps.
pseudoremora said:
When a "read-only" message is returned, it usually means that you don't have RW (read-write access), to circumvent this, run this command:
Code:
adb remount -- Should always be run if you plan on changing something that requires RW access
Then:
adb shell
cd /system/app
ls
rm app.apk
If for some reason you get a error message with adb remount (most likely due to permissions), then you'll need to use the full "remount" command, for that, run:
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
Hope that helps.
Click to expand...
Click to collapse
I tried your method, but I get another error. It looks like:
Code:
mac-mini:~ rafroehlich2$ adb remount
remount failed: Operation not permitted
mac-mini:~ rafroehlich2$ mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
mount: exec /usr/sbin/mount_yaffs2 for /System: No such file or directory
Is there a preventable reason
Code:
adb remount
fails? Thanks for the help.
rafroehlich2 said:
I tried your method, but I get another error. It looks like:
Code:
mac-mini:~ rafroehlich2$ adb remount
remount failed: Operation not permitted
mac-mini:~ rafroehlich2$ mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
mount: exec /usr/sbin/mount_yaffs2 for /System: No such file or directory
Is there a preventable reason
Code:
adb remount
fails? Thanks for the help.
Click to expand...
Click to collapse
I figured you might have trouble with the ADB remount -- again, this is usually due to permissions. For testing purposes, try booting into recovery and then issuing the adb remount command.
In regards to the full remount command -- I'm wondering if you have busybox (it contains all the Linux command line tools) so that you can run the above commands.
Can you issue and then paste the output back here?:
Code:
cat /proc/mounts
Also, run this:
Code:
adb shell
cd /system/xbin
ls
If you can see a huge list of files -- then that means you do in fact have Busybox installed.
Also, what ROM are you running?
pseudoremora said:
I figured you might have trouble with the ADB remount -- again, this is usually due to permissions. For testing purposes, try booting into recovery and then issuing the adb remount command.
In regards to the full remount command -- I'm wondering if you have busybox (it contains all the Linux command line tools) so that you can run the above commands.
Can you issue and then paste the output back here?:
Code:
cat /proc/mounts
Also, run this:
Code:
adb shell
cd /system/xbin
ls
If you can see a huge list of files -- then that means you do in fact have Busybox installed.
Also, what ROM are you running?
Click to expand...
Click to collapse
After
Code:
cat /proc/mounts
Code:
rootfs / rootfs ro 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
none /dev/cpuctl cgroup rw,cpu 0 0
/dev/block/mtdblock4 /system yaffs2 ro 0 0
/dev/block/mtdblock6 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock5 /cache yaffs2 rw,nosuid,nodev 0 0
tmpfs /app-cache tmpfs rw,size=8192k 0 0
/dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
Code:
mac-mini:~ rafroehlich2$ adb shell
$ cd /system/xbin
$ ls
wireless_modem
dnsmasq
su
I download the BusyBox app to keep it up to date and also installed it through the "problems" section on titanium backup. However, that's all I got.
The ROM I am using is the fully rooted stock RUU. I'd post a link, but am not sure if I'm allowed to yet. It is the one posted by whitslack.
How to root Nook HD+ (and Nook HD too, I guess).
(Thanks for some useful ideas to sparkym3: http://forum.xda-developers.com/member.php?u=4411543 )
(tested only on 2.0.0 version (as comes out of the box), also works on 2.0.2
Get one of the attached files: root_win.zip if you are on windows, or root_unix.tgz if you are on Linux or Mac.
unpack the file to some dir and run "makeroot" on Windows or "sh makeroot.sh" on Mac/Linux
After a couple of reboots you should be able to do
adb shell and issue a "su" command in the shell and get the root prompt (#).
Thanks to someone0 for his prior investigations here.
Known bugs:
Superuser.apk does not really install because package manager could not be contacted.
Oh, and I think you'll find this interesting too:
Hai.
Kind of a two-fer, eh?
I noticed that people see their Nook HDs restoring to factory settings after 8 unsuccessful reboots next time you boot after rooting, so possibly there's some extra check somewhere.
Very sneaky on the B&N side, I'd say.
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
roustabout said:
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
Click to expand...
Click to collapse
Do the new HD & HD+ still allow you boot from the external sd card ?
roustabout said:
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
Click to expand...
Click to collapse
if you put your books into /system/media, it will back them up to the cloud
Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.
leapinlar said:
Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.
Click to expand...
Click to collapse
stuff is best to be not mentioned. /sarcasm.....
recovery is signed, so it's not super easy to replace it with anything that would run.
The unsigned bootloader trick at the moment requires a boot from sdcard.
shouldn't step 8 & 9 be outside the code block?
verygreen:
I just want to thank you for your all your work on the Nook series. I've been using your "size-agnostic method ..." tools and process to run from the SD card on my Nook Color since you created the method, and now I'm excited to use your work on my new Nook HD+ (just received yesterday) !
just got mine and got an update notification. turned off wifi so it didnt complete.any word if it breaks root ir bootloader?
CWM is now possible too.
Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.
Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.
I also rewrote your code into a batch file. You can double check it I guess.
Code:
@echo off
cls
@echo .
@echo wait for it
@echo .
adb devices
@echo .
@echo if you do not see you device listed above hit ctrl+c and exit the script
@echo then check adb on your PC and device then try again.
@echo .
@echo reroute /data/local/tmp
adb wait-for-devices shell rm -r /data/local/tmp
adb shell ln -s /data/ /data/local/tmp
@echo .
@echo Now rebooting
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and making directory /data/su
adb wait-for-devices shell mkdir /data/su
@echo uploading su
adb push su /data/su/
@echo uploading busybox
adb push busybox /data/su/
@echo uploading boot_complete_hoot
adb push boot_complete_hook.txt /data/boot_complete_hook.sh
adb shell chmod 755 /data/boot_complete_hook.sh /data/su/*
@echo .
@echo Now rebooting again
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and getting shell
adb wait-for-devices shell
someone0 said:
Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.
Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.
I also rewrote your code into a batch file. You can double check it I guess.
Click to expand...
Click to collapse
so, when you run this, after the final adb shell, what are the permissions on /system/xbin/su?
run su and you should get the root prompt.
I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.
Code:
/data/
-rwxr-xr-x shell shell 167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell shell 586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell shell 22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell shell 2012-11-10 06:20 tmp -> /data/
cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
everything is in place and correct, but no dice. either boot_complete_hook.sh didn't get executed or it did but never get launched with root permission.
someone0 said:
I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.
Code:
/data/
-rwxr-xr-x shell shell 167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell shell 586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell shell 22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell shell 2012-11-10 06:20 tmp -> /data/
cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
everything is in place and correct, but no dice.
Click to expand...
Click to collapse
well, there should be more stuff in the shell file, you miss the final chown line: chmod 06755 /system/xbin/su
It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.
someone0 said:
It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.
Click to expand...
Click to collapse
check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh
verygreen said:
check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh
Click to expand...
Click to collapse
This is interesting, it look as if it won't launch the /data/boot_complete_hook.sh
Code:
cat /data/boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
[B][email protected]:/data $ /data/boot_complete_hook.sh
/data/boot_complete_hook.sh
/system/bin/sh: /data/boot_complete_hook.sh: No such file or directory
1|[email protected]:/data $
[/B]
Yub it does
Code:
cat clrbootcount.sh
#!/system/bin/sh
################################################################################
##
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
[B]/data/boot_complete_hook.sh[/B]
# Zero the boot count
cat /system/etc/zerobootcnt > /bootdata/BootCnt
Hi,
I just bought a cheap simple ARNOVA84 tablet (for 50 €) with android 2.1 to play a little bit and gather experience regarding rooting before I do this on my acer A511
I came so far, that I got adb shell with root ($ -> #). But to get SuperUser or SuperSU running I need also su in /system/bin. But /system is ro. The command
# mount -o rw,remount /dev/mtdblock4 /system
does not work in any combination. I get no error, but
# mount
still shows /system ro
To remount /system google said, I would need su, which in turn I don't have yet I copied su binary to another folder and changed permission to 755. But nevertheless su seems not to work. It just gives me new line with no # and everything I type in, is repeated. I have to break shell with ctrl-c.
The /system is a cramfs and my latest information is, that cramfs is always ro and can not be changed.
1. Is this true and does it mean I can root my tablet only be upgrading it with a modified update.img containing su etc.?
2. Is there no other more safe way to root such device?
3. Does this also mean more modern tablets have another filesystem for /system?
thanks!
Rainer