Develop Bugs

[IDEA] Android rescue.zip project..

So i am here with a new idea. A rescue.zip which can be used to rescue any android device which have a recovery like the famous cwm.
So here is it..
Some times we people screw up our android os like hell, and to reboot the device we usualy do a recovery flash of a new os, flash back our nandroid backup ( both on worst conditions) or even do permission fix, clean cache or dalvic cache( those in 'not that worse' conditions) . So thats are all the options we got. Rit?
Although flashing recovery backups, new roms can fix all, it will also eatup our apps, current setups, contacts, msgs, etc( in case we dont have backups) and will probably screw us. All we can do is say " WTF..WTF..WTF.."
SO here is my idea,
Find out the causes of what causes a reboot, non-boot, hang,fc etc.
And keep a zip that can be flashed through recovery, that has a solution for our problem. They may be including..
1) fix permission of system, data, and user data.
2) zipalign the apps
3) fix the default clock speed of processor
4) defragment memory
5) flash a new copy of su and busy box
6)wipe data or system or ext or cache or dalvic cache
7) flash a new copy of framework.res, system-ui.apk, settings.apk with default permissions( those files are kept in separate "custom" folder on the zip, so that end user can put their own files to that "custom" folder for flashing., the reason behind it is known to all, yap. Not all devices have them in common, every device have its own files)
These are all i got for now, pls post ur ideas and knowledge for any possible cure about any problem u faced/ cured. So that we can make it an ultimate rescue.zip that have a cure for 99% problems android os have. The rest 1% will go with a clean flash.( well we cant avoid that if we did something that bad).
So my plan is to use aroma installer( now on hard learning to find how it works). Throw in some scripts, files etc. Into the zip.
And since its not a device specific .zip file, i want to know how and why any problems are caused in any device( there are many common problems, but that is not what i ask for. I ask for device/os specific problems, and not for a problem that we can cure after booting, but for a problem that can make the device un-bootable) . So u people may help me to find those problems and cures for it. For my knowledge i have experience with wildfire and hd2.
Well i will keep this thread for a week or two, so that u can post ur knowledge, and info. after that i will release the file for u.
To the admin. Of the forum, pls keep this thread as announcement so that all can take a look.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

If you plan to do this available to any android device, the file size will be so big that it will become useless. Every phone has different apk, and not only that, but those apk are different in different version of os. For example, CM9 framework should not work on google release. Worst, older CM9 framework might not work on newer CM9 and newer framework might not work on older. Also, one of the cause of bootloop that i have been experiencing since i have my GNexus is data corruption of apps. The only way i had was to wipe data. I dont think there is a way to know if your app are corrupted with script. I also seen a lot of strange problem on SGS II like the kernel being erased. Well, in this case this package would be useless. So i guess that having this package would be awesome, but wont happen. My best advice is that you could create a universal guide on how to recover from bootloop/fc/hang with the minimum of impact on the phone. This is just my opinion tho.
Sent from my Galaxy Nexus using xda premium

You could add using flags in the updates filename, see some roms or themes for the lg optimus 2x for more information. It uses sed. For example, "update-wc-wd.zip" would wipe /data and /cache.
You could also merge these features in a customized clockwork mod recovery, the up side would be that you could automatically make a backup of the last flashed full ROM's systemui etc. this would also allow usage of the touch screen/volume keys to choose an repair option. You could even allow users to backup specific applications along with their data, and let users restore it later on after a fresh flash. I have some basic knowledge in modifying the recovery so I might help you out a little if you're interested.

chadouming said:
If you plan to do this available to any android device, the file size will be so big that it will become useless. Every phone has different apk, and not only that, but those apk are different in different version of os. For example, CM9 framework should not work on google release. Worst, older CM9 framework might not work on newer CM9 and newer framework might not work on older. Also, one of the cause of bootloop that i have been experiencing since i have my GNexus is data corruption of apps. The only way i had was to wipe data. I dont think there is a way to know if your app are corrupted with script. I also seen a lot of strange problem on SGS II like the kernel being erased. Well, in this case this package would be useless. So i guess that having this package would be awesome, but wont happen. My best advice is that you could create a universal guide on how to recover from bootloop/fc/hang with the minimum of impact on the phone. This is just my opinion tho.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
I told it already, the "custom" folder is not filled. It will be kept empty. The user can put a file, which ofcourse is the file of the device he/she have or want to get repaired. All he has to do is copy and paste the file from the working zip( zip file of his currently installed rom, that encounter the problem) of his rom to the custom folder inside the rescue.zip.
And the things that are common will be scripts, but those too will contains device specific mound points, paths, etc. I think that will be common( ie, the working of script, once the mound is done). Am i right?
So all i have to figure out is mount points, paths etc.. i got a couple of them, about 15 or so. And pls help me to find the rest.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

a good idea to add is a file system chech like windows systems has. By installing a rom the installer should first check for bad sectors and mem blocks before installing the rom. After all blocks and sectors are scanned and the bad ones marked as "bad or corrupt" it should run something like defrag and place the bad blocks at the end of the file table. When all is done .. then the true rom install should start.
This will prevent heaps of problems since the curent installs just write over a bad block or sector creating the most weird problems. A fault checker/repair will take away a lot of strange forced closes and othere software/hardware failures.
Most phones wont last that long so that bad blocks or sectors can occure. But for the flashing junkies among us its a serious problem what can occure. I guess after 1000 or more installs bad sectors or blocks will occure and not all are being able to be repaired
Sent from my Galaxy Nexus using XDA App

Mikevhl said:
You could add using flags in the updates filename, see some roms or themes for the lg optimus 2x for more information. It uses sed. For example, "update-wc-wd.zip" would wipe /data and /cache.
You could also merge these features in a customized clockwork mod recovery, the up side would be that you could automatically make a backup of the last flashed full ROM's systemui etc. this would also allow usage of the touch screen/volume keys to choose an repair option. You could even allow users to backup specific applications along with their data, and let users restore it later on after a fresh flash. I have some basic knowledge in modifying the recovery so I might help you out a little if you're interested.
Click to expand...
Click to collapse
I am totaly newbee to lg. I have experience with htc, few samsung, etc. So can u pm me the details? Also is it usable to create recovery? I think a zip file with selectable options is more friendly. The thing is building a recovery wont make it universal( or atleast common for a couple of devices) and we will have to port them for each and every device. Thats the problem.
But any way i want ur help in building it. Can u pm me an example for mounding script in lg devices? And any thing that may become useful. Thank you.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

wilwilwel said:
a good idea to add is a file system chech like windows systems has. By installing a rom the installer should first check for bad sectors and mem blocks before installing the rom. After all blocks and sectors are scanned and the bad ones marked as "bad or corrupt" it should run something like defrag and place the bad blocks at the end of the file table. When all is done .. then the true rom install should start.
This will prevent heaps of problems since the curent installs just write over a bad block or sector creating the most weird problems. A fault checker/repair will take away a lot of strange forced closes and othere software/hardware failures.
Most phones wont last that long so that bad blocks or sectors can occure. But for the flashing junkies among us its a serious problem what can occure. I guess after 1000 or more installs bad sectors or blocks will occure and not all are being able to be repaired
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
Pls pm me the idea how to make the checking script. Or links that have info in this. Thank u in figuring out such a prob. I am unaware of that.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.

showlyshah said:
I am totaly newbee to lg. I have experience with htc, few samsung, etc. So can u pm me the details? Also is it usable to create recovery? I think a zip file with selectable options is more friendly. The thing is building a recovery wont make it universal( or atleast common for a couple of devices) and we will have to port them for each and every device. Thats the problem.
But any way i want ur help in building it. Can u pm me an example for mounding script in lg devices? And any thing that may become useful. Thank you.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.
Click to expand...
Click to collapse
I'll send this as a PM as well, but people might learn from this. I am not talking about any specific mount points for LG phones, I just pointed out that there are some roms which use sed to check the filename of its update.zip and do tasks according to that, you need to have one line in your updater script to run the script which detects what to do. That way a user of a Galaxy Nexus would rename it to update-maguro.zip and it would know to use mount points for the maguro, while if the exact same update.zip was to be named update-p990.zip, it would know to use the mount points for the LG optimus 2x. This way you could easily keep the zip up to date for any device, because they all use the same update.zip
About the recovery, you would need to build it for every phone once, but you could make one change to the recovery source and easily compile the recovery for all phones which are capable of running CWM. I believe this method to be more user friendly, as a recovery image has support for actually choosing what you want to do, instead of having to rename the file. A recovery image also has a better way of communicating with the user. Where a update.zip can only say "Hey, I had an error and I'm quitting now, I won't give you any details what the problem was because that's just how update.zips roll", a recovery image would be able to give more advanced outputs, like "An error occurred when trying to mount /data." And then give you the option to either try again, manually fix it by using a computer with adb, or quitting.
But that's just my personal opinion. The recovery would be way harder to make, but I was the original porter of CM6, CM7 and HTC Sense to the xperia mini pro and mini back in the days. I also made a custom recovery and roms for the HTC desire Z, maintain a CWM port for the HTC Chacha which I don't even own and have used the LG optimus 2x before. (currently a maguro owner) but I'm trying to say that I've been experimenting a lot with different phones and know what the possibilities of Android are. you could even make a live Android build, tailored for recovering your phone, which is ran by an update.zip! How cool is that? That would be VERY device specific though..
let me know what you think is the best way to do this. I was thinking of making a mobile time machine app for some time so it's good I saw this thread.

ROM for AT&T

Got my Note 2 in today .. any ROM's known working with this hardware ? I'd read there might be issues with so many different versions of this device.
Thanks !

Sorry, but the i317 doesn't have any ROM. Not a single byte of it.
Perhaps you were asking about firmware?

garyd9 said:
Sorry, but the i317 doesn't have any ROM. Not a single byte of it.
Perhaps you were asking about firmware?
Click to expand...
Click to collapse
Interesting point. What are the firmwares stored in inside these modern devices? Are they not EEPROMs or some variant that are being flashed?

Non-volatile random-access memory.
All the memory in the device is one big pool similar to an SSD drive (even if its partitioned and mounted to appear otherwise.)
EEPROM would be WAY too slow (and wouldn't have the endurance.) Also, with EEPROM, you'd have to effectively erase and reformat all the device memory every time you got a new email message, logged a phone call, etc. (No random access with EEPROM.)
Yeah, I'm old.
Understanding the firmware... imagine shoving an SSD drive into a machine and making 2 partitions. The first you call "C" and install windows on. Then you create another partition ("D") to use as a data drive. You hack windows so that all writes are redirected to D. Now only mount the C drive as ro and mount D as rw.
This is easier with linux... first logical contains /usr, /etc, /home. /home contains mount points for the second logical that's mounted rw. Any time the firmware changes, the first drive is remounted as rw, changes made, and remounted as ro again.

ohRonaldo said:
Interesting point. What are the firmwares stored in inside these modern devices? Are they not EEPROMs or some variant that are being flashed?
Click to expand...
Click to collapse
I think his point of the question is that ROM usually would be a new aftermarket offing, say CM10 etc. And the Firmware refers to the Sammy official stock load or image (TAR?) that is flashed in ODIN or perhaps Keis.
I don't think that was a discussion on hardware.

ZedZardoz said:
I think his point of the question is that ROM usually would be a new aftermarket offing, say CM10 etc. And the Firmware refers to the Sammy official stock load or image (TAR?) that is flashed in ODIN or perhaps Keis.
Click to expand...
Click to collapse
How are they different? Either mount as /system and perform the same function. They are both firmware.
ROM means "read only memory." If it was actually ROM, it couldn't be modified.
If it'd help, I'd be happy to recompile CM10 for the i9300 and wrap it up in an ODIN compatible tarball.

garyd9 said:
How are they different? Either mount as /system and perform the same function. They are both firmware.
ROM means "read only memory." If it was actually ROM, it couldn't be modified.
If it'd help, I'd be happy to recompile CM10 for the i9300 and wrap it up in an ODIN compatible tarball.
Click to expand...
Click to collapse
Agreed. Just bits programmed to a memory.
garyd9 said:
Sorry, but the i317 doesn't have any ROM. Not a single byte of it.
Perhaps you were asking about firmware?
Click to expand...
Click to collapse
Now that I re-read your post, I see that it was a discussion of hardware. But aren't you just quibbling on symatics?
Off-topic> Is there a way to dump the TAR off my new phone prior to root? I guess some day the official firmware will become available.

ZedZardoz said:
Is there a way to dump the TAR off my knew phone prior to root? I guess some day the official firmware will become available.
Click to expand...
Click to collapse
Not all at once. The stock kernel and stock recovery images are already extracted. What I'd suggest is this:
After you get your phone, use ODIN to install the root kernel referenced in this post: http://forum.xda-developers.com/showpost.php?p=33846420&postcount=163
Then adb shell into the phone, but when you do the dd thing, instead of pulling the recovery partition, you can pull the system partition. The commandline would be:
dd if=/dev/block/mmcblk0p13 of=system.img bs=4096
That will result in a huge (but completely stock) system partition image. That, combined with the recovery.img and boot.img (kernel) we already have can be used to get a system completely stock.
PS: I hope the community gets you a Note2 soon!
Click to expand...
Click to collapse
Why? I just sold an international note2 and am using an AT&T note2. If the community were to try to donate one to me, I'd tell them to take their money and donate it to some children that need food, clothes, etc.

garyd9 said:
Not all at once. The stock kernel and stock recovery images are already extracted. What I'd suggest is this:
After you get your phone, use ODIN to install the root kernel referenced in this post: http://forum.xda-developers.com/showpost.php?p=33846420&postcount=163
Then adb shell into the phone, but when you do the dd thing, instead of pulling the recovery partition, you can pull the system partition. The commandline would be:
dd if=/dev/block/mmcblk0p13 of=system.img bs=4096
That will result in a huge (but completely stock) system partition image. That, combined with the recovery.img and boot.img (kernel) we already have can be used to get a system completely stock.
Why? I just sold an international note2 and am using an AT&T note2. If the community were to try to donate one to me, I'd tell them to take their money and donate it to some children that need food, clothes, etc.
Click to expand...
Click to collapse
Thanks for the response.
Sorry the PS was ment for another thread... Damn all this time waiting on my delivery and too much thread watching / posting.

It *is* a variant of EEPROM. It is also a type of "non-volatile RAM" which is also a form of erasable ROM. It's much further from RAM than it is from EEPROM. RAM needs constant power to refresh it to prevent data loss and reading it is destructive, it degrades the contents and requires recharging time before being accessed again.
I thought I'd try to point it out in question form. The guy asked an innocent question using older but correct terminology -- I completely understand being in that position because I'm an old man, a traveling man, trying to figure this new stuff out too.

ohRonaldo said:
It *is* a variant of EEPROM. It is also a type of "non-volatile RAM" which is also a form of erasable ROM. It's much further from RAM than it is from EEPROM. RAM needs constant power to refresh it to prevent data loss and reading it is destructive, it degrades the contents and requires recharging time before being accessed again.
I thought I'd try to point it out in question form. The guy asked an innocent question using older but correct terminology -- I completely understand being in that position because I'm an old man, a traveling man, trying to figure this new stuff out too.
Click to expand...
Click to collapse
First, please stop referencing your age in every single post. We get it. You're old. You might actually be surprised to learn that quite a few other people here are old as well.
As for EEPROM or not, I actually still use EEPROM with some of my ham radio gear, and NVRAM is nothing like it in general use. In order to rewrite any portion of EEPROM, the entire chip has to be erased. (I made reference to that above.) Same issue with EPROM (but for a slightly different reason.) I agree it might be similar electrically, but from a usage point of view, "ROM" is nothing like "NVRAM."
Oh, and I'm old too. How old? Let's just say that I wrote my first computer programs, I was terrified of dropping the deck and getting the cards out of order.
Take care
Gary

That's why you draw a line across the top of the deck, Gary. HI HI
73

ohRonaldo said:
That's why you draw a line across the top of the deck, Gary. HI HI
Click to expand...
Click to collapse
yep. okay, I'll kill stop harassing everyone.
dit dit

No Baseband - No EFS - with solution/explanation

I figured this out after a struggle, so I figured I would pass along the info in case it helps anyone else.
I'm running CyanogenMod 11 (Android 4.4.4 Kit Kat AOSP based) on my T-Mobile Galaxy S III. I'm on vacation in Mexico, and I had planned to use my Verizon HTC Rezound (aka HTC Vigor) as a phone with a local Mexican SIM card from Telcel. Once I was in Mexico I discovered that the Rezound does not support the GSM/HSPA bands commonly used in North America. It should work fine in Europe, but I could only get Edge service. I decided to try to unlock my T-Mobile Galaxy S III to see if it worked any better.
The free unlock methods I found seemed to require the stock Service Mode applications - so I needed to install a stock rom. I tried to flash a rooted stock 4.3 ROM but the instructions didn't seem to work. The baseband I was running seemed to be too new for the unlock method, which was noted as working with 4.1.1. I tried to downgrade the baseband. It still did not work. I tried flashing a stock rooted 4.1.1 image, and it still did not work. At some point while trying things I realized that no baseband was getting reported in the about screen and no IMEI number was being reported. The phone wasn't even trying to connect to the network. Googling around made me think I hosed my EFS partition. I didn't have a backup.
I hoped that if the EFS partition was corrupted, it might get rebuilt. I used 'dd if=/dev/block/platform/msm_sdcc.1/by-name/efs of=/storage/extSdCard/efs.img' to make a copy of the current state of the efs, then I deleted all the files. I restarted the phone. So data got written to efs, but still I couldn't connect to the network. I didn't have a windows computer with Odin on my trip, by I tried used heimdall with my Mac to write a stock 4.1.1 rom. Still no luck. Not only was the network not working, but the touch screen and buttons were erratic and it would spontaneously reboot. Also, it would generate no sound at all. I figured I practically had a brick. I tossed it in my suitcase and left it until I got home.
When I got home I used ODIN to write the most recent (Android 4.3) root66 stock rooted image. On reboot I got sound back. That was promising. I used dd again to restore the contents of my EFS partition. I was able to connect to the network again. I installed the latest snapshot build of CyanogenMod 11 and everything seems to be working.
I finally put the pieces together. The EFS partition in older roms is formatted with a FAT filesystem, and in new roms it is formatted with an ext4 filesystem. At some point as the phone is upgraded, the EFS partition gets updated to the newer filesystem. Older basebands can not read the data from the ext4 filesystem. If you do not have a backup of the FAT version of your EFS partition, you can't downgrade to the older baseband.
I don't know the precise transition point, but the baseband that comes with 4.3 can read the ext4 partition fine, but the basebands with 4.1 need the FAT partition.
If you open a terminal shell on your phone or with adb shell, then type 'mount', you'll see a list of mounted volumes. The entry for the EFS partition will look like this...
Code:
/dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,noatime,user_xattr,barrier=1,journal_async_commit,data=ordered,noauto_da_alloc,discard 0 0
The first field is the location of the partition. The second field - in this case '/efs' is the mount point. The third field is the filesystem type. Here you see 'ext4'. On your phone, look for the line where the second entry is '/efs'. If the third entry is 'vfat' you can downgrade to older basebands. If it is 'ext4' you can't go to very old basebands unless you have a backup of the old version of your EFS partition and you know how change the filesystem format. Anyone with decent Unix/Linux experience should be able to do that - it isn't hard - but I don't have the old EFS backup to try it out, so I won't try to give any instructions here.
I hope this saves you some trouble.

I think I understand the theory behind what you are trying to explain here, but I dont think this will make a difference.
First though, how did you come to the conclusion that older builds format that partition differently, or more specifically, as vFAT? And that older modems can only read this format?
The reason I dont believe this will make any difference is because much of the data everyone seems to think is located on the EFS partition is not there on the Qualcomm model S3's. For example, the IMEI. On older devices, and maybe some newer ones (dont know for sure), it was moved. If I remember correctly, some of the NV Data is stored on modemst1, some on modemst2, some on param, and some one hidden boot partitions, (and possibly elsewhere). (Dont quote me on those, its been a while since ive looked at all of this so im going by memory and may be slightly off.) But the EFS partition, as best as I can remember, mostly contains data related to DRM, factory mode, carrier info, s/n, and a few other things. I believe there is some important data there related to the modem and network, but not all of it.
The other reason I dont think this would make a difference is I dont see how the system could read and write to other partitions that are vFAT or ext4, but not EFS. It should be able to do so (and is able to do so for the data that is there) regardless of which format it is using. Both formats have been used on this device since day 1.
I am also not certain about the EFS having been re-formatted to a different filesystem at some point. To my knowledge, Odin does not touch that partition, and I've never seen any indication that it has ever formatted anything unexpected in the past. Besides, wouldnt this change its size on disk and thus require the re-formatting of other partitions to compensate? (Im not saying i am right or you are wrong about this, just there are things that aren't making sense to me here.)
I also dont know how comfortable I would be re-formatting ANY partition to a different filesystem. Let alone one that probably cannot be repaired with Odin. For the $5-6 that you might save, it just doesnt seem to be worth the risk to me. (Risk vs reward)
I do apologize if any of this has come off as too argumentative. If your theory does prove to be correct, thats awesome, but I just want to make sure all points are covered before telling anyone something like this is safe to attempt.
Thanks for the post either way though. I do find it interesting!

DocHoliday77 said:
how did you come to the conclusion that older builds format that partition differently, or more specifically, as vFAT? And that older modems can only read this format?
Click to expand...
Click to collapse
I'm trying to retrace my google searches to find the exact reference. It was not a post focused on the SGH-T999, but another similar device. When I find it I'll update to point there.
DocHoliday77 said:
The other reason I dont think this would make a difference is I dont see how the system could read and write to other partitions that are vFAT or ext4, but not EFS. It should be able to do so (and is able to do so for the data that is there) regardless of which format it is using. Both formats have been used on this device since day 1.
Click to expand...
Click to collapse
It is my impression, and please correct me if I am wrong, that the baseband software does not run inside the linux kernel that primarily operates the phone. The low level radio functions have their own system with their own CPU functions and such. There are several reasons this makes sense.
First, interaction with the mobile radio infrastructure is very timing dependent. The software that operates the radios needs to be "real time" - meaning that every task that the system performs must complete in a predictable, determinable amount of time. General purpose, multitasking operating systems like Linux, virtually all Unix systems, and Windows don't do this well. If a general purpose system has specific subsystems that require real time operation, the common solution is put those operations onto a small purpose built hardware with its own processor and software. Even in your standard PC, the ethernet adapters and disk drives have their own processors and firmware.
Second, if the interaction with the radio network was happening in-kernel, then the GPL would require that the software to run this would be open source. The source code for the baseband is not freely available. That suggests that the baseband is separate. It is possible that the code to run the radios could be in a userland process, not in-kernel, and so sidestep the GPL issue. That is unlikely, however, since it would make the timing issues even more difficult.
So if the baseband is software running on a separate CPU, it doesn't matter that the kernel has the modules to read both vfat and ext4. The baseband would need the modules to read that. If certain baseband revisions did not include the modules to read ext4, then the baseband process could not read that data.
DocHoliday77 said:
I am also not certain about the EFS having been re-formatted to a different filesystem at some point. To my knowledge, Odin does not touch that partition, and I've never seen any indication that it has ever formatted anything unexpected in the past. Besides, wouldnt this change its size on disk and thus require the re-formatting of other partitions to compensate? (Im not saying i am right or you are wrong about this, just there are things that aren't making sense to me here.)
Click to expand...
Click to collapse
Other partitions would need to be changed if the size of the EFS partition was increased, but if the size of the EFS partition was not increases, the format could be changed. That process doesn't have to happen in Odin. It could be done at first boot with a particular software revision. The system would need to backup the data on the EFS partition that needs to be saved, reformat the partition using the equivalent of the mkfs command, adjust the partition table and/or the fstab so that the system could mount it properly, remount it, and write back the EFS data - possibly in a new format. All this could be done by any process that had root privs on the system. The baseband could do this itself, even, before the Linux kernel was loaded.
DocHoliday77 said:
I also dont know how comfortable I would be re-formatting ANY partition to a different filesystem. Let alone one that probably cannot be repaired with Odin. For the $5-6 that you might save, it just doesnt seem to be worth the risk to me. (Risk vs reward) ...t I just want to make sure all points are covered before telling anyone something like this is safe to attempt.
Click to expand...
Click to collapse
I definitely don't suggest that anyone tries this unless they are really really really comfortable with this kind of hacking.
BTW - some additional reading in a different T999 thread mentioned that once you go to the NC2 baseband-firmware it is not possible to go back. Makes me think that NC2 is the dividing line if I'm correct about this.

Afaik, you are correct on how the modem operates independently from the rest of the system. That was a good point I didn't take into account, so I will agree that what you stated about the filesystem format being changed is possible. In helping people around here I do periodically run into folks who have never updated beyond 4.1.1 or 4.1.2, so ill try to remember to ask them to check what format the efs partition uses next time. That would probably be the best way to confirm whether or not it was changed somewhere along the way.
As for the sizing of the partition, I do see what you are saying. I was thinking in terms of keeping the usable space the same, which if I am not mistaken would require more space on disk for vFAT.
One other reason I dont think it was changed btw, is I have compared the partition tables of older vs newer builds in the past. It has been a while though, and I wasn't focusing on the efs at the time so I may have overlooked something, but I didnt notice anything different. I was doing this while helping with our debricking process, so it is possible I just didnt see the change, but I kind of feel like I would have had it been there. But, as I just said, it is possible I overlooked it since I wasnt specifically looking for that kind of change.
The inability to downgrade firmware began with our first 4.3 update (MJC). This was done to help prevent tampering and attempts to break into the Knox secure containers.
Something else that just came to mind, is that while you cannot use an older baseband for that reason (Knox), you can use the 4.3 baseband on pre-knox builds (4.1.2 and earlier). So if you were running 4.1.1, for example, you could use the 4.3 baseband. So if your theory is correct wouldnt it mean the 4.3 baseband is capable of reading both formats? And if that is the case, it would mean its something different blocking the SIM unlock in the menu, right?
We do not have 4.4.2 yet, but I have been very active in AT&T's forums lately and can say it is almost the same. You still cannot use older modems as they just wont function, but you can use the 4.4.2 modem on a 4.1.2 or earlier build. The difference, is that while trying the 4.3 baseband on 4.4.2 firmware just doesnt work, if you put a 4.4.2 modem on 4.3 firmware you get an irrecoverable hard brick. Not even jtag will fix it. (right now the only fix is to replace the motherboard). I know that last bit doesn't have much bearing on the topic at hand, but thought I'd throw it in there since on the subject.
So anyway, if the newer basebands will function on older firmware, and the formatting of the efs had been changed, that means the new modems are capable of reading both formats. If all of that is true, the changing from vFAT to ext4 really wouldn't make a difference.
I hope I explained all of that well enough!

Could someone in detail explain the a/b partition system??

I just came over from a Nexus 6p and am slightly confused by this a/b partition on the pixel 2. I understand what a hard drive partition is, but I don't understand the point of it for this phone? And I know this has caused headache for custom rom makers too. Is there a visual map of the harddrive file system to see a good visual representation of how the drive works?

From my understanding, it's split into two partitions so that you can download an update and install it in the background while running the other partition. If there was a problem with the install, you would still have a functional partition which didn't have the update installed on.

If not mistaken the partition system was designed to reduce the downtime required when installing OTA updates. By taking place in the background, it allows the device to quickly reboot after and switch partitions instead of taking relatively ages to wait for the patch to be applied upon boot up.

I guess we will be able to use it for a dual-boot type setup?
Sent from my Pixel 2 XL using Tapatalk

slaydog said:
I guess we will be able to use it for a dual-boot type setup?
Sent from my Pixel 2 XL using Tapatalk
Click to expand...
Click to collapse
Not that I'm aware of. The original Pixel also had a partitioned storage system and I can't recall any dual booting news.

Oh okay thanks! So it's just two 2gb system partitions to rotate between. Cool idea, but honestly I feel like that catering to the impatient haha. I never had problems in the past with updates. On my Nexus 6p you download update in background and then restart to install. Now that install process is quicker I guess, but you still have to restart.
With old system: it would have to restart to unmount the partition then install and boot in
New system: While in partition A, partition B is installing the update and then reboots to switch partitions.
Is that right?

Changing Partition Sizes of internal flash memory

Hi,
after removing all the bloatware and some apps I will never use there is a little over 1G of free space in my system_root partition. Since both system a/b and userdata partitions are on sda I assume it is the same physical device. So in theory it should be possible to shrink the systems partitions and grow the userdata. Has anybody tried to do this? Does anybody know what type of encryption is used on userdata - it doesn't seem to be luks. I have a linux background and am quite surprised how much android differs from what I am used to...
Cheers
Paul

alpinista82 said:
Hi,
after removing all the bloatware and some apps I will never use there is a little over 1G of free space in my system_root partition. Since both system a/b and userdata partitions are on sda I assume it is the same physical device. So in theory it should be possible to shrink the systems partitions and grow the userdata. Has anybody tried to do this? Does anybody know what type of encryption is used on userdata - it doesn't seem to be luks. I have a linux background and am quite surprised how much android differs from what I am used to...
Cheers
Paul
Click to expand...
Click to collapse
In theory it's possible. But in practice it's extremely difficult, especially with all the partitions on todays devices. Changing a partition effects all partitions after it and they all need to be recreated. It's also extremely dangerous if you don't really know what your doing. I successfully did it on an old skyrocket just for fun. But I wouldn't want to try it on the pixel. I'm not even sure what the dual slots would entail.
Sent from my [device_name] using XDA-Developers Legacy app

alpinista82 said:
Hi,
after removing all the bloatware and some apps I will never use there is a little over 1G of free space in my system_root partition. Since both system a/b and userdata partitions are on sda I assume it is the same physical device. So in theory it should be possible to shrink the systems partitions and grow the userdata. Has anybody tried to do this? Does anybody know what type of encryption is used on userdata - it doesn't seem to be luks. I have a linux background and am quite surprised how much android differs from what I am used to...
Cheers
Paul
Click to expand...
Click to collapse
What bloatware did you remove?

airmaxx23 said:
What bloatware did you remove?
Click to expand...
Click to collapse
Everything that is not related to basic phone functionality or camera. Like two dozen apps. arcore, vrcore, all the carrier and e-sim stuff, play music/video, and a lot of other unnecessary stuff.

This is an answer to jd1609, I hit the wrong button:
Yeah, I thought so. Android has evolved quite a bit since cm14 (Android 7.1). I am just starting to understand whats going on with a/b partitions. I still don't quite understand why they had to go with sparse images instead of just raw images. Most probably to confuse me a bit more ....
But thanks a lot for sharing your experiences.
Cheers
Paul