yashsingh1/xdaforums huggingface dataset:
[Galaxy Note II Q&A, Help & Troubleshooting] pantapanta1:
Hello,

After some months using samsung stock rom i would like to change to a deodexed samsung custom rom but without loosing my data and settings. Can i flash a samsung rom without making a clean install? What roms do you suggest me? I want battery life as main and sound!
[Galaxy S 4 General] PowerLemons:
I guess everyone knows that the Samsung Galaxy S4 has an option in settings called "High touch sensitivity".

It's intended to be used while wearing gloves, but there are other things which can be used with the Samsung Galaxy S4.

I've tried to use many things on my S4, and some worked.

Here are some objects which can be used with it...

- Almost anything metal (Cutlery, Metal Pen, etc)

- Fruits (Bananas, Oranges, etc)

- Certain Batteries

Post objects which can be used on the S4 below!
[Galaxy S 4 General] Obagleyfreer:
March issue of Playboy

My cat

Jacket potato
[Galaxy S 4 General] noideaforusername:
The metal things will work with any other type of touch screen as well since they transfer static(checked on my S3).

I think that everything that can produce even very small static can used on this phone (this is when the extra sensitivity comes in to play).
[Galaxy S 4 General] GalaxyoS4:
Scissors!

And what a stupid thing to do....gladly i had a cheap screen protector
[Galaxy S 4 General] RedLineJoes:
The SGS4 uses that latest tech in Gorilla Glass 3, you can't scratch it that easily. You'd have to try by going full retard on it. :eek:
[Galaxy S 4 General] CyberT3:
Well mine works with a paper candy bag and I didn't even turn on the High touch sensitivity ;)
[Galaxy S 4 General] system.img:
Well, you can use the screen with an iPhone 5.

Phonarena demoed that.
[Galaxy S 4 General] MaKTaiL:
Finally found something I can do with this Apple crap. :)
[Nook HD, HD+ Q&A, Help & Troubleshooting] gunnyman:
I'm asking because I had to format my 64GB sd card as fat32 in order to get cwm to see it, but now I can't use it as secure storage for nook vids and such.
[Nook HD, HD+ Q&A, Help & Troubleshooting] king200:
I'd try making 2 primary partitions on the card. Format the smaller one fat32. I think cwm can see ext2 partitions too. Easy enough to try. Gparted does it easy.
[Nook HD, HD+ Q&A, Help & Troubleshooting] gunnyman:
Great idea. Thanks.
[Ouya Android Development] sonofskywalker3:
Well, since i'm not aware of anyone else doing it, and it will be necessary for any real development to occur, I have decided to try porting Clockworkmod Recovery to the Ouya. I am downloading ubuntu right now and I'll start trying to build it from source against our current recovery tonight or tomorrow night depending on how long the setup and prerequisites take.

The reason I'm posting this now, is to solicit help. I've never built CWM before, but XDA has a really great tutorial I'm going to follow, but if anyone here has had experience in the past I'd love some help/tips, and other than that I would like a few brave souls to volunteer and try flashing it on their Ouya when/if I have a build that works on my own.

I'll update this thread with my progress, if I make any, and please let me know if any of you are willing to help in any way.

Update 1:

I have compiled a version of CWM recovery that theoretically should work, but I'm unable to flash it. I have installed flash_image onto the ouya and it works fine, but i normally would have used "flash_image recovery recovery.img" however there is no "recovery" partition on the ouya. This is what I get:

./flash_image recovery recovery.img

error scanning partitions: No such file or directory

Mount reveals the following info:

mount

rootfs / rootfs ro,relatime 0 0

tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0

devpts /dev/pts devpts rw,relatime,mode=600 0 0

proc /proc proc rw,relatime 0 0

sysfs /sys sysfs rw,relatime 0 0

debugfs /sys/kernel/debug debugfs rw,relatime 0 0

none /acct cgroup rw,relatime,cpuacct 0 0

tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0

tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0

none /dev/cpuctl cgroup rw,relatime,cpu 0 0

/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xatt

r,acl,barrier=1,data=ordered 0 0

/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 rw,nosuid,nodev,noatim

e,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=wri

teback 0 0

/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,nosuid,nodev,noatime

,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writ

eback 0 0

/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1

023,default_permissions,allow_other 0 0

This is the script from the OTA update:

#!/system/bin/sh

if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then

log -t recovery "Installing new recovery image"

applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p

else

log -t recovery "Recovery image already installed"

fi

but I can't make any sense of it. If anyone can help out i'd much appreciate it...
[Ouya Android Development] mybook4:
This seems to be the magic lines in the update script:

I don't know much about the applypatch program. It might just be another script. Since it isn't being called with a "./", I'd imagine it is installed somewhere that the path mentions. Try looking for "applypatch" to see if it is a program or script. In a terminal running on the Ouya, try running "echo $PATH". Hopefully you get a list of directories containing program locations (e.g. /usr/bin/ ...etc). Applypatch might be in one of those directories.

UPDATE 1:

applypatch is a binary, not a script. It is located in /system/bin/

I tried running it without arguments on my Nexus 7 (to see if we would luck out with a nice "usage" message), but for some annoying reason I can't give it execute permissions, even as root. I'll look deeper into the scripts

UPDATE 2:

I need to verify this on my Ouya, but from the updater-script in the latest OTA, the kernel partition is /dev/block/platform/sdhci-tegra.3/by-name/LNX (I'm going out on a limb here boys, but I think LNX stands for Linux, aka, our kernel, lol).

UPDATE 3:

Seems like the recovery partition is /dev/block/platform/sdhci-tegra.3/by-name/SOS

I don't know much about the details of "applypatch", but the recovery script you posted above seems to first check to see if the recovery partition hashes to f80238c4f4a53888b547e4463fb4751343f23412 (the hash of the latest and greatest recovery). If it doesn't, then we flash the latest recovery, which from the looks of it consists of the kernel (in LNX) with a patch applied to it from recovery-from-boot.p (another mess of binary). In other words, it looks like they build a recovery from the existing kernel, as the name "recovery-from-boot" implies (the kernel is packaged in a file called boot.img).

Long story short, it looks like you can write to the block device /dev/block/platform/sdhci-tegra.3/by-name/SOS to write a new recovery. Aka, in a hacked version of the OTA script, include the line

package_extract_file("recovery.img", "/dev/block/platform/sdhci-tegra.3/by-name/SOS");

where recovery.img is the name of your new recovery. They did something very similar to the kernel (LNX). I'm pretty sure that the correct way to do something like this is to use "dd" after verifying the image is correct (by running a hash against the image). I'm not sure why the Ouya team is using package_extract_file() instead of dd. I'm not in front of my Ouya though, LNX and SOS could be folders rather than block devices (although /dev/block seems to imply otherwise).

You can remove most of the other lines in the script that install the actual OTA update files. If you need help, let me know. I can make a custom update-script for you.

WARNING!!!!!!!! The above is just my take on things from looking at the scripts for 20 minutes. This could total brick your device if your recovery isn't of the right format or is not correctly built. Don't say I didn't warn ya.

You might want to read off the contents of the SOS to compare in a hex editor to your recovery. We might find out some things that would prevent a brick.
[Ouya Android Development] sonofskywalker3:
Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:

https://dl.dropboxusercontent.com/u/7653846/Archive.zip

So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?

my concern is that particular block doesn't show up on a mount command...
[Ouya Android Development] mybook4:
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.

I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.

One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).
[Ouya Android Development] sonofskywalker3:
Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.
[Ouya Android Development] mybook4:
It probably doesn't work because the update.zip we're using is signed.

Just a thought, but an easier way to go, albeit dangerous, is to do the following. You need root access over adb to do this. Using dd is VERY dangerous. THIS MIGHT NOT WORK. We need to make sure that what we are writing to (/dev/block/platform/sdhci-tegra.3/by-name/SOS) is truly the block device containing the recovery partition or else this might brick the Ouya. In the past, I've seen recovery written to /dev/block/mmcblk0pX, where X is the recovery partition for the particular device. I'm not much of a tegra guy. I know more about Samsung's stuff.

1) place the recovery.img on your ouya (let's say in /sdcard/recovery.img)

2) open a terminal running on your Ouya (over adb would probably be best, e.g. "adb shell")

3) enter a root shell, type "su"

4) make a backup of your existing recovery partition with "dd if=/dev/block/mmcblk0p1 of=/sdcard/origRecovery.img"

5) write the new recovery to the recovery partition with "dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p1"

6) perform the following from user mbm in the Ouya forums to get into recovery (thread http://forums.ouya.tv/discussion/1380/recovery-mode)

There are two big unknowns here:

1) We don't know for sure that the new recovery (CWM) will actually work

2) We don't know for sure that /dev/block/platform/sdhci-tegra.3/by-name/SOS is the correct place to be writing a recovery

I'll see what I can dig up regarding /dev/block/platform/sdhci-tegra.3/by-name/SOS

---------- Post added at 02:53 PM ---------- Previous post was at 02:30 PM ----------

/dev/block/platform/sdhci-tegra.3/by-name/SOS is a link to /dev/block/mmcblk0p1

So far, it appears that the layout is the following:

Kernel (boot.img) is mmcblk0p2

Recovery is mmcblk0p1

System is mmcblk0p3

---------- Post added at 02:56 PM ---------- Previous post was at 02:53 PM ----------

I would imagine that if the recovery partition really is SOS, then the above steps would work if you could run them as root.
[Ouya Android Development] rayman:
Some definite info:

SOS is recovery

OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine

It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.

As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.
[Ouya Android Development] rayman:
It's 8MB. If you dd to the block device (e.g. mmcblk0p1), you can't write out of bounds. The linux kernel knows the size and refuses it.
[Ouya Android Development] mybook4:
I did the following with skywalker's recovery.

1) Attached a usb keyboard to the Ouya's full size usb port

2) Attached my computer to the Ouya's micr usb port

3) Ran "adb reboot bootloader" (the Ouya rebooted to a blank screen)

4) Waited 30 seconds and ran "fastboot boot recovery.img" (skywalker's recovery file)

The Ouya rebooted into CWM Recovery v6.0.3.2!

Error messages were encountered on the recovery screen (image attached)

5) Navigated around CWM with the arrow keys and the enter key

6) Rebooted with "reboot system now". Ouya booted right up.

When we flash the recovery to mmcblk0p1, we should rename /system/etc/install-recovery.sh (and maybe /system/recovery-from-boot.p) to prevent the recovery partition from being overwritten.

Looks like we need to adjust the recovery so it properly mounts the partitions. Hopefully after that we are good to go.
[Ouya Android Development] sonofskywalker3:
Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.
[Ouya Android Development] mybook4:
I think it should be a matter of placing the proper partitions in the fstab prior to creating the recovery image. From the error messages it looks like /cache and /data are the culprits.

If you get a chance to, please post the fstab you use so we can double check everything (want to avoid the potential for bricks).
[Ouya Android Development] sonofskywalker3:
I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.

Update:

Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.

Update2:

I have compiled a new recovery using the following recovery.fstab:

/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC

/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP

/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA

/sdcard fuse /dev/fuse

this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:

can't mount /cache/recovery/command

can't mount /cache/recovery/last_log

can't open /cache/recovery/last_log

and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?
[Ouya Android Development] mybook4:
I'm still new at making a recovery.fstab, but I noticed the following:

From running "ls -l /dev/block/platform/sdhci-tegra.3/by-name/"

Since the APP, CAC, LNX files are links to mmcblk0pX devices, maybe we should be using the mmcblk0pX names?

We should look at more examples to see what the recovery.fstab for other devices looks like. From what I've seen of other devices, mmcblk0pX devices are listed in recovery.fstab.

P.S. So far, I think we are fairly certain that

APP is the system partition

CAC is the cache partition

LNX is kernel boot.img

SOS is the recovery partition

I'm not sure what the rest are (data, etc). Is there a definitive list somewhere?
[Ouya Android Development] sonofskywalker3:
Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:

/system	ext4	/dev/block/platform/sdhci-tegra.3/by-name/APP

/cache	ext4	/dev/block/platform/sdhci-tegra.3/by-name/CAC

/data	ext4	/dev/block/platform/sdhci-tegra.3/by-name/UDA	length=-32768

/misc	emmc	/dev/block/platform/sdhci-tegra.3/by-name/MSC

/boot	emmc	/dev/block/platform/sdhci-tegra.3/by-name/LNX

/recovery	emmc	/dev/block/platform/sdhci-tegra.3/by-name/SOS

/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP

Obviously this isn't exactly right, but it's a start until we can find more about the mounts.

I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.

Update:

Well still no love, and no noticeable progress between recovery 2 and 7, but I feel like we're chipping away in the right direction. I'll seek some help from some more experienced recovery people tomorrow.
[Ouya Android Development] mybook4:
Good stuff.

Not sure how we are going to get the field length= . I noticed the same field being used in the US Galaxy S III recovery https://raw.github.com/CyanogenMod/android_device_samsung_d2-common/cm-10.1/recovery.fstab

length= field is probably not needed, as the stock recovery doesn't list it.
[Ouya Android Development] mybook4:
Here's the recovery.fstab from my Ouya's recovery partition.

I tried doing CWM build with this recovery.fstab. /system, /data, and /cache all mounted.

Couldn't mount /sdcard automatically (trying to choose zip from sdcard) or manually (in mounts and storage, mount /sdcard).

I tweaked the recovery.fstab to the following:

This one mounted /sdcard correctly. I can "choose a zip from sdcard". I didn't actually choose a zip yet. I didn't format any of the partitions. I suppose we could try making a quick cwm zip to write something to the sdcard to test it out.

I've attached the stock Ouya recovery.img (from SOS partition). THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of the stock recovery.img. The md5 hash of the unzipped recovery.img is a6c1a6962984e9080ed8821628c4cc3f.

I've attached the CWM recovery.img that worked for me. THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of a newly built CWM recovery.img. The md5 hash of the unzipped recovery.img is c6b37906f280b16cd200503c3cde6dfb.
[Ouya Android Development] sonofskywalker3:
well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?

Update!

It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!
[Ouya Android Development] mybook4:
I edited the comment right above yours.

Recovery Builder wants the stock recovery.img, so I used adb to copy my Ouya's recovery partition to the sdcard, then I used adb pull to copy the recovery partition to my computer.

1) adb shell

2) su

3) cd /dev/block/platform/sdhci-tegra.3/by-name

4) dd if=SOS of=/sdcard/stockRecovery.img

5) exit

6) adb pull /sdcard/stockRecovery.img .

I used the recovery.fstab attached to this post. I obtained the stock Ouya recovery.fstab by doing the following:

I used split_bootimg.pl to split up the recovery.img into kernel and ramdisk (see Alternate Method in http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images). I used gzip to unzip the ramdisk and saw the stock recovery.fstab in /etc.

Here's what I did step by step:

1) split_bootimg.pl stockRecovery.img

2) mkdir ramdisk

3) cd ramdisk

4) gzip -dc ../stockRecovery.img-ramdisk.gz | cpio -i

in the ramdisk directory is etc/recovery.fstab

I then copied this file and edited the last line (/sdcard stuff). I used the new recovery.fstab with the Recovery Builder.
[Ouya Android Development] mybook4:
Awesome! Let us know how the backup/restore and zip flashing goes.

Once we verify that this CWM works correctly, people should be able write the new recovery by doing the following (NOTE this wasn't tested yet. I need to test it out first):

1) adb reboot bootloader

2) wait 30 seconds (blank screen is normal)

3) fastboot flash recovery recovery.img

4) fastboot reboot recovery (need a usb keyboard to navigate CWM)

5) flash a CWM zip to prevent stock recovery overwrite (we need to make this. The zip file should mount /system, rename recovery-from-boot.p to recovery-from-boot.bak, and unmount /system)

6) profit

Most of this could potentially be automated into a root/install CWM script.
[Ouya Android Development] sonofskywalker3:
Backup worked fine, flash worked and I'm booting now to make sure it put the files where it was supposed to and see if they work. Then i'll reboot and restore and make sure those files go away.One thing to note is that when i choose reboot system now it asked me to disable recovery flash,so I took the plunge and said yes, we'll see if it goes back to stock or not...

Update:

The .zip I built said it flashed correctly (unless i'm reading wrong the parts i could see with the overscan problems i'm having) but the files did not go to /system/app. I have attached the .zip file to see if I did something wrong with it, I just grabbed a sample from online and changed the files, haven't checked updater-script yet. I am restoring now, will post update on if that works.

It rebooted to stock recovery, as I expected, so still haven't flashed it just yet.

Well my oversensitive keyboard just hit enter twice so I'm actually backing up again, but I have to leave and take my daughter to a muesuem now, so I won't be able to continue until later. Good luck, i'll be keeping up with this thread on my phone.

Edit: removed non working zip
[Ouya Android Development] mybook4:
Yeah, I think install_recovery.sh is run on startup (init.rc of the kernel ramdisk tells it to run). I think we need to rename /system/recovery-from-boot.p to recovery-from-boot.bak in order to prevent the overwriting of the recovery partition.

UPDATE: Sure enough, that's what it was. I performed the following and now I have successfully flashed CWM to my recovery partition. I can reboot and it stays there.

1) adb shell

2) su

3) mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP

4) cd /system

5) mv recovery-from-boot.p recovery-from-boot.bak

6) exit

7) exit

8) adb reboot bootloader

9) fastboot flash recovery OuyaCWMRecovery.img

10) fastboot reboot

11) adb reboot recovery

NOTE: The updates issued by Ouya simply format the whole system partition and write an updated system partition. If you receive an update from Ouya, it will undo the change I described above and flash the stock recovery over CWM. Kind of annoying. We could prevent this from happening by turning off updates (I'm not sure how to do this yet). When Ouya releases an update, we could take the update.zip and modify it so that CWM wouldn't be overwritten. Not a huge deal.
[Ouya Android Development] professorpoptart:
Looks like the update script is mounting /dev/block/mmcblk0p2 as system. Shouldn't this be /dev/block/mmcblk0p3

edit:

probably need to add this too.

set_perm_recursive(0, 0, 0755, 0644, "/system/app");
[Ouya Android Development] mybook4:
Yeah you definitely don't want to do that! 0p2 is LNX (the kernel). I'm surprised it even booted after that flash! Skywalker, if you run into problems booting, let me know. We can fix it.

Better to do the following:

mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system");

We know APP is the /system parition.
[Ouya Android Development] professorpoptart:
with the music zip, once the right fstab is built into the recovery, wonder if we can just flash the regular gapps.zip and get the play store.

---------- Post added at 05:21 PM ---------- Previous post was at 05:10 PM ----------

could edit the build.prop and change the ro.update_url= to localhost or something? put it in an install.zip...