Just wanted to see if anyone else has successfully rooted their p3 once it's running android 12 and have it successfully pass safetynet.
I'm relatively sure that most of the people reading these forums have quite a few root apps that make their lives and phone experience easier and would like to keep those on android 12.
Thanks
Can confirm root and safety net pass with a12 release
acidspider said:
Can confirm root and safety net pass with a12 release
Click to expand...
Click to collapse
Which version/build of Magisk are you using? Any modules for hiding from detection?
Psychotc said:
Which version/build of Magisk are you using? Any modules for hiding from detection?
Click to expand...
Click to collapse
Latest canary and safety net fix
Did you just fastboot flash after updating to A12? Did you have to flash the vmbeta also?
prabs99 said:
Did you just fastboot flash after updating to A12? Did you have to flash the vmbeta also?
Click to expand...
Click to collapse
yes just fastboot flashed the magisk_patched boot.img and all was good
p.s whats the vmbeta?
acidspider said:
yes just fastboot flashed the magisk_patched boot.img and all was good
p.s whats the vmbeta?
Click to expand...
Click to collapse
Magisk allows for 'systemless' root. We've all read that. What that means though is basically, it doesn't 'touch' root (it does a kind of 'overlay' of it, but doesn't modify actual System).
when we flash disable-verity etc zip, it keeps the data partition from becoming encrypted, so twrp backup can backup that partition.
you can additionally, if desired, disable vbmeta. That allows u to make modifications in System, Op, etc, and the changes will stick even after a reboot. It is said though if yer changes are in System, yer much better off using a magisk module, as they can be easily reverted, if needed.
To disable vbmeta u have to use fastboot. This would be the fastboot command: fastboot --disable-verity --disable-verification flash vbmeta_a blank_vbmeta.img. You don't have to use a blank vbmeta, you can just flash back the original. Also, if u do fastboot --h it will show all commands and these are listed towards the end of the output.
cheers
AsItLies said:
Magisk allows for 'systemless' root. We've all read that. What that means though is basically, it doesn't 'touch' root (it does a kind of 'overlay' of it, but doesn't modify actual System).
when we flash disable-verity etc zip, it keeps the data partition from becoming encrypted, so twrp backup can backup that partition.
you can additionally, if desired, disable vbmeta. That allows u to make modifications in System, Op, etc, and the changes will stick even after a reboot. It is said though if yer changes are in System, yer much better off using a magisk module, as they can be easily reverted, if needed.
To disable vbmeta u have to use fastboot. This would be the fastboot command: fastboot --disable-verity --disable-verification flash vbmeta_a blank_vbmeta.img. You don't have to use a blank vbmeta, you can just flash back the original. Also, if u do fastboot --h it will show all commands and these are listed towards the end of the output.
cheers
Click to expand...
Click to collapse
This should not be necessary on the P3; this only became an issue with Android 12 on the 4a 5g and up. All prior devices are unaffected AFAIK.
V0latyle said:
This should not be necessary on the P3; this only became an issue with Android 12 on the 4a 5g and up. All prior devices are unaffected AFAIK.
Click to expand...
Click to collapse
I was responding to the person who asked what disabling vbmeta was. So I explained what it was.
it "being necessary" on p3 or any device, I have no idea about, nor am I proclaiming it to be one way or another.
it might be better to direct your comment to those that believe it's needed, if you have reason to believe it is not.
cheers
AsItLies said:
I was responding to the person who asked what disabling vbmeta was. So I explained what it was.
it "being necessary" on p3 or any device, I have no idea about, nor am I proclaiming it to be one way or another.
it might be better to direct your comment to those that believe it's needed, if you have reason to believe it is not.
cheers
Click to expand...
Click to collapse
No need to become defensive.
rocketrazr1999 said:
No need to become defensive.
Click to expand...
Click to collapse
No need to respond to people that aren't asking a question.
AsItLies said:
I was responding to the person who asked what disabling vbmeta was. So I explained what it was.
it "being necessary" on p3 or any device, I have no idea about, nor am I proclaiming it to be one way or another.
it might be better to direct your comment to those that believe it's needed, if you have reason to believe it is not.
cheers
Click to expand...
Click to collapse
I'm afraid you're incorrect. Dm-verity and vbmeta verification have nothing to do with encrypting the data partition, nor is vbmeta used for encryption whatsoever. It is, however, used for "tamper-evident storage" of /boot and /system.
Dm-verity is a method by which a hash is generated from a block storage device. Vbmeta verification compares that generated hash to a cryptographically signed hash stored in /vbmeta to determine they match. These are used for Android Boot Verification on the Pixel 4a 5g, 5, 5a, and 6; those of us using those devices have had to reflash vbmeta with --disable flags in order to flash patched boot images.
However, none of this applies to the Pixel 3, 3XL, 3a, 4, 4XL, or 4a.
The only requirement for root on these devices is an unlocked bootloader. Root is accomplished in exactly the same way as it always has - patch the boot image in Magisk.
V0latyle said:
I'm afraid you're incorrect. Dm-verity and vbmeta verification have nothing to do with encrypting the data partition, nor is vbmeta used for encryption whatsoever. It is, however, used for "tamper-evident storage" of /boot and /system.
Dm-verity is a method by which a hash is generated from a block storage device. Vbmeta verification compares that generated hash to a cryptographically signed hash stored in /vbmeta to determine they match. These are used for Android Boot Verification on the Pixel 4a 5g, 5, 5a, and 6; those of us using those devices have had to reflash vbmeta with --disable flags in order to flash patched boot images.
However, none of this applies to the Pixel 3, 3XL, 3a, 4, 4XL, or 4a.
The only requirement for root on these devices is an unlocked bootloader. Root is accomplished in exactly the same way as it always has - patch the boot image in Magisk.
Click to expand...
Click to collapse
My exact words:
"I was responding to the person who asked what disabling vbmeta was. So I explained what it was.
it "being necessary" on p3 or any device, I have no idea about, nor am I proclaiming it to be one way or another."
What, in my words, are any different than what you're saying?
AsItLies said:
My exact words:
"I was responding to the person who asked what disabling vbmeta was. So I explained what it was.
it "being necessary" on p3 or any device, I have no idea about, nor am I proclaiming it to be one way or another."
What, in my words, are any different than what you're saying?
Click to expand...
Click to collapse
This:
AsItLies said:
when we flash disable-verity etc zip, it keeps the data partition from becoming encrypted, so twrp backup can backup that partition.
Click to expand...
Click to collapse
Disabling verity has nothing to do with data encryption, because it is used exclusively to verify /boot with /vbmeta, and /system with /vbmeta_system.
There is no need for users of the Pixel 4a or below to flash or reflash /vbmeta at any point during update or attempting root.
V0latyle said:
This:
Disabling verity has nothing to do with data encryption, because it is used exclusively to verify /boot with /vbmeta, and /system with /vbmeta_system.
There is no need for users of the Pixel 4a or below to flash or reflash /vbmeta at any point during update or attempting root.
Click to expand...
Click to collapse
V0latyle said:
This:
Disabling verity has nothing to do with data encryption, because it is used exclusively to verify /boot with /vbmeta, and /system with /vbmeta_system.
There is no need for users of the Pixel 4a or below to flash or reflash /vbmeta at any point during update or attempting root.
Click to expand...
Click to collapse
I'm talking about disable-verity-force-encrypt. Ever heard of it? it's the magisk zip module that's been used by probably millions of people, and it does exactly what I said, from a practical standpoint.
And again, I didn't say the vbmeta was specific to any device, I said specifically "I don't know" if it's relevant for the p3, etc etc etc.
I just said, from a practical perspective, what it does.
what's your problem?
AsItLies said:
I'm talking about disable-verity-force-encrypt. Ever heard of it? it's the magisk zip module that's been used by probably millions of people, and it does exactly what I said, from a practical standpoint.
And again, I didn't say the vbmeta was specific to any device, I said specifically "I don't know" if it's relevant for the p3, etc etc etc.
I just said, from a practical perspective, what it does.
what's your problem?
Click to expand...
Click to collapse
No problem here, just doing what I can to try to ensure the information shared is clear, relevant, and accurate.
I would suggest that if you're going to continue to participate in public conversations such as this, you might want to consider your defensive reaction to certain circumstances, as has already been pointed out by another member.
V0latyle said:
No problem here, just doing what I can to try to ensure the information shared is clear, relevant, and accurate.
I would suggest that if you're going to continue to participate in public conversations such as this, you might want to consider your defensive reaction to certain circumstances, as has already been pointed out by another member.
Click to expand...
Click to collapse
And I would suggest to you, if someone makes a point, and it's accurate, then there's no reason to tell them they are wrong? is there?
doing such would make anyone defensive, in public or private. Only someone with their head buried where the sun doesn't shine would not understand that.
AsItLies said:
And I would suggest to you, if someone makes a point, and it's accurate, then there's no reason to tell them they are wrong? is there?
doing such would make anyone defensive, in public or private. Only someone with their head buried where the sun doesn't shine would not understand that.
Click to expand...
Click to collapse
It seems we understand each other.
Cheers!
V0latyle said:
It seems we understand each other.
Cheers!
Click to expand...
Click to collapse
Very nice passive-aggressive response. You'd be a lot better off with 'I was wrong, I misunderstood'.
cheers!
AsItLies said:
Very nice passive-aggressive response. You'd be a lot better off with 'I was wrong, I misunderstood'.
cheers!
Click to expand...
Click to collapse
Do you not find it just a little hypocritical to try to correct someone else when you yourself have become extremely defensive?
I will admit that I was partly wrong - Verified Boot is indeed tied to device encryption on some newer devices, including the 4a 5g and up.
The point I was trying to make is that an excess of information can be confusing to people looking for a solution. But, this community thrives on individuals who all try to help those around them, so the information you provided is appreciated.
Related
For the sake of discussion, y'all ever see Tassadar's Multirom making a comeback ever? It was the absolute coolest thing ever!
That said, the new way Android works most likely killed this off entirely. A/B partitions that share userdata, and encryption that locks you out of your phone unless the security patch at least matches. Kinda hate the new way Android works to be honest.
If you remove encryption and AVB/Verity shouldnt it still work?
virtyx said:
If you remove encryption and AVB/Verity shouldnt it still work?
Click to expand...
Click to collapse
See now you got me thinking... Since Multirom mounts the userdata as system and then isolates the userdata for secondaries, it should right? Although people who have removed encryption on these newer devices have said you can't even have a screen lock or fingerprint at all with encryption gone, that's a big trade off. Hmm...
H4X0R46 said:
See now you got me thinking... Since Multirom mounts the userdata as system and then isolates the userdata for secondaries, it should right? Although people who have removed encryption on these newer devices have said you can't even have a screen lock or fingerprint at all with encryption gone, that's a big trade off. Hmm...
Click to expand...
Click to collapse
Hello, so what do you think is a good thing or a bad thing?
Personally, I'm a little afraid about that
H4X0R46 said:
See now you got me thinking... Since Multirom mounts the userdata as system and then isolates the userdata for secondaries, it should right? Although people who have removed encryption on these newer devices have said you can't even have a screen lock or fingerprint at all with encryption gone, that's a big trade off. Hmm...
Click to expand...
Click to collapse
On my pixel 3, removing encryption wouldn't let me use a pin or finger print to unlock, so no gpay.
On my 7 pro I tested out removing encryption and everything still worked perfectly, even removed Verity/ AVB too, fingerprint and pin worked fine.
I think the reason it didn't work on my pixel 3 is the Titan chip - but I'm unsure.
virtyx said:
On my pixel 3, removing encryption wouldn't let me use a pin or finger print to unlock, so no gpay.
On my 7 pro I tested out removing encryption and everything still worked perfectly, even removed Verity/ AVB too, fingerprint and pin worked fine.
I think the reason it didn't work on my pixel 3 is the Titan chip - but I'm unsure.
Click to expand...
Click to collapse
So you were able to keep your screen lock? That's neat! [emoji848] How do you remove encryption on these newer devices? I remember it used to just be a flag in the boot image, but has that changed?
H4X0R46 said:
So you were able to keep your screen lock? That's neat! [emoji848] How do you remove encryption on these newer devices? I remember it used to just be a flag in the boot image, but has that changed?
Click to expand...
Click to collapse
Firstly, you need to have twrp
Format data
Then
Make sure vendor is mounted
You need to pull the vendor/etc/fstab file to your PC
Rename "fileencryption" to "encryptable"
Then push it back to the vendor/etc location
I also make it a habit to do this before flashing magisk when unencrypted
Echo "KEEPVERITY" = false>>/data/.magisk
Echo "KEEPFORCEENCRYPT" =false>>/data/.magisk
Install magisk
And it's done.
To keep unencrypted between updates, you need to do the fstab move again in twrp and flash magisk again before first boot.
I suspect the pixels Titan chip prevents us from using a screen lock when decrypted
Which is silly, but I understand the security behind it.
virtyx said:
Firstly, you need to have twrp
Format data
Then
Make sure vendor is mounted
You need to pull the vendor/etc/fstab file to your PC
Rename "fileencryption" to "encryptable"
Then push it back to the vendor/etc location
I also make it a habit to do this before flashing magisk when unencrypted
Echo "KEEPVERITY" = false>>/data/.magisk
Echo "KEEPFORCEENCRYPT" =false>>/data/.magisk
Install magisk
And it's done.
To keep unencrypted between updates, you need to do the fstab move again in twrp and flash magisk again before first boot.
I suspect the pixels Titan chip prevents us from using a screen lock when decrypted
Which is silly, but I understand the security behind it.
Click to expand...
Click to collapse
Shoot I might just do this! I've always hated having to match the security patch when flashing a rom, or getting locked out of my phone, this might actually be better since Incan try roms and scrap em easily if I don't like em like I used to do in the older days of Android. Thanks so much! Gonna screenshot these steps and give it a go when I have time. Worst case, I restore a backup or use the MSM Tool, so no biggie! [emoji4]
H4X0R46 said:
Shoot I might just do this! I've always hated having to match the security patch when flashing a rom, or getting locked out of my phone, this might actually be better since Incan try roms and scrap em easily if I don't like em like I used to do in the older days of Android. Thanks so much! Gonna screenshot these steps and give it a go when I have time. Worst case, I restore a backup or use the MSM Tool, so no biggie! [emoji4]
Click to expand...
Click to collapse
No worries! Shoot me a PM if you have trouble
There is a noverity zip lying around somewhere but I prefer to do the steps manually gives me piece of mind.
virtyx said:
No worries! Shoot me a PM if you have trouble
There is a noverity zip lying around somewhere but I prefer to do the steps manually gives me piece of mind.
Click to expand...
Click to collapse
https://forum.xda-developers.com/android/software/universal-dm-verity-forceencrypt-t3817389
This is the zip you mentioned right? Since the change is made in the vendor partition, flashing a stock boot image wouldn't set it back to forced right? Or wrong?
H4X0R46 said:
https://forum.xda-developers.com/android/software/universal-dm-verity-forceencrypt-t3817389
This is the zip you mentioned right? Since the change is made in the vendor partition, flashing a stock boot image wouldn't set it back to forced right? Or wrong?
Click to expand...
Click to collapse
Right, but full rom zip will revert it back
Would this possibly mean multirom would be possible?
Has anyone tried the Android 11 dp1 gsi on there Google pixel? I'm going to try later but thought would ask here 1st.
ttocs99 said:
Has anyone tried the Android 11 dp1 gsi on there Google pixel? I'm going to try later but thought would ask here 1st.
Click to expand...
Click to collapse
Yeah, I have. System partition isn't big enough for it, we'd need to resize it with like fdisk or something.
Voltz100999 said:
Yeah, I have. System partition isn't big enough for it, we'd need to resize it with like fdisk or something.
Click to expand...
Click to collapse
Besides partition resizing and flashing GSI (as described on official developer website), is there any other steps required for it to boot successfully?
I've tried flashing the smaller official GSI without GMS, but it is not booting at all. Can't figure out the cause yet.
I even repartioned my phone and can't get any GSI working. Someone did open a ticket with phhusson here however:
github.com/phhusson/treble_experimentations/issues/1161
oasisfeng said:
Besides partition resizing and flashing GSI (as described on official developer website), is there any other steps required for it to boot successfully?
I've tried flashing the smaller official GSI without GMS, but it is not booting at all. Can't figure out the cause yet.
Click to expand...
Click to collapse
Yeah no, it doesn't boot for me either, I think it might be an AVB issue but i'm not certain of that.
Voltz100999 said:
Yeah no, it doesn't boot for me either, I think it might be an AVB issue but i'm not certain of that.
Click to expand...
Click to collapse
AVB should not bother on Pixel 1 if bootloader is unlocked, especially if any custom ROM can be flashed without problem. I think it's probably SELinux-related issue, maybe set to permissive could help. (I've not tried)
oasisfeng said:
AVB should not bother on Pixel 1 if bootloader is unlocked, especially if any custom ROM can be flashed without problem. I think it's probably SELinux-related issue, maybe set to permissive could help. (I've not tried)
Click to expand...
Click to collapse
Interesting, though I don't know how we would set SELinux to permissive without booting first, maybe we'd need a kernel to set it for us? I dunno, this whole thing is really confusing.
Yeah so much for Google phones and universal treble support LOL
Pathetic
Flipz77 said:
Yeah so much for Google phones and universal treble support LOL
Pathetic
Click to expand...
Click to collapse
Can't argue with that, but it wont help us figure out how to get this working.
Clue
Here's a clue:
According to this certain audio libraries are needed to boot the quack GSI so maybe its the same for 11?
github.com/phhusson/treble_experimentations/issues/1196
xtremeed2705 said:
Here's a clue:
According to this certain audio libraries are needed to boot the quack GSI so maybe its the same for 11?
github.com/phhusson/treble_experimentations/issues/1196
Click to expand...
Click to collapse
I gave that a look and even tried it, its missing the libeffectsconfig.so file, yet I couldn't add it because /system is not mountable in twrp. We need another way.
Google has released the final build for android 11, will there be a port for the Pixel?
Deleted.
Mission:
The purpose of this project is to increase efficiency of the Pixel 7 series devices by merging functional patches with minimal bloat.
If you submit bug reports without a log, you may be prosecuted...or executed.
Disclaimer:
If your device fails to comply with your standards of what you consider functioning, I am not liable. This is provided free of charge and does not come with a warranty. Although, if you provide a log, I can provide some sort of assurance that I will look into your issue.
You must have verity and verification disable to flash this for the time being!
To do so you will need to flash vbmeta.img using the command below followed by wiping the device.
fastboot flash vbmeta vbmeta.img --disable-verity --disable-verification
Installation:
-Download ZIP for kernel and extract
-Use the below commands to flash from bootloader/fastboot
-fastboot reboot bootloader
-fastboot flash dtbo dtbo.img
-fastboot flash boot boot.img
-fastboot flash vendor_kernel_boot vendor__kernel_boot.img
-fastboot reboot fastboot
-fastboot flash vendor_dlkm vendor_dlkm.img
Links:
Downloads:
Kernels - Google Drive
drive.google.com
Telegram:
Despair
You can view and join @despairchat right away.
t.me
Source:
https://github.com/DespairFactor/pantah
Credits:
Google
A question, for curiosity sake...
*because it is coming from a very ignorant, noob place
With the change of Magisk now needing to patch the boot_init instead of the usual boot.img, would your kernel need to make the same adjustments? I was just looking at your directions and saw the command line for fastboot flashing boot, and I've been obsessively on the How To guide and there is a certain need of a sensitivity to flashing to the boot instead of the boot_init right now while the initial word gets out of the change...
I also mention this because it seems that this was developed under the Pixel 6 and all your documentation still seem to point to that device still....so....
i have absolutely no experience in kernel building and only dabbled in employing using custom kernels in the past, so I may have no idea what I'm talking about....i was just wondering if it's a possibility or eventuality...
You're source is nill if you didn't notice. And just a bit of an edit needed dude.
SeanHacker said:
You're source is nill if you didn't notice. And just a bit of an edit needed dude.
Click to expand...
Click to collapse
it's uploading still and yeah, I need to update that
simplepinoi177 said:
A question, for curiosity sake...
*because it is coming from a very ignorant, noob place
With the change of Magisk now needing to patch the boot_init instead of the usual boot.img, would your kernel need to make the same adjustments? I was just looking at your directions and saw the command line for fastboot flashing boot, and I've been obsessively on the How To guide and there is a certain need of a sensitivity to flashing to the boot instead of the boot_init right now while the initial word gets out of the change...
I also mention this because it seems that this was developed under the Pixel 6 and all your documentation still seem to point to that device still....so....
i have absolutely no experience in kernel building and only dabbled in employing using custom kernels in the past, so I may have no idea what I'm talking about....i was just wondering if it's a possibility or eventuality...
Click to expand...
Click to collapse
the init_boot is not touched with this so that magisk image that you flashed is untouched! I am hoping to get AnyKernel working soon enough or maybe another dev will hop on it and beat me to it. There is a bit of a problem with how our images are made for this device and how AnyKernel works from the stuff I have tested today.
Nice to see you here.
DespairFactor said:
I am hoping to get AnyKernel working soon enough or maybe another dev will hop on it and beat me to it. There is a bit of a problem with how our images are made for this device and how AnyKernel works from the stuff I have tested today.
Click to expand...
Click to collapse
Would you mind elaborating on that? I'm working on an update to Kernel Flasher, and I'm considering taking a stab at wrapping this kernel in AK3 for testing purposes.
I suppose with init_boot being untouched, one obvious change would be preventing it from patching boot. Would that and adding vendor_kernel_boot into the mix be enough, you think?
Edit: I managed to get it to flash and work with AK3 with verity disabled, but simply patching the hashtree descriptor for vendor_dlkm in vbmeta wasn't enough to get it to work with verity enabled.
your the man @DespairFactor
capntrips said:
Would you mind elaborating on that? I'm working on an update to Kernel Flasher, and I'm considering taking a stab at wrapping this kernel in AK3 for testing purposes.
I suppose with init_boot being untouched, one obvious change would be preventing it from patching boot. Would that and adding vendor_kernel_boot into the mix be enough, you think?
Edit: I managed to get it to flash and work with AK3 with verity disabled, but simply patching the hashtree descriptor for vendor_dlkm in vbmeta wasn't enough to get it to work with verity enabled.
Click to expand...
Click to collapse
So you've packed this kernel on AK3 , flashed through your flasher app and it boots?..( i have also verity disabled )
capntrips said:
Would you mind elaborating on that? I'm working on an update to Kernel Flasher, and I'm considering taking a stab at wrapping this kernel in AK3 for testing purposes.
I suppose with init_boot being untouched, one obvious change would be preventing it from patching boot. Would that and adding vendor_kernel_boot into the mix be enough, you think?
Edit: I managed to get it to flash and work with AK3 with verity disabled, but simply patching the hashtree descriptor for vendor_dlkm in vbmeta wasn't enough to get it to work with verity enabled.
Click to expand...
Click to collapse
init_boot and vendor_boot go untouched, think of vendor_kernel_boot as more or less the replacement for vendor_boot. How did you manage to get this to work? I think AVB is now tied to init_boot and vendor_boot only for now based on what I saw in the fstab.
Just uploaded a 1.02 build to fix a couple issues. This is using the manual flashing method until I can get confirmation on what is needed for AK3 to work. After I have this information I will make it into an AK3 zip.
DespairFactor said:
Just uploaded a 1.02 build to fix a couple issues. This is using the manual flashing method until I can get confirmation on what is needed for AK3 to work. After I have this information I will make it into an AK3 zip.
Click to expand...
Click to collapse
Will we always have to disable verity on this phone for custom kernels to work or will you eventually figure out a way around it?
I really don't feel like wiping my phone.
Gordietm said:
Will we always have to disable verity on this phone for custom kernels to work or will you eventually figure out a way around it?
I really don't feel like wiping my phone.
Click to expand...
Click to collapse
There may be a way around it, we rely on capntrips to help us on this journey. He helped us do it on the Pixel 6 devices. For now, I will keep mine disabled and probably will going forward to avoid any issues.
Like this so far!
Will revisit this once i dont need to Wipe my Device anymore and theres a Flasher for this!
Larakali said:
Like this so far!
Will revisit this once i dont need to Wipe my Device anymore and theres a Flasher for this!
Click to expand...
Click to collapse
You would only need to wipe once when you disable verification, you can update using factory images or flash tool and keep it disabled after the first time and not wipe.
It's great to see a custom kernel for the P7P. Is there a description of the changes in the kernel? I'm coming from the P6P and the Kiri kernel.
After spending 2 days setting up my device, I'm hesitant about wiping. Hopefully there will be a way to flash this kernel with out changing verification.
Does it still hold true that a wipe isn't needed when disabling only verity? I think capntrips mentioned only disabling verity and not verification as well.
Regardless, I disabled both of them on my 1st flash when getting this phone and will keep them that way going forward like I did with Raven, because things ...
swieder711 said:
It's great to see a custom kernel for the P7P. Is there a description of the changes in the kernel? I'm coming from the P6P and the Kiri kernel.
After spending 2 days setting up my device, I'm hesitant about wiping. Hopefully there will be a way to flash this kernel with out changing verification.
Click to expand...
Click to collapse
They are on GitHub, it's pretty close to the stuff I added on my 6 kernels. I have added SSG IOSCHED as well. I cannot list all the changes at the moment. Feel free to check GitHub commit history for the time being.
EDIT: One thing to note, because of the complaints of display being heavy on battery usage, I undervolted the display a little bit, we will have to see how this fares for battery usage. I didn't go crazy with it because we need to maintain stability of the device especially when there can be different binnings.
Lughnasadh said:
Does it still hold true that a wipe isn't needed when disabling only verity? I think capntrips mentioned only disabling verity and not verification as well.
Regardless, I disabled both of them on my 1st flash when getting this phone and will keep them that way going forward like I did with Raven, because things ...
Click to expand...
Click to collapse
I had to disable verification cause I manually flashed. We would need him to confirm or have someone with that setup test.
thanks for the quick release!
I did not disable verity when I did my bootloader unlock and root and dont feel like starting from scatch again so will wait to see if it gets fixed with AK3. if not then will wait until I have time to do a full wipe
Nekromantik said:
thanks for the quick release!
I did not disable verity when I did my bootloader unlock and root and dont feel like starting from scatch again so will wait to see if it gets fixed with AK3. if not then will wait until I have time to do a full wipe
Click to expand...
Click to collapse
I think capntrips will be looking into this over the coming week. You can disable Verity without wiping, but not verification. If he managed to get it to work with just Verity disabled that is good enough for me as it's rather simple to disable even if you forget to after an update.
Hi all, I hope this isn't a thread that has already been posted... I found it interesting that there is no TWRP or any custom recovery for Pixel 7/7 Pro. I understand it's not needed to flash different rom's such as Paranoid Android or Spark OS but I figure it would be helpful no? My prior device was a iPhone 12, haven't run a rooted android since my Galaxy s4 way back in the day. Is this something somebody is actively pursuing or no as it's not needed? Curious on what the situation is with this, loving my p7 pro. Cheers!
TWRP has been nearly an entire Android version behind for awhile now so I haven't been able to use it on my last couple phones. I believe it is still being worked on but since it's been so far behind due to the changes to Android and it's migration to ramdisk installation it's mostly fallen out of use sadly. I do miss it sometimes as well.
jake.99x3 said:
I figure it would be helpful no?
Click to expand...
Click to collapse
No, its useless. Pixel devices have unlocked bootloaders and support fastboot, therefore recovery is not needed.
Well, a lot of old and new Samsung phones and tablets are running TWRP and root. Yes, with Android 13. Is it strictly because there is that A and B split thing going on ? Personally I have not written to my B partition in many months if ever.
Can there be a lesson learned from that ?
96carboard said:
No, its useless. Pixel devices have unlocked bootloaders and support fastboot, therefore recovery is not needed.
Click to expand...
Click to collapse
I don't know about that. It may not be needed but the advantages are profoundly easier than having to learn terminal commands
Also you can't do flashes and restores without a PC whereas when we had active working custom recovery it could be done anywhere at anytime.
JakeDHS07 said:
Also you can't do flashes and restores without a PC whereas when we had active working custom recovery it could be done anywhere at anytime.
Click to expand...
Click to collapse
Exactly! I used to do a complete backup, periodically. One day I screwed something up playing around at work, went to Recover and flashed my backup. Fixed it in a few minutes
Yeah it would be nice to have for sure
Same here, a nice custom recovery would be sweet. If I had any clue how to build one I would be all over it.
JakeDHS07 said:
Also you can't do flashes and restores without a PC whereas when we had active working custom recovery it could be done anywhere at anytime.
Click to expand...
Click to collapse
Is it even possible to do a nandroid backup anymore with the changes to Android filesystems and permissions? I mean you can't even flash a full firmware package in fastboot anymore, part of it has to be done from fastbootd.
old_fart said:
Well, a lot of old and new Samsung phones and tablets are running TWRP and root. Yes, with Android 13. Is it strictly because there is that A and B split thing going on ? Personally I have not written to my B partition in many months if ever.
Can there be a lesson learned from that ?
Click to expand...
Click to collapse
The A/B system is not for power users who manually flash things. It's so that updates for the 99% who use their phones normally can be done in the background. It also adds a failsafe in case one slot gets corrupted since it will automatically boot the other slot after so many failures. Previously such a failure would be an automatic brick.
Also, I think most of us power users are using the A/B system normally at this point too. You have to go out of your way to not flash an update to the other slot, all the defaults do.
HipKat said:
I don't know about that. It may not be needed but the advantages are profoundly easier than having to learn terminal commands
Click to expand...
Click to collapse
That's insane. And dangerous. When it messes up, good luck fixing it.
96carboard said:
That's insane. And dangerous. When it messes up, good luck fixing it.
Click to expand...
Click to collapse
Ummmm, what??
TWRP is a big miss for me. Nandroid Backups and phone based file explorer without having to boot to Android were just two of the numerous features I used regularly. To say it would be useless is ridiculous.
I for one would be very happy to have it make an appearance on the Pixel 7 Pro. I'm not holding my breath though, the Pixel 6 and 6 Pro still don't have it I believe.
I've used TWRP in the past. I've never understood the attraction.
Even with A/B a recovery is useful, but why would I want to play with volume buttons to express my wishes?
Just take a stock recovery, patch adbd to be rooted, patch the kernel to be permissive, done.
As Patrick Henry said, "Give me ADB or give me death!"
Renate said:
I've used TWRP in the past. I've never understood the attraction.
Even with A/B a recovery is useful, but why would I want to play with volume buttons to express my wishes?
Just take a stock recovery, patch adbd to be rooted, patch the kernel to be permissive, done.
As Patrick Henry said, "Give me ADB or give me death!"
Click to expand...
Click to collapse
You sure you've used it? TWRP is fully touch screen.
Beefheart said:
You sure you've used it? TWRP is fully touch screen.
Click to expand...
Click to collapse
You're right. I'm conflating stock recovery with TWRP.
I do remember big tiles and tapping on them.
Still, I prefer to keep my fingers on the (desktop) keyboard.
Renate said:
You're right. I'm conflating stock recovery with TWRP.
I do remember big tiles and tapping on them.
Still, I prefer to keep my fingers on the (desktop) keyboard.
Click to expand...
Click to collapse
I'm as much of a command line fan as the next nerd, but TWRP offers multiple features not available via ADB.
Renate said:
I've used TWRP in the past. I've never understood the attraction.
Even with A/B a recovery is useful, but why would I want to play with volume buttons to express my wishes?
Just take a stock recovery, patch adbd to be rooted, patch the kernel to be permissive, done.
As Patrick Henry said, "Give me ADB or give me death!"
Click to expand...
Click to collapse
Because when you don't have a computer to connect to do a restore, for example, it's imperative to have a Recovery that does backups so you can
HipKat said:
Because when you don't have a computer to connect to do a restore, for example, it's imperative to have a Recovery that does backups so you can
Click to expand...
Click to collapse
Ok. You're doing backups to a USB flash drive? Fair enough.
But, since this thread is questioning whether any custom recovery is in development wouldn't it be helpful if someone knocked off at least a custom recovery to the extent that I mentioned?
Renate said:
Ok. You're doing backups to a USB flash drive? Fair enough.
But, since this thread is questioning whether any custom recovery is in development wouldn't it be helpful if someone knocked off at least a custom recovery to the extent that I mentioned?
Click to expand...
Click to collapse
No, doing backups to internal storage, actually. How am I going to access a USB flash drive with a telephone if I’m sitting at a friend’s house and something gets corrupted, phone won’t boot, and I have to reboot to recovery where I can access an internal back up? Which cannot be done with stock recovery.
I want to clarify, i already saw many threads mentioning how you can protect your data with an unlocked bootloader, so no need to go deep into that.
But it also seems to me, many people just avoid the other issues, like an attacker being able to sideload malware in your device.
How to mitigate those other risks?
cablop said:
I want to clarify, i already saw many threads mentioning how you can protect your data with an unlocked bootloader, so no need to go deep into that.
But it also seems to me, many people just avoid the other issues, like an attacker being able to sideload malware in your device.
How to mitigate those other risks?
Click to expand...
Click to collapse
Sideloading malware requires physically access to your device. You have to reboot into bootloader mode and flashing e.g. a patched system.img and then reboot into system again. To avoid this: Never leave your device unattended.
WoKoschekk said:
Sideloading malware requires physically access to your device. You have to reboot into bootloader mode and flashing e.g. a patched system.img and then reboot into system again. To avoid this: Never leave your device unattended.
Click to expand...
Click to collapse
I am fully aware of that. But there are time you leave it unattended, you can't carry a bag with all your belongings with you to every place you must be in, e.g., bathroom, beach, gym, etc.
So, if you leave it unattended and then you come back and you think it was compromised, what can you do, apart from a full reset? Can't you have a tool that tells you if something changed, somebody took it, it rebooted, etc.?
cablop said:
I am fully aware of that. But there are time you leave it unattended, you can't carry a bag with all your belongings with you to every place you must be in, e.g., bathroom, beach, gym, etc.
Click to expand...
Click to collapse
It seems a bit paranoid... When I'm not at home my phone is in my pocket or locked up (e.g. gym). That's it.
cablop said:
So, if you leave it unattended and then you come back and you think it was compromised, what can you do, apart from a full reset? Can't you have a tool that tells you if something changed, somebody took it, it rebooted, etc.?
Click to expand...
Click to collapse
A full reset would do nothing for you. In bootloader menu you have no access to /data. Even if fully booted up nobody can access /data due to my display pattern. So, a full wipe wouldn't help you since it only wipes /data.
As I already said you could only patch the system.img/vendor.img with malware. But if Android verified boot is enabled, it's impossible to change something on these partitions.
WoKoschekk said:
It seems a bit paranoid... When I'm not at home my phone is in my pocket or locked up (e.g. gym). That's it.
Click to expand...
Click to collapse
Not really paranoid. You only need to see the ads offering ways to people to know what their partners do, don't they? Keyloggers predate Android phones, so how can i think they are not a real risk?
WoKoschekk said:
A full reset would do nothing for you. In bootloader menu you have no access to /data. Even if fully booted up nobody can access /data due to my display pattern. So, a full wipe wouldn't help you since it only wipes /data.
As I already said you could only patch the system.img/vendor.img with malware. But if Android verified boot is enabled, it's impossible to change something on these partitions.
Click to expand...
Click to collapse
BTW. If it was impossible to write on those partitions, then it would be impossible to change the firmware of the phone, but we do when we unlock the bootloader, and then we patch stuff, like a new recovery partition and even root the phone. So it is not something the Android verified boot can do.
It seems to me that while Google and the vendors think it is important to keep the bootloader locked for security reasons, the community keeps looking in other direction to say it is not, and there's no risk, but there is.
cablop said:
BTW. If it was impossible to write on those partitions, then it would be impossible to change the firmware of the phone
Click to expand...
Click to collapse
You mixed up things. A new firmware is not the same as patching /system on a stock ROM. Even a custom recovery requires a patched vbmeta.img in most cases.
Malware is an executable file that can only be stored on a file system. You can't store it on a boot.img or recovery.img since they are only binaries. No, you need e.g. /system or /vendor. Only there you could store a malicious file like a patched APK that gets executed by system during the next boot sequence.
WoKoschekk said:
You mixed up things. A new firmware is not the same as patching /system on a stock ROM. Even a custom recovery requires a patched vbmeta.img in most cases.
Malware is an executable file that can only be stored on a file system. You can't store it on a boot.img or recovery.img since they are only binaries. No, you need e.g. /system or /vendor. Only there you could store a malicious file like a patched APK that gets executed by system during the next boot sequence.
Click to expand...
Click to collapse
ok, that is interesting, but comes with a doubt... then, how does Magisk work? afaik it is a patch outside the firmware or system or data... Can't we install a malware to the phone in a similar way Magisk gets installed?
cablop said:
ok, that is interesting, but comes with a doubt... then, how does Magisk work? afaik it is a patch outside the firmware or system or data... Can't we install a malware to the phone in a similar way Magisk gets installed?
Click to expand...
Click to collapse
Even Magisk needs an installation for the Manager APK when a patched boot.img gets booted. The APK isn't part of the patch and the installation must be granted by the user.
WoKoschekk said:
Even Magisk needs an installation for the Manager APK when a patched boot.img gets booted. The APK isn't part of the patch and the installation must be granted by the user.
Click to expand...
Click to collapse
Hmmm.
Ok, maybe i am confused by thinking the bootloader of Android can work in a similar fashion as the boot of Linux or even Windows.
So, just to be sure, what you are telling me is that there's no way to install with an unlocked bootloader a malware in the system, either as new software or replacing an existing one, but that the risk is they can read my data, something that i can solve with a proper device or userspace encryption, right?
Can't we flash some things from the TWRP or alike like the GMS directly into the system?