yashsingh1/xdaforums huggingface dataset:
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
i'll post my instructions after i get my daughter to sleep, I can confirm it can be done without a custom kernel factory resetting now
[Google Pixel XL Guides, News, & Discussion] psychatog64:
Would this all be the same just with Marlin instead of sailfish since that's what I'm on

---------- Post added at 03:47 AM ---------- Previous post was at 03:44 AM ----------

Also is there a x boot.img that is already modded for the Cid that I can just flash cause I'm not exactly to sure on how to go about editing this to change the cid

---------- Post added at 03:54 AM ---------- Previous post was at 03:47 AM ----------

On another note you all have no idea how happy I was early while I was driving and figured this out with that simple switch in the 0.xml file restarted my phone and went to dev options and almost crashed my car lmao when I saw I got it to stick and the toggle wasn't grayed out immediately posted that **** lmao so all could follow lol

---------- Post added at 04:21 AM ---------- Previous post was at 03:54 AM ----------

Blue eyes I'm gonna send ya a pm need help if you can spare some time
[Google Pixel XL Guides, News, & Discussion] death2all110:
This is great, but I vote we keep this thread/discussion alive until [MENTION=4821597]social-design-concepts[/MENTION] or I, or one of us can figure out what is setting /data/system/user/0.xml
[Google Pixel XL Guides, News, & Discussion] Atlantian:
Vzw pixel xl.. depixelate... Root... Installed stock EX kernel with EX application. .. reboot. Mod 0.xml update build prop. Done!
[Google Pixel XL Guides, News, & Discussion] blueyes:
Glad to see it getting put to use. It was OK knocking out the Verizon oem block, but being able to to share it with others is much more gratifying.

I guess we can tell vzw "Nice Try", but between jcase's mod and this one their persistence for Google to lock up their versions help for a whopping 6-8 weeks?
[Google Pixel XL Guides, News, & Discussion] Atlantian:
Will this persist through reset? That's the better question or persist through a flash.
[Google Pixel XL Guides, News, & Discussion] nbhadusia:
Apologies for the silly question but it's a genuine one. What are the benefits of being able to toggle the switch? Thanks in advance
[Google Pixel XL Guides, News, & Discussion] xdadevnube:
Pretty sure it's downloading the policy settings by calling home over the internet. My post several pages back links to another thread where an xda user explains.
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
[MENTION=6207927]blueyes[/MENTION]

Here is the method I used no custom kernel / no twrp needed, just root privileges required included is some quick scripts to do the process for the user just needed to make sure that adb shell has authorization for a root access before running.

Note: Once you enable the toggle it will be grayed back out after a reboot but will be grayed out in the enabled position, since Android 7.1 possible 7.0 this is the default behavior when the device is unlocked and OEM unlocking has been enabled through: Settings / Developer options / OEM unlocking.

GooglePixelPhone-OEMUnlockToggle.7z : View attachment GooglePixelPhone-OEMUnlockToggle.7z

Gonna do a better write up later.
[Google Pixel XL Guides, News, & Discussion] blueyes:
If you just reset and your not referring to completely wiping and installing a new firmware, can't say
[Google Pixel XL Guides, News, & Discussion] psychatog64:
Mine doesn't gray back out after reboot
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
The only thing I haven't tested is resetting and relocking.

---------- Post added at 04:31 PM ---------- Previous post was at 04:30 PM ----------

Are you using a custom kernel or something to make Android Pay Work?
[Google Pixel XL Guides, News, & Discussion] alluringreality:
My main interest is due to how the December update could stop dePixel8 from working. If that happens and the current version of dePixel8 is the only tool to allow a bootloader unlock, then it would not be possible to lock and unlock a bootloader on the newer firmware. Assuming an alternate method could allow someone "to lock your device and still unlock it later" then that might give more flexibility than just having dePixel8 as the only tool to unlock a Verizon bootloader. While I don't necessarily have a reason to relock my bootloader at this time, the flexibility could potentially be useful if there were future software changes similar to the safetynet check for an unlocked bootloader.

There are still some possible complications here. social-design-concepts mentions needing root access for that method, and there are forum suggestions that having a locked bootloader with root or a custom kernel can be recipes for a soft brick. I've read suggestions that it may be possible to get past certain soft bricks, but the typical advice to anyone like myself that is only marginally informed would still be the following.

http://xdaforums.com/pixel-xl/how-to/psa-read-relocking-bootloader-t3494615
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
So what I posted earlier currently uses superuser root access, but in theory until Google closes this hole any future exploit that can be leveraged to make the necessary changes to that file and properly set the permissions could be used to remove the OEM unlocking restriction.
[Google Pixel XL Guides, News, & Discussion] blueyes:
Missed this one. Marlin has had no other Android version besides 7.1 correct? Regarding your comment on the toggles behavior and greying our unlocked. Mine, once it went white , it's remained white. It's remained unlocked, and can switch it back and forth at will. Food for thought..

We're you already on a custom kernel or at least a stock with bootargs modified?
[Google Pixel XL Guides, News, & Discussion] blueyes:
Never went back grey
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
No custom kernel no boot.img mods outside of root, the custom kernels are masking the bootloader being already unlocked they have to in order to make Android Pay work, that's why you can toggle when ever you like.

If you want to test use the resetprop tool to set : resetprop ro.boot.flash.locked 0

Note:

prop changes like ro.secure 0, ro.adb.secure 0, or ro.debuggable 1 will also trigger that your devices is already unlocked status
[Google Pixel XL Guides, News, & Discussion] blueyes:
ro.secure=0 ,etc should only trigger a userdebug build. Not an unlocked trigger. It would also allow for adbd , adb insecure..
[Google Pixel XL Guides, News, & Discussion] death2all110:
Right. I was one of them to mention this. I'm referring to figuring out which specific package.
[Google Pixel XL Guides, News, & Discussion] kirschdog1:
How do you change it in root file explorer. I looked at your screenshots and there the same for me. What do change in root explorer/data/system/useres/0.xml to fix this issue.

Thanks Jordan
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
I assume it triggers it because they are not props that can be set with out being in an unlocked state. Probably part of safety net too. It's just my observations from before depixel8 was released and I was trying to find an unlock method.

It is the OobConfig.apk that sets the policy restrictions still need to track down what actually triggers it

Found this in the same folder of code that sets sim lock an Oem lock restrictions:

public String brand;

public String device;

public String imei;

public String manufacturer;

public String meid;

public String model;

public String product;

public String serialNumber;

Have to dig more later. . .

looks like it depends if it's a white-list or black-list

if it's a black-list we should be able to spoof an invalid (note: i said invalid talking about changing these to are no no on xda) imei and meid

if it's a white-list we are at the mercy of Google / VzW / EE

DELETED
[Google Pixel XL Guides, News, & Discussion] DA6030:
OOBConfig default policy

Based on what we learned here, has anyone validated if the default policy is to disable the OEM unlock (for a GS Pixel, that has never connected to the internet)?

http://xdaforums.com/showpost.php?p=69356304&postcount=32

It wouldn't surprise me if Google erred on the side of being fail-safe (i.e., if they ever decommissioned the activation server, as they've already done for Android <2.0 devices, people should be able to unlock). If so, that sounds like an opportunity for us!

Nonetheless, if every unlock requires a server validation, that doesn't sound promising for us. If I were Google, I would do the validation on IMEI or serial number or something else more immutable than CID. That would also allow for more flexibility (e.g., one-off exceptions where needed).
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
DELETED
[Google Pixel XL Guides, News, & Discussion] Scott:
Good Job!
[Google Pixel XL Guides, News, & Discussion] nbhadusia:
Thanks, that makes sense. From what I understand, the general consensus is that it's extremely unlikely that any future updates would relock the bootloader. I think that would be a first, though I'm not 100% on that. I'm tempted to enable the toggle.. The only worry is, if I accidentally toggle it to disallow unlocking... Could I end up with a soft brick(I'm rooted). The other thing is, if future otas do lock the Bootloader in future (which I don't think they will... I'm sure they'd find it even easier to undo the toggle modification. Again, I maybe wrong, but I remember reading there maybe some kind of whitelist of allowed unlockable bootloader's ... Anyone else outside that list (Verizon, EE)could be relocked with an update if they really wanted to be harsh. Again, I think this is unlikely.
[Google Pixel XL Guides, News, & Discussion] Scott:
No OTA has ever locked a bootloader. Do you know how many "I cant boot my Phone" Verizon would get?

:p
[Google Pixel XL Guides, News, & Discussion] nbhadusia:
Exactly my point.
[Google Pixel XL Guides, News, & Discussion] cam30era:
I'm a bit confused here. If one relocks the bootloader, the device performs a factory reset. So if I've well understood, relocking the bootloader will put the "Allow bootloader unlock" toggle back to the stock VZW grayed out setting? Or did I misunderstand?
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
According to the aosp source the persistent data block is only suppose to be cleared when Factory Reset is performed though Android Settings with in the OS, but it didn't clear the toggle, the toggle seem to be persistent through resets so far but I haven't checked it with the devices locked yet.
[Google Pixel XL Guides, News, & Discussion] cam30era:
This is very good news. So you believe that the unlock ability will persist, even if we flash a stock factory image, then relock the bootloader? And second question: in this stock, locked state do you think the unlock toggle would persist after ADB sideloading the December security update? (I understand that this is speculative at this point).
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
I'm going to do testing tonight.
[Google Pixel XL Guides, News, & Discussion] cam30era:
:fingers-crossed:

---------- Post added at 04:41 PM ---------- Previous post was at 04:36 PM ----------

I've always understood that a factory reset was a factory reset. Whether it was initiated through Android Settings, recovery, or fastboot (format data). So now it appears that wasn't/isn't true anymore? At least for the Pixel XL....
[Google Pixel XL Guides, News, & Discussion] psychatog64:
I pretty sure flashing a stock image will undo the build prop change don't know for sure but if I had to guess I would say yes cause factory image will remove kernel etc but as long as you keep root you can re edit and flash kernel allowing you to toggle oem unlock and unlock bootloader normally now with just fastboot in theory
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
the toggle doesn't oem unlock your device it only enables you to oem unlock your device through fastboot.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
[MENTION=6207927]blueyes[/MENTION] can you post a modded boot.img for x firmware that I can flash to reflect the super cid change tried adding lines to build prop but won't stick

---------- Post added at 11:07 PM ---------- Previous post was at 11:06 PM ----------

I know that I just said this last line with fastboot in theory
[Google Pixel XL Guides, News, & Discussion] death2all110:
Ugh. Still don't feel any closer to finding what OOBConfig is doing.

package com.google.internal.android.work.provisioning.v1.nano;

import com.google.protobuf.nano.CodedInputByteBufferNano;
import com.google.protobuf.nano.CodedOutputByteBufferNano;
import com.google.protobuf.nano.ExtendableMessageNano;
import java.io.IOException;

public final class DeviceRestrictionsConfig
extends ExtendableMessageNano<DeviceRestrictionsConfig>
{
public boolean disallowOemUnlock;

public DeviceRestrictionsConfig()
{
clear();
}

public DeviceRestrictionsConfig clear()
{
this.disallowOemUnlock = false;
this.unknownFieldData = null;
this.cachedSize = -1;
return this;
}

protected int computeSerializedSize()
{
int i = super.computeSerializedSize();
if (!this.disallowOemUnlock) {}
for (;;)
{
return i;
i += CodedOutputByteBufferNano.computeBoolSize(1, this.disallowOemUnlock);
}
}

public DeviceRestrictionsConfig mergeFrom(CodedInputByteBufferNano paramCodedInputByteBufferNano)
throws IOException
{
for (;;)
{
int i = paramCodedInputByteBufferNano.readTag();
switch (i)
{
default:
if (!super.storeUnknownField(paramCodedInputByteBufferNano, i)) {
return this;
}
break;
case 0:
return this;
case 8:
this.disallowOemUnlock = paramCodedInputByteBufferNano.readBool();
}
}
}

public void writeTo(CodedOutputByteBufferNano paramCodedOutputByteBufferNano)
throws IOException
{
if (!this.disallowOemUnlock) {}
for (;;)
{
super.writeTo(paramCodedOutputByteBufferNano);
return;
paramCodedOutputByteBufferNano.writeBool(1, this.disallowOemUnlock);
}
}
}

It looks super obfuscated.

---------- Post added at 04:56 PM ---------- Previous post was at 04:54 PM ----------

By the way, I modified dex2jar to work with Android N

Here's oobConfig.dex converted to a JAR file and to SMALI The JAR can be read with JD-GUI

oobConfig.zip
[Google Pixel XL Guides, News, & Discussion] DA6030:
That changed with all devices that support Factory Reset Protection - the device needs a way to know who was the last logged in user, to be able to lock out anyone else that may have performed a factory reset - that is the basic purpose of FRP. Thus, some data is persistent across factory resets.

The functional difference between a factory reset done within the OS vs one done outside the OS (e.g., recovery or fastboot) is that within the OS is considered what you might call a "fully authorized reset" since it was initiated with the device unlocked. Thus FRP is reset in the process.

Formatting the user partition outside the OS could be an "unauthorized reset" on a stolen device where the device-holder cannot log in, thus the FRP is not reset. Functionally, this means you have to log in with the same Gmail account after doing this type of reset (unless you've toggled "OEM unlocking" in Android Settings, which disables this feature).

I think this started with devices that came preloaded with Lollipop (e.g., Nexus 6), but not certain.

Keep in mind that FRP is disabled once you toggle "OEM unlocking" in Android settings (another potential reason for wanting to flip the toggle!), so you likely never encountered this.
[Google Pixel XL Guides, News, & Discussion] blueyes:
Lol. Is that really where you want to start? To me thats more work and like trying to stop a train after its moving. Lol. (Just kidding).

Seriously though, I'm looking at it from the devices source code. Knock it out before any apps have to be involved.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
Do we still loose root when flashing a kernel now in twrp or was that just with the old way before twrp
[Google Pixel XL Guides, News, & Discussion] blueyes:
No. Flashing this zip , you won't lose root or recovery.

It's his normal aroma installer. I just edited the build script.
[Google Pixel XL Guides, News, & Discussion] death2all110:
I still want to know what in the stock rom triggers it and what it looks for. Reason being because AOSP/CM roms won't help when you're stuck on stock with a locked BL when there is no temp root.
[Google Pixel XL Guides, News, & Discussion] jaxenroth:
Edited the file but keep getting "process android.process.acore has stopped" doing a factory reset didnt fix. Flashed weta didnt fix. When I rebooted it still show the restriction, so I went and redid the edit and flashed blueyes mod'd kernel. Trying to boot up now.
[Google Pixel XL Guides, News, & Discussion] psychatog64:
you have to be editing something wrong there hasn't been a single issue like what your stating
[Google Pixel XL Guides, News, & Discussion] jaxenroth:
Did steps just as blueyes stated. I edited just now and rebooted to twrp flashed the mod'd kernel, been in a boot loop for 15 mins now. Rewiped and reflashed weta again along with mod'd kernel and SU. Booting now, still getting FC message, time to flash factory image I guess. WTF
[Google Pixel XL Guides, News, & Discussion] blueyes:
Shouldn't of needed to flash SuperSU. Once rooted with twrp installed, only flash (if using my modified bootzip), the kernel. It doesn't overwrite twrp or su. Flashing root will cause at least one bootloop by itself. Thats probably your issue there.
[Google Pixel XL Guides, News, & Discussion] blueyes:
Attempting to enable the oem toggle while locked without the oem workaround would be a long shot. I tried before dePixel8 came out. Used dirtycow root adb shell "run has" cmd, and gaining temp but it didn't cut it.

I won't say impossible. Too much tail chasing following the apps from one to another. That's my reasoning for catching it at the source.

I'll pull some of the strings in the makefiles I'm looking at. Might help shed some light, not to mention seeing those triggers your looking for.
[Google Pixel XL Guides, News, & Discussion] jaxenroth:
[MENTION=6207927]blueyes[/MENTION], I know about the SU bootloop, but this is not the case. If I make the xml edit and reboot, it just keeps looping. Ive wiped and rebooted but keep getting the FC message. Ive wiped both slots A/B and flashed weta w/ no kernel or SU and still get FC message. Once booted up ive FC every app on app setting and cleared data, but still get FC message. Lost at this point. Gonna flash factory img when I get into work. Thx for your input though.
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
I got boot loops when editing the 0.xml because while i remembered to set ownership and permissions i forgot to reset the selinux context, if you still having problems you can try this no manual editing of the 0.xml file required:

http://xdaforums.com/showpost.php?p=69724024&postcount=332
[Google Pixel XL Guides, News, & Discussion] cam30era:
Run adb shell from OS or recovery? Is SuperSU needed?
[Google Pixel XL Guides, News, & Discussion] social-design-concepts:
The scripts are written to be run through the Android OS with su, they could be easily adapted to modify the 0.xml through a flashable recovery .zip, or though an adb shell through recovery, but I'm waiting till recovery becomes stable before flashing twrp.
[Google Pixel XL Guides, News, & Discussion] cam30era:
Thank you.

Have you had a chance to test the persistence of the unlock toggle through a factory image flash and subsequent bootloader relock?
[Google Pixel XL Guides, News, & Discussion] death2all110:
It *may* survive a factory image flash, but only if data isn't wiped.
[Google Pixel XL Guides, News, & Discussion] raycaster3:
I used SELinuxModeChanger set to permissive, and am running unmodified ElementalX 1.00. I made the change and it stuck after reboot with no issues.

Not sure why I felt like my device wasn't all the way mine until this was possible, but much appreciated.

There's something else I noticed... I have installed a ROM on both a and b boot and even though the original partition shows the toggle set for OEM unlocking. The ROM on the other partition - I'm using now - showed it as not toggled. I made the edit and then toggled it. Obviously it had no effect on the bootloader itself, but just thought I'd mention it
[Google Pixel XL Guides, News, & Discussion] thewebsiteisdown:
Two different slots, two Seperate installs.
[Google Pixel XL Guides, News, & Discussion] lucky_strike33:
Does your device memory go way down when you have roms on both slots?
[Google Pixel XL Guides, News, & Discussion] airmaxx23:
This worked great, thank you. Just for reference the toggle was not greyed out afterwards.
[Google Pixel XL Guides, News, & Discussion] dualityim:
You add "androidboot.selinux=permissive" to the kernel command line, right?

For the force encrypt modification, I used to know how to do it on my Nexus 6 running Lollipop, where you just modify the fstab in the initramfs to change from forceencrypt to encryptable. Is that still how this is done?
[Google Pixel XL Guides, News, & Discussion] treIII:
I'll try. If I save something up since my bootloader is unlocked will I be able to flash back to stock with factory image
[Google Pixel XL Guides, News, & Discussion] treIII:
Yes blue eyes. I just want to edit default.prop
[Google Pixel XL Guides, News, & Discussion] treIII:
I think the mobile app is only a flashable zip
[Google Pixel XL Guides, News, & Discussion] Javiisawesome:
So how did you achieve this, can u give me a step by step guide, I really wanna do this
[Google Pixel XL Guides, News, & Discussion] jjayzx:
I got everything to 1 except the sys.oem_unlock_support still shows 0 even with persist.
[Google Pixel XL Guides, News, & Discussion] death2all110:
After doing some digging. It looks like maybe the device downloads a device policy from Verizon, and maybe that disables the option?

com.android.sdm.plugins.connmo seems to make server calls to https://4g.vzwdm.com/

11-12 07:41:37.815 5059 5059 D DMIntentReceiver: server URL: https://4g.vzwdm.com proxy address: null

I'd like to find out what information it is sending and receiving.
[Google Pixel XL Guides, News, & Discussion] death2all110:
Maybe it still sends the IMEI/CID to VZW?

But i don't know. Jcase says the CID doesn't do anything on these phones. But I feel like the CID does something, we just don't know it yet. I mean why else would the 2 models have different CIDs (most likely).

I posted on reddit asking for someone with a Google Pixel to check their CID for me.
[Google Pixel XL Guides, News, & Discussion] death2all110:
Looks like it uses a web service rather than communicating with the towers themselves. I could be way off on this entire thing though.
[Google Pixel XL Guides, News, & Discussion] blueyes:
Format userdata. Extract this zip. https://www.dropbox.com/s/pbcar1qy8qi1c5g/kernel_boot2root.zip?dl=0

Inside will be a modded ElementalX kernel, flash it then flash the included boot-to-root. Also modified for no force encryption. Remember to use correct commands. Flash boot ex kernel...IMG then fastboot boot boot-to-root. If done correctly you'll boot up decrypted and permissive
[Google Pixel XL Guides, News, & Discussion] thewebsiteisdown:
I have a pixel from google store and one from verizon.

The only difference I see is with the imei's. How do I check the CID's though? Is it the ICCID?
[Google Pixel XL Guides, News, & Discussion] jjayzx:
That's what I was doing, modifying elementalx kernel. I'll backup my stuff and try your files later. I think that's the only thing I haven't done is disable encryption. When you go in terminal and use "getenforce" does it say permissive?
[Google Pixel XL Guides, News, & Discussion] death2all110:
Theres a couple methods.

Easiest is CID Getter from Play store

Other methods:

adb shell getprop ro.boot.cid

fastboot oem readcid