yashsingh1/xdaforums huggingface dataset:
[Google Pixel XL Guides, News, & Discussion] neatojones:
/proc/cmdline is a virtual location, so you can't modify it. As you probably know, it is just the boot arguments. You could find the block device that holds the information (possibly aboot?), then load that and modify it. I believe that there is a tool to modify the hex lines for that for Nexus devices and Oneplus 1. I think you will probably have to dump the block device information and then find the bit and change it, then copy it back to the device.

Edit: Or, possibly copy the image for a non verizon device? Other than using DD, would the persist service prevent an over-ride of that information? ie: PersistentDataBlockService.java

I believe the only location it prevents from being affected is at the FRP location.

From: /services/core/java/com/android/server/PersistentDataBlockService.java

**

* Service for reading and writing blocks to a persistent partition.

* This data will live across factory resets not initiated via the Settings UI.

* When a device is factory reset through Settings this data is wiped.

*

* Allows writing one block at a time. Namely, each time

* {@link android.service.persistentdata.IPersistentDataBlockService}.write(byte[] data)

* is called, it will overwite the data that was previously written on the block.

*

* Clients can query the size of the currently written block via

* {@link android.service.persistentdata.IPersistentDataBlockService}.getTotalDataSize().

*

* Clients can any number of bytes from the currently written block up to its total size by invoking

* {@link android.service.persistentdata.IPersistentDataBlockService}.read(byte[] data)

*/

public class PersistentDataBlockService extends SystemService {

private static final String TAG = PersistentDataBlockService.class.getSimpleName();

private static final String PERSISTENT_DATA_BLOCK_PROP = "ro.frp.pst";
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
I don't believe it's a real bit, the bootloader reads something, probably some protected region of non volatile memory that then appends it to the command line.
[Google Pixel XL Guides, News, & Discussion] neatojones:
I had that thought and have been considering looking into using an nv editor to look at my device when I get it. But, I'm not sure if anyone has ever tried doing that with this device. I haven't seen drivers for the pixel anywhere and I'm not sure if it will have a password even though it is carrier unlocked.

Still, there must be a way to do it without an nv edit since blueyes did it. All things seem to be pointing towards the persistent partition in my opinion.

The thing I keep stumbling on is the confusion over the ability to unlock and the presence of the unlock status. Clearly, they are two separate things but documentation on dealing with the issue seems to confuse the two.

Even if we cannot prevent the device from being relocked with firmware upgrade, our next best bet will be to convince the device it is a GSM pixel and download that software instead of verizon software that may relock the device. On my current S7 edge, all it took was a download and install the G935U variant firmware instead of G935A and the further updates were for U. Essentially, while changing the CID may not benefit us in unlocking the bootloader, that setting or another may help us here in downloading V firmware instead of X. Maybe it just requires a build.prop device identification change.

Edit: I assume the fix isn't in the build.prop because that would have been changed when the V firmware or modified kernel was flashed and others have reported their devices still download X firmware. Still, as mentioned above, I don't think the IMEI matters.
[Google Pixel XL Guides, News, & Discussion] cjkacz:
To be clear in what I'm reading. The process listed on the OP does not allow OEM toggle use and subsequent bootloader unlock for vzw pixel running 7.1.1 ?
[Google Pixel XL Guides, News, & Discussion] cam30era:
Yes, that is correct.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
OK question say someone had a locked bootloader and was on 7.1.1 cause early in the post some said they got it to stick through a reboot with out custom kernel so if thats possible couldn't we root edit get it to stick once boot right into fastboot and run oem unlock?

---------- Post added at 06:13 PM ---------- Previous post was at 06:09 PM ----------

Also I thought flashing back to stock boot images and then flashing a factory firmware reverted this 0.xml edit cause I flashed x boot.img to both slots then flash all.bat for newest firmware 7.1.1 then redid twrp root and then ex kernel when update came out and my toggle is still working and didn't reedit anything

---------- Post added at 06:14 PM ---------- Previous post was at 06:13 PM ----------

Or is it just when a factory reset is preformed from within Android it self after reverting to stock that it gets reset?
[Google Pixel XL Guides, News, & Discussion] DA6030:
It sounds like what you've described involves rooting 7.1.1 with a locked bootloader, which we're currently not able to do. Indeed, that would be half the battle. If you have a way to root 7.1.1 with a locked bootloader, please enlighten us.

Wow, that is very surprising indeed. My expectation is that flashing a boot.img (to which I assume you have not incorporated this edit?) and system image should gray out your toggle again. It would be very interesting to know if you're now getting pushed a different policy from the server, or if you've managed to trick your device. Would you mind posting the output of getprop | grep oem ?
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
The file should be regenerated anytime the phone goes through initial setup, if the toggle was already enabled and you are using a custom kernel or some other tool to mask the bootloader already being unlocked the toggle will remain use able, the real question is what did the file say when you looked at it.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
Ill do the get prop when I get home yea last night basically had the set you all have root twrp kernel then flashed the boot.imh to both a n b slots then ran the flash all for update then twrp install then root again then new kernel again but like I said I was under the impression just flashing the boot.img would reset the prop edit for the toggle then thought about at work checked it and it was still there

---------- Post added at 09:50 PM ---------- Previous post was at 09:44 PM ----------

Unless it doesn't wipe the edit by just flashing a boot.img and the edit stayed cause I removed the w in the flash all bat idk now I'm gonna have do some messing around when I gethome
[Google Pixel XL Guides, News, & Discussion] psychatog64:
That's what's in the file think it's pretty much the same besides new build numbee
[Google Pixel XL Guides, News, & Discussion] psychatog64:
has any one else accomplished this?

is this what we been trying to do? blueyes i got to this also with phone decrypted and running permissive but still dont think its the exact way you did it
[Google Pixel XL Guides, News, & Discussion] psychatog64:
OK I need help idk what the deal is last night I got all flags to 1 also while being permissive and unencrypted so with that said awesome great news then tried messing around some more cause I did all that on p which blue yes did I tried to flash a newer firmware and get everything work well hope 1's changed back to 0's etc so said f it just start over flashed stock p again and then blueyes modded kernel and modded boot to root IMG which I did last night but now I have all ones again and unencrypted but permissive won't work can someone please explain this and help me get this straightened out I'm getting so mad lol those are screen shots showing what I'm talking about only way to so permissive is by setenforce 0 command in terminal and last night it just worked without the command
[Google Pixel XL Guides, News, & Discussion] jjayzx:
Mine wasn't saying permissive at first but now it does and I'm pretty sure I've restarted the phone multiple times and flashed updated kernel and such.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
Weird OK now next question how can I get unencrypted and also get twrp and root on new firmware? Is there a way to do this? Like if I'm on 7.1 or 7.1.1 and format user data can I flash twrp and root some how right after the format?

---------- Post added at 12:13 AM ---------- Previous post was at 12:11 AM ----------

Lol now mime is coming back as permissive again on 7.1.1 even though last night said it wasn't but now I'm not unencrypted anymore cause I gave up and just flashed the new firmware last night but I would like to had both on new firmware

---------- Post added at 12:21 AM ---------- Previous post was at 12:13 AM ----------

If you have what I'm trying to do what exactly are the steps to stay unencrypted and have permissive eventually
[Google Pixel XL Guides, News, & Discussion] psychatog64:
nvm got it all 1's unencrypted permissive and on 7.1.1 root sr5 and newest ex kernel and weta rom man what a pain in the ass that **** was so frustrating
[Google Pixel XL Guides, News, & Discussion] jjayzx:
I would think the unencrypted would stick through updates. I personally didn't do the unencrypted part.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
Yea thin it does from what I've see only thing that makes it go away is a wipe when flashing new firmware if you remove. he it stays

---------- Post added at 09:24 PM ---------- Previous post was at 09:22 PM ----------

I'm gonna order the project Fi sim and re do everything that's the only thing I didn't do that blueyes did so it has to just be coming down to network and the policy

---------- Post added at 09:30 PM ---------- Previous post was at 09:24 PM ----------

I want to figure this out so bad been working on this crap eveyday
[Google Pixel XL Guides, News, & Discussion] cam30era:
Don't waste your time and money. I'm on Fi. I did everything that [MENTION=6207927]blueyes[/MENTION] did, and it didn't stick.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
Wtf god damnit

---------- Post added at 09:32 PM ---------- Previous post was at 09:32 PM ----------

I'm at a lose then I'm out of ideas
[Google Pixel XL Guides, News, & Discussion] blueyes:
cat /sys/firmware/devicetree/base/chosen/radio/htc_smem_cid

It will give you your Cid. It's write protected.
[Google Pixel XL Guides, News, & Discussion] blueyes:
Remove the OEM line in /data/system/users/0.xml and reboot. Your toggle switch will become live. You'll more than likely have to redo this after an update. Haven't looked at it much lately to figure out the permanent solution.
[Google Pixel XL Guides, News, & Discussion] blueyes:
Lol
[Google Pixel XL Guides, News, & Discussion] cam30era:
That was exactly my point ^

He was under the impression that changing his carrier to Fi would make it stick. Not....
[Google Pixel XL Guides, News, & Discussion] blueyes:
Correct. The sim card has ZERO to do with it.
[Google Pixel XL Guides, News, & Discussion] blueyes:
Decryption will NOT stick on an update because the updated kernel will force encrypt you. To avoid being encrypted on an update, just restore the kernel you were on prior to updating or flash any kernel that doesn't force encrypt.
[Google Pixel XL Guides, News, & Discussion] blueyes:
It comes down to the embedded cid and/or vzwmid. Which won't change with a Fi sim or any sim.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
So how the hell did you do this lol

---------- Post added at 12:17 AM ---------- Previous post was at 12:15 AM ----------

I'm the one that posted about the 0.XML lol I'm trying to make it persist like you did
[Google Pixel XL Guides, News, & Discussion] Colomonster:
Okay. Sorry again for my laziness, my wife got my pixel due to breaking her phone, and I love her and have the new one plus on the way... To obtain the switchable oem unlock, I just follow the instructions in OP... do I need the elemental X kernal?
[Google Pixel XL Guides, News, & Discussion] psychatog64:
All you need to do is unlock root kernel then edit the 0.xml will give you access but that's it doesn't really serve a purpose cause it just resets when you flash a firmware wipe etc so basically it can't be used to actually unlock your phone
[Google Pixel XL Guides, News, & Discussion] jjayzx:
What do you mean posted about the 0.XML, cause I found it and posted it? Also we know it wouldn't stick through a wipe. It solved what changed to make it toggle-able but just a stepping stone to get to the root of it.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
You posted about the finding of it then I posted about what what I did to get to get it to stick right after worded my post wrong I know you originally found it

---------- Post added at 08:34 PM ---------- Previous post was at 08:28 PM ----------

Sorry Jay didn't mean to take credit for your thing totally left out a big part of the post
[Google Pixel XL Guides, News, & Discussion] jjayzx:
I was just wondering what you meant, like if you we're referring to a post of maybe a question you asked. I could of also worded my post better.
[Google Pixel XL Guides, News, & Discussion] neatojones:
I successfully permanently changed my CID in the device. The CID and ESN are found in the board_info block of the device sdf1. However, this didn't seem to change anything regarding the oem unlock state in the getprop when it booted up.
[Google Pixel XL Guides, News, & Discussion] DA6030:
Congrats! Can you elaborate? What tool did you use? EFS backup, then edit the backup, then EFS restore?

Did you factory reset your device after changing the CID? Based on [MENTION=4821597]social-design-concepts[/MENTION] and others' research, this policy only gets set (mostly) during the setup wizard. If just a basic factory reset doesn't make it toggleable, I'd be interested to know if the outcome is different with or without network connection during the initial setup (e.g., no SIM inserted, skip WiFi during setup), as some have hypothesized that the policy could be always pushed by the provisioning server based on a unique ID (e.g., IMEI) but that the default policy (if provisioning server unreachable) could be different based on CID.
[Google Pixel XL Guides, News, & Discussion] M9guy:
Sounds like its all tied to the verizon imei then. Verizon is the only USA carrier that links the make and model of phone to its imei so they know the exact make and model of phone your using at any time. The other USA carriers they only care about weather your imei is clean and not on the blacklist. So verizon always knows what make and model of phone you have activated on your verizon account at any time. So this makes a lot of sense. I was wondering about this from day one, and what your saying makes perfect sense as to where the cause of the bootloader getting locked lies.
[Google Pixel XL Guides, News, & Discussion] DA6030:
Before this thread turns into an off-topic discussion of which carriers keep what information and use it for what purposes, I suggest we not jump to any conclusions. Let's focus our energy on running real experiments to collect hard data, so we can know for certain. :)
[Google Pixel XL Guides, News, & Discussion] neatojones:
The way I did it is sort of dangerous, so I wouldn't probably recommend doing it unless you know for sure what you are doing...in which case the information provided would likely be adequate. The information is on the board_info block device. I copied the information into a file then copied it back after editing.
[Google Pixel XL Guides, News, & Discussion] DA6030:
OK, that's what I figured - thanks!

Any thoughts on testing the initial setup scenarios I suggested (with and without connectivity)? I would certainly understand if anyone didn't feel like doing a few factory resets, but it sounds like you're the adventurous type. :)
[Google Pixel XL Guides, News, & Discussion] M9guy:
There is no discussion about it, its pure fact verizon links make and model of phone to the imei. Its not jumping to any conclusion, its a well know fact, just google search and its all there. And this is completely on topic as we are discussing how and why the bootloader gets locked. I do agree that yes it does not to need to go further talking about what carrier shares what but this is all about the verizon pixel / xl so this is on topic talking about verizon linking imei to make and model of phone.
[Google Pixel XL Guides, News, & Discussion] M9guy:
I forgot to mention I think at the beginning of the pixel / xl development prior to depixel8 I believe jcase posted that the cid on these phones did not really do anything. This was why I thought it was the verizon imei right from the start. Having been built by Htc one might think the cid could be the culprit as it has been that way on other Htc devices such the Htc 10, but this is a whole other animal. Hopefully maybe jcase will see this and confirm about posting before about the cid on these phones.
[Google Pixel XL Guides, News, & Discussion] Protibus:
I can say from experience with Verizon that they do link there service directly to the IMEI and the device manufacturer and device serial number. I know this because on deployment of a new fleet of laptops with Gobi adapters that the device manufacturer had never previously had connected to Verizon, we had to supply the IMEI and device serial number to Verizon to allow provisioning on their network. Normally the device manufacturer supplies this info to Verizon ahead of time but because this device combination was it's first instance on Verizon, we had to supply it. Verizon provisioning is directly linked to the IMEI and device manufacturer serial number.
[Google Pixel XL Guides, News, & Discussion] treIII:
This is interesting. I have read on XDA that someone messed up their efs so they pulled it from their friends phone and both phones ended up having the same imei. It was the only fix the guy could come up with.
[Google Pixel XL Guides, News, & Discussion] Colomonster:
Ok so my wife is now using the phone. It is already dePixel `d from day one. 63N I believe... Do you think it is wise to leave it that way? OP3T is my new daily driver...
[Google Pixel XL Guides, News, & Discussion] psychatog64:
You can update and do what ever you want as long as your phone is unlocked like you said it is you can change to any firmware and go back if you wanted
[Google Pixel XL Guides, News, & Discussion] Colomonster:
Got it.... So updating this xml is only a looks thing? Sounds like relocking the BL is not a wise idea, I thought this script edit would allow me to lock and unlock freely one executed.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
Nope only for show basically
[Google Pixel XL Guides, News, & Discussion] Colomonster:
Prefect. Thanks for clarifying
[Google Pixel XL Guides, News, & Discussion] blueyes:
If you run any current custom ROM , PN, OCT-N, your OEM switch will remain functional. I did something different and my switch. Has been live and I never touched the XML file. But recently I decided to decrypt my daughter's sailfish, after decryption and installing a custom ROM, it booted up with the switch live and fully usable. I've put it to the test, flashing an old factory build and locking it. Day or so later I unlocked with only fastboot.

But it is a bit "cosmetic".
[Google Pixel XL Guides, News, & Discussion] xdadevnube:
Not to derail the thread, but are you able to run decrypted on the latest firmware?

I thought the ability to decrypt with Magisk was patched a few updates ago.
[Google Pixel XL Guides, News, & Discussion] blueyes:
I don't know anything about magisk, and I'm on NOF26W decrypted. Which build are you referring to?
[Google Pixel XL Guides, News, & Discussion] xdadevnube:
Well, I'm not sure which build is the latest that can be decrypted with this method, but this is the method I was referring to.

http://www.theandroidsoul.com/disable-verity-force-encryption-pixel-xl-decrypt/

There is a thread on the XDA Pixel XL Q&A forum asking about decrypting the Pixel XL, although it received very little interest. If you have a method to decrypt recent builds, I would love to hear about it! I apologize if you already explained how you decrypted the Pixel in this thread.

https://xdaforums.com/pixel-xl/help/waiting-to-allow-force-encryption-t3563527
[Google Pixel XL Guides, News, & Discussion] blueyes:
I'll update my system and let you know, my kernel is already updated. I doubt I'll have a problem unless I do something crazy like flashing the factory kernel. My fstab isn't going to change and I have verity disabled.
[Google Pixel XL Guides, News, & Discussion] Hittmanthe3rd:
7.1.1

My phone is a Verizon on 7.1.1 Stock, no unlocked bootloader and the option is greyed out. Am I currently ****ed?
[Google Pixel XL Guides, News, & Discussion] mac796:
Yes your not unlocking it. Have to buy one from Google store
[Google Pixel XL Guides, News, & Discussion] DA6030:
Has anyone with a Verizon Pixel loaded Android O DP1? If so, would you mind checking if it performs the Verizon-imposed server-side validation before allowing the OEM unlock toggle? In other words, is your OEM unlock toggle in Development Options grayed out or is it blue? (Either position is fine, no need to toggle it, just need to know the color.)

IMHO, it would be irresponsible of Google to ship beta firmware to devices that potentially don't have a path back to stable builds, so fingers crossed the DPs won't enforce this check on the toggle. If DPs don't enforce, this would create an opportunity for us, once the DPs become available as signed OTA zips. And even if it does enforce, I think users could make a clear case to a Google CSR saying "hey, I opted into ABP and am stuck on a beta build, please whitelist my IMEI to allow bootloader unlocking, so I can get back to stable builds."
[Google Pixel XL Guides, News, & Discussion] StrizzMatik:
I'm on VZW, bootloader unlocked, running Android O and it's greyed out. Am I f-ed if I try to flash back to the latest 7.1.1 build?
[Google Pixel XL Guides, News, & Discussion] DA6030:
You're fine, just don't lock your bootloader!!

That is an interesting policy decision on Google's part, as this means if you were to lock your bootloader you would be stranded on this build (certainly for now, possibly forever), which I would have thought they'd want to prevent.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
it sucks that we never figured out exactly what yopu did blue to trigger your toggle to remain working
[Google Pixel XL Guides, News, & Discussion] Uncle Lizard:
I thought I would chime in about my latest experience. I just received my third Pixel, due to screen flickering issues twice, and failing charging port as well the second time. My original and first replacement Pixel were both unable to have their bootloader unlocked. This third one I decided to try and unlock the bootloader. I did not put on my sim card and I did not hook it up to my wifi. It would not let me toggle the unlock tab and said the usual message of hook to network or call carrier. I figured it was a lost cause, so I hooked it up to my wifi. When I did it let me toggle the switch. I immediately went to the computer and unlocked the bootloader. I don't know what's different with the latest batch of warranty replacement, but my theory is that there are way too many pixels going out for Verizon to keep their database up to date on which serial number belongs to their network and which one doesn't.
[Google Pixel XL Guides, News, & Discussion] RegnierD:
Not necessarily true for the 7.1.2 beta, since when you opt out of the program, they send you an OTA to downgrade which wipes all data on the device as a precaution. Possibly an avenue to consider would be trying to hijack the downgrade process to install 7.1 instead of 7.1.1?

As far as the O preview, I can't speak on that at all.