yashsingh1/xdaforums huggingface dataset:
[Verizon Galaxy S 5 Q&A, Help & Troubleshooting] Endalyor:
How so?

I'm in recovery mode now.. I don't have any CWM or anything like that, and I don't see any options.

Maybe I should try to apply the recent update and see if that resets everything?
[Verizon Galaxy S 5 Q&A, Help & Troubleshooting] Endalyor:
Updated to the latest version.

Doesn't look like that helped anything.

Still locked, and I don't want to try another password incase I'm still on my last try.
[Verizon Galaxy S 5 Q&A, Help & Troubleshooting] Endalyor:
I can set up the ADB while in recovery mode... Can I backup via the ADB in recovery mode?
[Verizon Galaxy S 5 Q&A, Help & Troubleshooting] Endalyor:
When I use adb devices, my device comes up as "sideload" rather than device? Why?
[Android Apps and Games] Brocker7:
Any new updates?
[Android Apps and Games] DarkSandmaN:
This dont work as i see :( 6.0.1 mm on xperia z ultra
[Android Apps and Games] rony raj:
thanks great one
[Android Apps and Games] anjel05:
Hopefully dev will continue this app
[Android Apps and Games] dangquoctrung123:
Man hope you will continue this app, like adding more resolution that fit screen ratios like 18:9 etc.
[Samsung Galaxy Mini] andersonajx:
Hello.

I do need some help. I tried installing CMW and when I rebooted it, it simply doesn't work anymore. It doesn't turn on. I hold power button and anything happens. I tried entering in download mode, recover mode and nothing. I tried using Odin. It detects the phone, but nothing happens. Setup connection forever and ever. :(

Can anyone help me?

P.S. I've ever googled, but I didn't find anything.
[Samsung Galaxy Mini] Mr_Intel:
If ur phone detected by ODIN, may be u can recover ur phone back try these steps : http://xdaforums.com/showthread.php?t=2226030
[Samsung Galaxy Nexus] bamtan2:
Update 1: Adding a simple proposal which leaves /data untouched.

Premise: Nexus 6 has a smaller cache partition than Galaxy Nexus, which implies Google thinks we're wasting space on our /cache. ;) Leaving /data untouched is very convenient. So instead of focusing on how large we want /system to be, we can focus on how small we want /cache to be, and then accept whatever benefit to /system that provides.

I do not have the exact numbers. But if Galaxy Nexus /cache is ~720MB, and Nexus 6 /cache is ~248MB, then that means we could add ~472MB to /system, which is a LOT.

Does anyone think this would be too much or too little? Do we need more /cache space than Nexus 6?

Can anyone find the exact numbers to compare what we would get from this change? I don't have a Nexus 6 to read the exact size of /cache.

We must be wary of taking away too much /cache space if we risk preventing new features in the future. For example: Moto X (2013) and Moto G (2013) both use F2FS, and F2FS may demand cache use. I am curious what their /cache partition sizes are.

CC [MENTION=4544860]osm0sis[/MENTION] [MENTION=2633638]Ziyan[/MENTION] [MENTION=4608636]bsmitty83[/MENTION]
[Samsung Galaxy Nexus] bsmitty83:
Gnex /cache is 432 mb , n6 on m preview has 256 mb . but I have far more apps on my n6 yet only 13 mb used , as opposed to 137 mb used on my gnex . so I think the cache size is fine . the n6 has triple the ram , double the cpu cores , and doesn't really have to cache data .

Personally I would wait until the time comes when a ROM is too big to fit on the current partition . I don't necessarily think its a bad idea at all , I just don't have a need to touch my partitions right now .
[Samsung Galaxy Nexus] osm0sis:
I've never seen the /cache partition on modern (>ICS) Android be used for anything but OTA temp storage, and the GN certainly isn't receiving any more OTAs so I agree we should at least take the overhead of 425.2-256 and add it to system. App caches are stored in /data/data, so I honestly don't think /cache needs any more than 128, and even that's probably just playing it safe.

I'll post on some of the other research I've been doing for this in my limited spare time, hopefully next week.
[Samsung Galaxy Nexus] bamtan2:
This is an excellent post! Exactly why we need to have this discussion! We want to leave no stone unturned. Your point about not changing until we need to is EXCELLENT. Sometimes we all need to put on the brakes and not fix what's not broken. PS: Of course I got the numbers wrong RIGHT after I had been looking at them *forehead smack* ;) 200MB saved, not 400mb, of course.

In my experience the /cache has not really been used for anything. Now is a good time to collect information from all interested parties about how the cache can and will be used.

That is really informative, thank you!! I look forward to hearing more of what you've learned about /cache usage!

It sounds like we might be onto something here...
[Samsung Galaxy Nexus] mn.code:
[MENTION=4544860]osm0sis[/MENTION] I didn't have maguro last two months, I sold titanium colored one and now I bought a white one :) So, as promised, I will write a tutorial on how to flash new pit and how to untar the file [MENTION=1048318]zzpianoman[/MENTION] provided as soon as I get home from vacation. Also, I will make a new pit file (old one "borrowed" space only from /data), I will increase /system with another ~200MB (will take some from /cache and maybe some more from /data), so the /system partition will be around 1,2GB.
[Samsung Galaxy Nexus] osm0sis:
After examining a raw dump I did of the beginning of mmcblk0, the PIT dumping command for our device is definitely:

dd if=/dev/block/mmcblk0 of=/sdcard/out.pit bs=1 count=4096 skip=17408;

My maguro dump is different from the maguro -0915.pit posted at the Stock PIT link I added above, so I'd definitely like to see a PIT dump from another maguro, a toro and a toroplus for me to compare. I'm going to open them up in PIT Magic and see what it registers the differences as next.

Edit

: Interestingly, the only difference was with userdata. "Block Count" was 28,397,534 with mine, and 31,174,656 with the supposed "Stock PIT". That certainly wouldn't account for 32gb vs. 16gb (which is something we will definitely have to accommodate), so my best guess is EMMC chip type?

d=/sys/class/block/mmcblk0/device;
echo "Name: `cat $d/name`\nManufacturer ID: `cat $d/manfid`\nFwRev: 0x`cut -b 19,20 $d/cid`\nDate: `cat $d/date`";

I'm running everybody's favorite ;):

Name: VYL00M
Manufacturer ID: 0x000015
FwRev: 0x25
Date: 12/2011

So I'll want another VYL00M and non-VYL00M 16gb maguro to figure this out.

Edit 2

: Fixed the command above. bs=1 when it's not a raw dump apparently. :good:
[Samsung Galaxy Nexus] bsmitty83:
I'll dump my 32gb toro when I get home in a little bit . most Toro's are 32gb anyways so it should suffice
[Samsung Galaxy Nexus] osm0sis:
Okay, here's what I've worked out:

PIT structure -

block sizes, 4 bytes (little endian) from offsets:

system=1500

cache=1632

userdata=1764

block counts, 4 bytes (little endian) from offsets:

system=1504

cache=1636

userdata=1768

blocks / 2048 * 1024 = kB

system = 1,339,392 = 669696 (654 MB)
cache = 884,736 = 442368 (432 MB)

userdata("stock") = 31,174,656 = 15587328 (15222 MB) [maguro, ?]
userdata(bamtan2) = 28,397,534 = 14198767 (13865.9833984375 MB) [maguro, GT-i9250]
userdata(osm0sis) = 28,397,534 = 14198767 (13865.9833984375 MB) [maguro, GT-i9250M]
userdata(bsmitty83) = 59,944,926 = 29972463 (29269.9833984375 MB) [toro, SCH-i515]
userdata(musical_chairs) = 59,944,926 = 29972463 (29269.9833984375 MB) [toroplus, SPH-L700]

In all files but [MENTION=4263181]mn.code[/MENTION]'s nothing changes but the block counts, even with the jump from 16gb to 32gb. He's changing block size on everything as well and I'm not sure that's something we should touch.. Maybe he can explain? :)

I still need toro SCH-i516 (16gb Verizon), another couple maguros with different MMC chips, ideally one from the Play Store (maguro GT-i9250) too, and of course toroplus SPH-L700 (32gb Sprint) for a proper comparison.

Edit

: I tried generating and flashing a PIT based on my own dump (seems like the safest approach to avoid exceeding chip capacity), simply by subtracting 304mb of blocks from cache and adding them to system (so cache at 128mb, and I also tried cache at 256mb), and I could not make it stable... Damn thing kept corrupting system when I'd format cache and vice versa.

So I then took the risk and flashed [MENTION=4263181]mn.code[/MENTION]'s instead and it definitely works. So he'll have to tell us what the trick is with the math. In better news, there's no need to mess around with tar's like we thought, even if [MENTION=2633638]Ziyan[/MENTION] doesn't go back to file OTA-style flashable zips for awhile, since TWRP's new(ish) Resize FS command resolves it. Run it after flashing the ROM then you have your space added back to flash GApps, etc. Really, we want addon.d support though, so hopefully ZMoD will be switched back anyway, but this is a simple workaround for now.

Edit 2

: Updated with the latest. A 16gb Verizon i516 and a couple maguros with different emmc chips (non-VYL00M) would be appreciated now. Thanks everyone!
[Samsung Galaxy Nexus] musical_chairs:
Here's a dump from a toroplus - is this what you are looking for?
[Samsung Galaxy Nexus] bamtan2:
[MENTION=4544860]osm0sis[/MENTION] Mine is like yours, but 1 month senior:

1|u0_a65@maguro:/ $ su

blk0 of=/sdcard/out.pit bs=1 count=4096 skip=17408;

4096+0 records in

4096+0 records out

4096 bytes transferred in 0.442 secs (9266 bytes/sec)

root@maguro:/ # d=/sys/class/block/mmcblk0/device;

name`\nManufacturer ID: `cat $d/manfid`\nFwRev:

> 0x`cut -b 19,20 $d/cid`\nDate: `cat $d/date`";

Name: VYL00M

Manufacturer ID: 0x000015

FwRev:

0x25

Date: 11/2011

:P
[Samsung Galaxy Nexus] mn.code:
[MENTION=4544860]osm0sis[/MENTION] Your cache partition is getting corrupted because PITMagic, for some reason, is not saving new values for /userdata partition (so /cache and /userdata are overlapping). You have to change them manualy with hexedit after you change all other partitions (it's kinda tricky and a little pain in the a** :D ). Also, Block Size value of current partition must be the sum of Block Size and Block Count of the previous one (it is the point from which the current partition starts). New PIT is on the way :)
[Samsung Galaxy Nexus] osm0sis:
Thanks guys! I've updated my previous PIT structure post with your info. Now I just need a couple non-VYL00M EMMC chip devices. :)

Ahh nice! I'll give it another shot next chunk of free time I get. Can one of your new PIT files have /cache at only 128MB, /data untouched, and /system with the added ~304MB reclaimed from /cache? That's what I was going for so it'd be much appreciated for my testing purposes. Thanks! :D
[Samsung Galaxy Nexus] mn.code:
Sure, will make one as soon as I catch some spare time :)

Here is the new pit, /system is 1280MB, /cache 248MB and the rest is /data.

Edit: Here is another pit, the one you requested, /cache is now 128MB, 304MB reclaimed to /system, /data untouched. INFO: if you used any of my pits before flashing this one, your /data might get corrupted and you won't be able to repair it with official twrp 2.8.7.0, you must use the one [MENTION=2633638]Ziyan[/MENTION] made (2.8.6.0 with f2fs support) and it will work fine.
[Samsung Galaxy Nexus] mn.code:
Well, my PITs use that value for userdata because I base them on -0915 "Stock PIT" file. I didn't dump mine before I edited it the first time, I just flashed that one since it came with stock firmware (Odin.stock.takju.jwr66y+4.3.zip) :D

When you flash my PIT, is your /userdata size changing?
[Samsung Galaxy Nexus] osm0sis:
Answered that in my first edit above. I'm wondering if you have any insight into what I mention in my second and third edits as well. :)
[Samsung Galaxy Nexus] mn.code:
Are you using official TWRP 2.8.7.0 or the one with f2fs that Ziyan made (2.8.6.0)?
[Samsung Galaxy Nexus] osm0sis:
Official, which has worked perfectly for everything on my end when a working PIT is flashed via Odin, resizefs, format and everything. I was more hoping for your ideas on what Odin could be doing after flashing that I'm not when I edit the PIT directly.
[Samsung Galaxy Nexus] mn.code:
For what I know, after flashing Odin just reboots your phone (when you flash just PIT). About partitions being corrupted, I had this issue with official recovery even when I flashed with Odin (but I was changing sizes for all three partitions). You can try with Ziyan's modified one, that was solution in my case.
[Samsung Galaxy Nexus] osm0sis:
Yeah, I already ruled that out by flashing the dump of my modified PIT via Odin, and then everything worked like it should in official TWRP again, so there must be something extra Odin is doing to force the repartitioning to work correctly. I'll keep experimenting I guess.
[Samsung Galaxy Nexus] mn.code:
[MENTION=4544860]osm0sis[/MENTION] I had to restore my maguro to stock, so I dumped my pit and it turns out my /userdata is not the same size as the one on "stock" pit, it's the same size as yours 28.397.534 (and I also have VYL00M chip) :)

Will dig deeper after I' am finished with my exams, I have only three exams and one android project left to finish college, so I must get serious with it :D
[Samsung Galaxy Nexus] osm0sis:
I did a more thorough hex comparison of the dumps people have uploaded and the working generated ones from PIT Magic and found a few more differences:

$ diff [color=blue]test.xxd[/color] [color=red]backup.xxd[/color]
13c13
< 00000c0: 0000 0000 6770 7400 [color=blue]0000 00[/color]00 0000 0000 ....gpt.[color=blue]...[/color].....
---
> 00000c0: 0000 0000 6770 7400 [color=red]6465 72[/color]00 0000 0000 ....gpt.[color=red]der[/color].....
38c38
< 0000250: 6566 7300 [color=blue]0000 00[/color]00 0000 0000 0000 0000 efs.[color=blue]...[/color].........
---
> 0000250: 6566 7300 [color=red]6f72 79[/color]00 0000 0000 0000 0000 efs.[color=red]ory[/color].........
40c40
< 0000270: 6566 732e 696d 6700 [color=blue]0000 00[/color]00 0000 0000 efs.img.[color=blue]...[/color].....
---
> 0000270: 6566 732e 696d 6700 [color=red]696d 67[/color]00 0000 0000 efs.img.[color=red]img[/color].....

Not sure if this would explain my issues with rewriting the PIT on-the-fly, since writing a new dump afterward seems to work too, but it's a definite difference between the unaltered dumps/backups and the others as written via PIT Magic/Odin3 so I'm going to try adding zeroing those areas to the script to see if it helps.
[Samsung Galaxy Nexus] mn.code:
That might actually work, it totally makes sence. You see the "string" values that differ, for example "efs.img" and "efs.img.img", so if you zero out the difference, maybe device will think it's flashed by odin. At the moment I don't own a maguro, so I am not able to experiment with it....
[Samsung Galaxy Nexus] Oehr:
I just want to add my two cents to this thread as a consumer and not as a developer:

I use encryption on my GN, however encryption is unsupported by the custom recoveries available since the release of LP 5.0.

So in order to update a custom rom, I rely on the cache partition temporarily to keep the various zips (rom, kernel, supersu, etc) that are to be flashed.

This can easily amount to over 256MB of data, especially when including google apps (which I dont).
[Samsung Galaxy Nexus] osm0sis:
Added the following to the end of pitfix.sh (on the previous page):

# zero minor gpt/efs areas of the PIT to mimic external editing and flashing
for i in 200 596 632; do
echo -ne "\x00\x00\x00" | dd obs=1 count=3 seek=$((i+pit)) of=$block;
done;

And it now produces a resulting dump identical to a test.pit created by PIT Magic, but still no luck getting recovery to recognize the changes on-the-fly, nor after a reboot to recovery, bootloader or download mode; fastboot format of cache and system still formats them to the correct new size but then they don't work in recovery like they do after ODIN flashing as I reported before. There still must be some more voodoo ODIN is doing we haven't figured out how to replicate. :(

My best guess would be it doing something similar to what OTAs do with multi-part radios, bootloaders, etc. now - writing text files out to param/misc partitions and such to trigger the reset - but I have no idea how to figure out what exactly ODIN is doing let alone how we can make recovery think it's done it.

I may have to just turn this into a flashable zip .pit backup and modifying solution, then the user will have to pull the resulting .pit off of their /sdcard and flash it with ODIN, i.e. no fun at all and cutting the usefulness/user-friendliness in half. :mad:
[Samsung Galaxy Nexus] bamtan2:
Brilliant work [MENTION=4544860]osm0sis[/MENTION] !!! While maybe not what you had originally hoped for, this is still huge progress because it allows any normal enthusiast to modify their system. Thank you for your work, and for sharing your code to the world ;) :)
[Samsung Galaxy Nexus] musical_chairs:
Rats! Is there any way to flash this from Linux? I don't have any working Windows machines any more. (do have a working XP virtual machine, but it looks like the more recent versions of odin do not support XP.)

Thanks for your work all the same.
[Samsung Galaxy Nexus] osm0sis:
[MENTION=4531957]musical_chairs[/MENTION], from a quick Google, looks like Heimdall is the best option:

http://www.webupd8.org/2012/06/heimdall-odin-alternative-that-runs-on.html

http://glassechidna.com.au/heimdall/

:D

Added the main link to it to the zip post. Also noticed I missed something with the zeroing part in my last fix so I've reuploaded again and it should be producing byte-for-byte identical files to PIT Magic again. :good:
[Samsung Galaxy Nexus] ghost010:
How is this working for others? Any issues yet? have not try'd it on mine yet but i have been following this thread for a while, have not contributed cuz i'm not a dev.

Has any one tryd this with 6.0? Or would you just stick with 5.1 or lower? I'll be reporting my experience once i get to setting up the programs.
[Samsung Galaxy Nexus] osm0sis:
It's independent of Android version, but with L+M having much larger APKs than KitKat it'll be helpful for using GApps packages with either. :)

Edit: I'm going to unsubscribe since I feel this project is complete now. Mention me or post in my Odds and Ends thread if you need me. :good:
[Samsung Galaxy Nexus] defy_owner:
[MENTION=4544860]osm0sis[/MENTION] Thanks for your procedure!

I have only a simple question: why after flashing a rom (in a zip file) the partition reverts to the original size? I have to use "resize FS" option in TWRP every time between the rom zip and the gapps zip. Did I make any mistake in the PIT procedure?
[Samsung Galaxy Nexus] osm0sis:
Nope. The problem is [MENTION=2633638]Ziyan[/MENTION] et al. are using the system.dat style zips for flashing, which flash the block whole and have a built-in partition size when they're built, hence the reversion of size.

Really, they should switch back to file-based OTA format; Google only switched to system.dat for devices that launched with Lollipop, and that was only because they started enforcing system block verification for whole-block patching.

The best example of this is that the Nexus 5 and Nexus 7 2013 still use file-based OTAs, thus so should Galaxy Nexus, since we're not getting official OTAs and going back to file-based would stop screwing with the partition size, and also allow people to use addon.d again so they could update ROM builds and not **** up their GApps, etc ;)
[Samsung Galaxy Nexus] Lanchon:
so why don't you run the device-dump tool and post an issue with the output? this could have been mostly solved already.

btw, you dont need to standardize; beyond stock everybody has his or her own view of what they want. (and many have uninformed views for sure.) but with the lucky stock layout in which you can grow system without wiping data (and thus your emulated sdcard), REPIT is a bit of overkill. it is still better i think than PC-based heimdall or odin. lets add this option then move on. the CM maintainer(s) have to neglect non-partitioning users; that is the only way to overcome the issue. make useful tools, then depend on them. otherwise people are lazy and will never change.
[Samsung Galaxy Nexus] thagringo:
Thanks [MENTION=4545566]bamtan2[/MENTION]. Have uploaded my dump here :

https://github.com/Lanchon/REPIT/issues/25

Cheers

Enviado desde mi Galaxy Nexus mediante Tapatalk
[Samsung Galaxy Nexus] Lanchon:
thanks! done:

https://github.com/Lanchon/REPIT/issues/25
[Samsung Galaxy Nexus] thagringo:
cool, thanks !

havent tried or looked at it yet, 2 questions though :

- you say resizing /data is slow and inefficient. If i wipe everything and there is only resizing involved ( no data ) will it take less ? Or is it just a software limitation ( gpt, parted or whatever you use) or hardware limitation ? MMC on this thing is crappy as hell, wouldnt be suprised if it takes a lot longer than it takes on a i9100.

- in case sth. goes wrong and the partition table goes to hell i guess the only thing i have to do is flash over a stock image ?

havent really digged into your sources or havent read much about Repit yet so sorry in advance if these are silly questions.

thanks for your time !
[Samsung Galaxy Nexus] thagringo:
just tried, wiped everything except internal storage and got this :

Installing zip file '/sdcard/lanchon-repit-20160404-system=1.0-cache=0.0605+wipe-data=same-maguro.zip'
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
I:Zip does not contain SELinux file_contexts file in its root.
I:Legacy property environment initialized.

Illegal instruction

[ERROR 132]

Updater process ended with ERROR: 132
I:Legacy property environment disabled.
Error installing zip file '/sdcard/lanchon-repit-20160404-system=1.0-cache=0.0605+wipe-data=same-maguro.zip'
Updating partition details...
I:Data backup size is 0MB, free: 11192MB.
I:Unable to mount '/usb-otg'
I:Actual block device: '', current file system: 'vfat'
...done
I:Set page: 'flash_done'
I:operation_end - status=1
I:Set page: 'clear_vars'
I:Set page: 'install'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Set page: 'advanced'
I:Set page: 'filemanagerlist'
I:Set page: 'filemanageroptions'
I:Set page: 'choosedestinationfolder'
I:Set page: 'filemanagerconfirm'
I:Set page: 'filemanageraction'
I:operation_start: 'Command'
I:Running command: 'cp "/tmp/recovery.log" "/sdcard"'

tried with both latest official twrp and unofficial 3.x twrp.

Thanks !
[Samsung Galaxy Nexus] Lanchon:
you dont need to wipe anything!!! just don't resize /data, or pay the price of a long process.

what do you want to attain with repit? reduce /cache and have a 1GB /system partition? those are the default settings, /data is not resized nor wiped.

---------- Post added at 02:50 PM ---------- Previous post was at 02:37 PM ----------

wiping before repit WILL NOT MAKE ANYTHING ANY MORE EFFICIENT AT ALL !!!

you need to read the repit instructions, if you want to wipe you need to tell repit to wipe, not wipe before and then let repit work for an hour moving and empty partition!!!

unfortunately your kernel in incompatible with the binaries in REPIT. (they come from TWRP2 for Nexus 5.) this is a problem because in maguro kernel and recovery come together and you can't switch... :(

https://github.com/Lanchon/REPIT/issues/23#issuecomment-205392431

i'm very sorry this didn't work, i should be able to fix it when i have time, but i'm really baffled by this.
[Samsung Galaxy Nexus] thagringo:
yeah, sorry, was a bit confused with the naming scheme. Of course /data is untouched by default.

ok, thanks. Saw that ticket too but wasnt sure if it was related or not.

If you need a guinea pig to test sth. once you have it ready just let me know :)

thanks !
[Samsung Galaxy Nexus] Lanchon:
new release should fix all issues!!! ;)

https://www.androidfilehost.com/?w=files&flid=53660