yashsingh1/xdaforums huggingface dataset:
[Google Pixel 7 Pro] powershift:
I copied the init_boot.img from the build onto the phone, used Magisk to create a patch using that image and then did a test boot with the new patched image. What happens is the phone reboots and goes right into fastboot mode. It doesn't boot Android off the image. The init_boot.img is only 8 MB and it probably doesn't have a RAMDISK in it. Any ideas on what I'm doing wrong?

anon@dev:~/android/platform-tools$ ls magisk_patched-25200_9IRcy.img
-rw-r--r-- 1 anon anon 8.0M Mar 18 19:03 magisk_patched-25200_9IRcy.img
anon@dev:~/android/platform-tools$

anon@dev:~/android/platform-tools$ sudo ./fastboot boot magisk_patched-25200_9IRcy.img
Sending 'boot.img' (8192 KB) OKAY [ 0.058s]
Booting OKAY [ 0.006s]
Finished. Total time: 0.073s
anon@dev:

Here is t he latest build (March 2023)

anon@dev:~/android/platform-tools$ ls ../builds/Pixel7Pro/cheetah-tq2a.230305.008.c1/
total 7.5G
drwxr-x--- 2 anon anon 4.0K Mar 18 18:51 .
drwxr-xr-x 3 anon anon 4.0K Mar 18 18:48 ..
-rw-r--r-- 1 anon anon 207 Dec 31 2008 android-info.txt
-rw-r--r-- 1 anon anon 64M Dec 31 2008 boot.img
-rw-r----- 1 anon anon 13M Mar 3 16:11 bootloader-cheetah-cloudripper-1.0-9618366.img
-rw-r--r-- 1 anon anon 16M Dec 31 2008 dtbo.img
-rw-r----- 1 anon anon 1006 Mar 3 16:11 flash-all.bat
-rwxr-x--x 1 anon anon 1.1K Mar 3 16:11 flash-all.sh
-rwxr-x--x 1 anon anon 1.1K Mar 3 16:11 flash-base.sh
-rw-r----- 1 anon anon 2.5G Mar 3 16:11 image-cheetah-tq2a.230305.008.c1.zip
-rw-r--r-- 1 anon anon 8.0M Dec 31 2008 init_boot.img
-rw-r--r-- 1 anon anon 2.8G Dec 31 2008 product.img
-rw-r--r-- 1 anon anon 1.0M Dec 31 2008 pvmfw.img
-rw-r----- 1 anon anon 109M Mar 3 16:11 radio-cheetah-g5300g-221229-230210-b-9589366.img
-rw-r--r-- 1 anon anon 5.1K Dec 31 2008 super_empty.img
-rw-r--r-- 1 anon anon 340K Dec 31 2008 system_dlkm.img
-rw-r--r-- 1 anon anon 362M Dec 31 2008 system_ext.img
-rw-r--r-- 1 anon anon 828M Dec 31 2008 system.img
-rw-r--r-- 1 anon anon 26M Dec 31 2008 system_other.img
-rw-r--r-- 1 anon anon 12K Dec 31 2008 vbmeta.img
-rw-r--r-- 1 anon anon 4.0K Dec 31 2008 vbmeta_system.img
-rw-r--r-- 1 anon anon 4.0K Dec 31 2008 vbmeta_vendor.img
-rw-r--r-- 1 anon anon 64M Dec 31 2008 vendor_boot.img
-rw-r--r-- 1 anon anon 42M Dec 31 2008 vendor_dlkm.img
-rw-r--r-- 1 anon anon 645M Dec 31 2008 vendor.img
-rw-r--r-- 1 anon anon 64M Dec 31 2008 vendor_kernel_boot.img
anon@dev:~/android/platform-tools$
[Google Pixel 7 Pro] Lughnasadh:
You can't fastboot boot it because your using an init_boot.img, not a boot.img. Just flash it...

fastboot flash init_boot <nameofpatchedimage>
[Google Pixel 7 Pro] powershift:
I patched the boot.img from the latest build and did a test boot with the patched image. It booted just fine so in my case the init_boot.img is not what I needed. It was really good practice to test boot `sudo ./fastboot boot magisk_patched-25200_IZC7w.img` without flashing it first, otherwise I would have had a bigger problem.
[Google Pixel 7 Pro] WoKoschekk:
You need the boot.img for that. The init_boot.img has got no kernel and without a kernel you cannot boot.
[Google Pixel 7 Pro] Lughnasadh:
Why are you patching the boot.img? You need to patch the init_boot.img.
[Google Pixel 7 Pro] powershift:
That was a mistake on my part. I flashed the patched init_boot and I don't have root. It looks like the command failed. Any ideas on what I'm doing wrong?

anon@dev:~/android/platform-tools$ sudo ./fastboot flash init_boot magisk_patched-25200_IZC7w.img
Warning: skip copying init_boot_b image avb footer (init_boot_b partition size: 8388608, init_boot_b image size: 67108864).
Sending 'init_boot_b' (65536 KB) OKAY [ 0.491s]
Writing 'init_boot_b' FAILED (remote: 'failed to flash partition (init_boot_b)')
fastboot: error: Command failed
anon@dev:~/android/platform-tools$
[Google Pixel 7 Pro] WoKoschekk:
You flashed the boot.img (not the init_boot.img!!) with a size of 67.108.864 Byte (= exactly 64MB) to the partition init_boot. That's wrong.
[Google Pixel 7 Pro] Lughnasadh:
At first glance it looks like you're using a patched boot.img, not a patched init_boot.img. Says size is 65536 KB. That would be the size of a boot.img. The size of an init_boot.img shoud be around 8192 KB.

EDIT: Ninja'd 🙃
[Google Pixel 7 Pro] powershift:
That was it and the phone is rooted. I'll plan to do this sober next time lol. Thank you!

anon@dev:~/android/platform-tools$ sudo ./fastboot flash init_boot magisk_patched-25200_dfucY.img
[sudo] password for anon:
Sending 'init_boot_b' (8192 KB) OKAY [ 0.053s]
Writing 'init_boot_b' OKAY [ 0.016s]
Finished. Total time: 0.069s
anon@dev:~/android/platform-tools$
[Google Pixel 7 Pro] humb13:
I agree. It seems this time around the developers who write platform tools managed to do the impossible: fry a phone's motherboard with 34.01. The phone is not in the fastboot mode with the screen turned off. When you plug it into the PC, the PC won't see it at all. There is also no reaction when you plug it into a charger.

I had to bite the bullet and replace the phone. I got refurbished one at Amazon for $638 plus tax plus $40 delivery fee because I couldn't wait a week. When I got it and did that OTA upgrade that takes forever, I noticed it only went to the February release. I decided to cross my fingers and attempt a flash-all.bat update to March, only this time using 33.0.1 platform tools. Everything went perfect, no issues of any kind. This is hard proof that 34.0.1 is the culprit.

I know all this is risky. What bothers me about these developers is that despite the fact that this update is known to fry motherboards, it is still online for download. In fact, it took quite a bit of Googling to find 33.0.1. I refuse to believe the developers don't monitor forums such as this one where I'm not the only one complaining. There is a MAJOR problem with 34.0.1 and they keep silent and refuse to do anything about it. If there were any justice in this world I'd send them the bill for my new phone. Oh well.... just write the old phone off and continue, nothing more to do.
[Google Pixel 7 Pro] simplepinoi177:
according to the posts below, Google has acknowledged it, but it is weird that it has not been taken down or made any warning on it; but then again, it's not just Pixels and/or Pixel 6 or 7 that uses platform-tools (the problem lies with not getting into fastbootD mode, which is a mode I believe only in Pixel 6 & 7; as I don't recall it in Pixel 5 or Pixel 2), so maybe Google doesn't want to remove it for it being used in all those other cases (as r34 & RC2 do supposedly address other specific fixes on bugs)....
[Google Pixel 7 Pro] Dave_247:
In theory I believe it should affect any phone that relies on using fastbootd as part of it's update procedure, however as it's still a relatively new feature in the world of Android, where aside from Google themselves everyone else is notoriously slow to adopt things unless forced, I don't know of any other phones that this could affect as Samsung use their own flashing method and all of the others don't seem to be affected else this would have blown up in a much bigger thing, which I assumed to be because they don't use or rely upon the newer userspace fastboot, or maybe there is something else that I have no idea about.
[Google Pixel 7 Pro] WoKoschekk:
It's the fastboot flashall command that is used to flash a single ZIP with one single command. Every Pixel firmware has a bootloader.img, radio.img and the firmware ZIP inside the downloaded ZIP. This firmware ZIP needs the flashall command. It's a own flash routine to flash the images on their partitions.
[Google Pixel 7 Pro] ShadowJP88:
Why does the march update has been removed from their repository?

Images d'usine pour les appareils Nexus et Pixel | Google Play services | Google for Developers

developers.google.com
[Google Pixel 7 Pro] WoKoschekk:
Switch language to english or the march update isn't displayed. Seems to be a bug or sth else.
[Google Pixel 7 Pro] pndwal:
The point re. 'Working Fastboot is possible with blackscreen' (again, it may well not apply to P7 series devices, but I only posted about the existence of this phenomenon; users will need to test) was NOT that "the phone is in the fastboot mode with the screen turned off"... Rather, some devices (incl. Qualcomm based) can enter fastboot without the user being aware because (due to some corruption) the screen may simply remain black...

The working method to fix such bricked devices (only know of success with older devices however) was to activate the flash before connecting device, then hold down vol- while connecting usb to PC to cause device to enter 'download' mode and drivers to discover and connect device (even while bootlooping or with 'dead' screen) and flashing to commence... This way the user becomes aware that fastboot flashing is working since there is no indication from device, and no indication on PC unless a trick like pressing vol- while plugging USB succeeds...

Clearly P7 series users would need to experiment with similar tricks to activate a fastboot mode 'blind', not simply hope for fastboot mode to be available when connecting device...

Some EDL mode may also be an avenue for P7 series users to explore... 🙃 PW
[Google Pixel 7 Pro] WoKoschekk:
no matter if screen is off... or only shows nothing but is turned on... or is simply dead, it will be recognized when it gets connected to a PC. Otherwise it's not in fastboot mode then. A dead screen and no signal via USB means the device is dead.

A Pixel will boot into fastboot mode that way. Connecting a power source to a turned off device boots the charger mode (not the system by default). However, doing this while keep pressing the Vol- button boots it into fastboot mode.

Till now there's no documentation about sth similar like download/EDL mode on a Tensor SoC. I guess Google didn't implement such option to make the devices more secure since EDL is known to bypass the security features of Qualcomm CPUs.
[Google Pixel 7 Pro] Lughnasadh:
https://twitter.com/i/web/status/1637902911899410434
[Google Pixel 7 Pro] humb13:
The problem with this logic is the fact that an older version (33.01) works perfectly whereas the newer one doesn't. Shouldn't it be the other way around? There is no question this is a major bug, and from what I'm seeing I'm not the only one who's been burned by it.

No it hasn't. I just checked and it's still on there. In fact, I upgraded my new Pixel 7 Pro (the one replacing the one the developers fried) with the March update using 33.0.1 and it worked perfectly.

Whatever you do, stick with 33.0.1 for now. Don't even touch 34.0.1.
[Google Pixel 7 Pro] WoKoschekk:
And that's the reason why (changelog 34.0.0 (February 2023)):

You can read it also in the log of the repo for ADB/Fastboot:

Log - refs/heads/main - platform/system/core - Git at Google

First entry is 667b1ef, 7 weeks ago.
[Google Pixel 7 Pro] WhoIsJohnGalt1979:
Had a quick question for all the music aficionados who use a 3.5 mm to USB-C adaptor(small DAC) or use a USB-C DAC to listen to music. I hadn't used one for a while and have been using my Pixel Buds Pro since I got the Pixel 7 pro last year.

I recollect however, that on my Pixel 6 pro, for USB DAC to continue playing music when the screen goes off while using apps like UAPP and Neutron player, I had to set the Default USB configuration to "No Data Transfer". Lo behold, I had to do the same on my Pixel 7 pro too today for the same issue of music stopping on screen off while using a USB DAC. Both apps are set to Unrestricted battery usage.

Is the above the same for everyone else too? Am surprised this functionality hasn't been fixed for Android to handle in natively all this while.

Any comments are welcome in case I am doing something wrong or the issue manifests only in specific DACs.
[Google Pixel 7 Pro] Displax:
So, here is the commit with fix. Waiting to merge.

https://android-review.googlesource.com/c/platform/system/core/+/2495616
[Google Pixel 7 Pro] WoKoschekk:
This is a commit for "libsparse: Fix allocation failures on 32-bit systems."
[Google Pixel 7 Pro] simplepinoi177:
The thread below in the Pixel 7 (non-pro) forum express your issue as well -- while also coming up with the same workaround you have -- so you might be able to find/connect some other people there as well...!

https://xdaforums.com/t/screen-off-...pdated-with-workaround.4565463/#post-88313383
[Google Pixel 7 Pro] simplepinoi177:
Thanks for that oh, great Displax!

The issue is a 32-bit one...??? (please pardon my uber amateur-ish take...)

Here's hoping for r34.0.2 ....!!
[Google Pixel 7 Pro] roirraW "edor" ehT:
I'd wish they would just skip to 35. :) 34.x has been bad enough, especially for the at least one user whose phone is unrecoverable.

Public congratulations @simplepinoi177! 🧨🎇🎆
[Google Pixel 7 Pro] Lughnasadh:
I think I've seen 3 or so people who say their phone was "bricked" because of this. Not good...
[Google Pixel 7 Pro] simplepinoi177:
I think I've seen the same people (me and @Lughnasadh definitely roam the same threads)...

It's quite incredible that it has led to

hard-bricking

-- and even one instance where the repair shop (i believe it was even the authorized uBreakiFix) where the system board wasn't pulling any power! -- than just simply bootlooping or "system/partition corrupted" errors! It usually goes when those hard-bricked members re-attempt multiple times, in the same open instance, then manually restart or use the volume-power button selection.

At this point, let's just call r34 a bust and move to r35 like roirraW "edor" ehT suggests...!!!(y)
[Google Pixel 7 Pro] WoKoschekk:
The issue that is linked is related to Windows 32bit, but it's another problem. No related to the issue discussed here regarding the bricked devices.
[Google Pixel 7 Pro] simplepinoi177:
Thanks...I had assumed (but wrongly)...

God....I really would've thought that would've been top priority considering all of us that manually flash the update and

numerous

bricks and bootloops have occurred that THAT would be the issue they would work on foremost and/or report on....😒

I guess we're all just on "pins and needles" waiting for a positive report from them on this; especially those who have been helping countless members after they brick or bootloop because they've always been taught "download the most latest version of platform-tools..."!
[Google Pixel 7 Pro] WoKoschekk:
They already do. There're a few devs working on different parts of this repo. Here's the log:

Log - refs/heads/main - platform/system/core - Git at Google

All links related to "flashall", "super", "flashing_plan" and some others.
[Google Pixel 7 Pro] bluegrass55:
When editing the flash-all line to remove -w what should it look like this after editing?

fastboot -w --skip-reboot update image-cheetah-2023032000.zip

fastboot --skip-reboot update image-cheetah-2023032000.zip ( is this correct)?
[Google Pixel 7 Pro] simplepinoi177:
yes, removal of any (although normally there is just 1 instance) instance of "-w" works best; just keep in mind spacing before and/or after...so the line looks good

Also I'm curious as to why you added "--skip-reboot"?

I've only ever experienced adding that command for when flashing to both slots (although I'm sure there are other reasons to, I just can't recall what they are or seeing them); as a reboot would clumsily boot into the OS after the flash-all and you'd have to go through some trouble to get back into the bootloader and switch slots to flash again...
[Google Pixel 7 Pro] bluegrass55:
Thanks for the reply.

I didn't add the "--skip-boot" text. This is how it comes in the Flash-all text.

This is from the Graphene OS. After updating the ROM I'll be flashing the Magisk patched boot to re gain root.
[Google Pixel 7 Pro] roirraW "edor" ehT:
Do you mean this is a Flash-All.bat for the Graphene OS?

My stock Android Flash-All.Bat looks like this after removing the -w:

fastboot update image-cheetah-tq2a.230305.008.c1.zip

Hence, the confusion, if we're talking about something other than Google's official firmware.
[Google Pixel 7 Pro] Displax:
Just click on bugs links in the head of commit...
[Google Pixel 7 Pro] roirraW "edor" ehT:
To spell it out, @Displax is talking about:

which resolves to:
[Google Pixel 7 Pro] WoKoschekk:
Yes, but I don't see any connection between this commit and the bug regarding the flashall command.
[Google Pixel 7 Pro] roirraW "edor" ehT:
I certainly won't find out first hand once the fix is released. I will wait for the positive reports! 🤣 I don't have time for phone mishaps these days.
[Google Pixel 7 Pro] Lughnasadh:
This is the error people are getting:

Sending sparse 'super' 1/1 (4194303 KB) FAILED (Sparse file is too large or invalid)
fastboot: error: Command failed

Seems like the mapping fails because the file is too big, so they will map files in chunks of 256MB instead.
[Google Pixel 7 Pro] Schroeder09:
People root graphene? I thought that was counterproductive for graphene theory? how's it work as compared to the stock Google ROM for p7p? I've considered it. Using xprivacy Lua has been the closest I've gotten to using privacy-centric apps and ROMs.
[Google Pixel 7 Pro] simplepinoi177:
without having to go through most of the post and explanation and just having a cursory glance...I

really

would rather have waited the extra 35 50 seconds in the flash-all process than have this whole mess happening 😝

*again, I haven't read it all in full, so I'm sure there is more reasons for it, I just saw that snippet and wanted to comment on it already...
[Google Pixel 7 Pro] bluegrass55:
Yes rooting and having an unlocked bootloader is strongly discouraged by the Graphene developers, but I have a call recording app that only works with root.

I migrated to Graphene when Marcel stopped supporting Xprivacy Lua. It is the next best thing and I recommend it. Everything works and they provide regular security updates.

I have not used stock Google OS in a long time so cannot compare it with Graphene.
[Google Pixel 7 Pro] xunholyx:
I know this wasn't meant for me, but I add that to the flash-all myself too. I then add an extra line

fastboot flash init_boot **magisk patched init_boot.img**

Followed with

fastboot reboot
[Google Pixel 7 Pro] roirraW "edor" ehT:
Whoohooo! [MOD][Xposed+Magisk][Pre-Release] AOSP Mods - System modifications for AOSP-based Android 12+ v2.7.1 has:

among other things! Glad to have it back.
[Google Pixel 7 Pro] Lughnasadh:
Quite understandable. I actually pondered whether this was the reason for the issue a couple of weeks ago here, but didn't look into it in depth as you did.

I was also going by Google saying they discovered the cause, were working on a fix and then following the trail where they referenced this bug in the commit Displax mentioned, which also seemed logical to me.
[Google Pixel 7 Pro] lunatix01:
im trying to unlock the bootloader and it says Unrecognized command flashing unlock.

OEM unlocked and debugging is on, and the device is detected in fastboot, i even downloaded the 33 platform tools still the same.

edit: nvm my bad i was in fastbootd
[Google Pixel 7 Pro] roirraW "edor" ehT:
Google Camera 8.8 tweaks the zoom bar on Pixel 7/Pro

Google Camera 8.8 also tweaks the zoom UI on the Pixel 7. The latest version of Camera also reveals work on the Pixel 8 Pro...

9to5google.com
[Google Pixel 7 Pro] roirraW "edor" ehT:
Google Pixel adding 'Adaptive Charging' status notification with one-time off button

Pixel Adaptive Charging has been a contentious feature, and Google is now updating it with a notification to note when it's active...

9to5google.com
[Google Pixel 7 Pro] simplepinoi177:
saw this last night...kinda freaked me out...

I mean, i guess it's good to know and all, but since it's not on/enabled by default, I wonder how much it really needs to be notified -- as the user would surely know it's on because they turned it on.

Then again, it might be good to suggest if the user doesn't have it enabled and might be interested in it....
[Google Pixel 7 Pro] roirraW "edor" ehT:
The ability it brings to turn it off for just one time sounds good, and users can probably long press it just like most any other notification and customize it, make it "silent" while still keeping it handy enough if you do wish to access it.

Of course, I know or imagine that most users aren't even aware of the ability to customize notifications, but they'll either find out or they won't. 😂
[Google Pixel 7 Pro] pndwal:
Oh... It looked like it would be active by default (with compatible multi-voltage charger) but with new option to turn off once (until a reboot?) and that user is simply notified now... Am I wrong? 🤔

Other devices normally have adaptive charging on by default when available... PW
[Google Pixel 7 Pro] simplepinoi177:
I only remembered that, when I first set up my P7P, I had to choose to enable it....
[Google Pixel 7 Pro] LLStarks:
Google Issue Tracker

issuetracker.google.com

Pixel 7 losing n25 in recent updates is "intended behavior"
[Google Pixel 7 Pro] roirraW "edor" ehT:
Ah! Now I get it. Google is The Joker! ;) Seriously, though, is there a reason why, anywhere?
[Google Pixel 7 Pro] Schroeder09:
Can you speak to the battery life of graphene OS on a p7p? How much SOT are you getting and over what what period of time off the charger is that said SOT happening over? What's idle drain percentage per hour?

Can anyone else speak to battery drain and battery life since the march update? I've lost an hour of SOT when off the charger 18hrs. Combined active/idle drain is now regularly 2.8-3.5%/hr when before it was 2.1% - 2.8%. I'm not aware of any changes I made other than the update.
[Google Pixel 7 Pro] simplepinoi177:
Can you say it's been subpar since December (update)?

I just saw an article in my Google feed speaking a bit on the matter, but it marks the December update as the cause...but it speaks on the "ImsService" and its wakelocks when frequently consuming location data as the cause. Supposedly there's a bug report to Google, in which it is responded to and is said to be escalated to the dev team...

I'll put the link in this thread if it ends up being relevant...
[Google Pixel 7 Pro] bluegrass55:
I don't really pay attention to SOT, idle drain.

The display is on QHD and 120hz. I have a smartwatch & health app that is always running in the background.

90% at 9am. By 3pm 30%.

Battery drain is similar to my old Oneplus 5T, with the same apps but on Pie.
[Google Pixel 7 Pro] Schroeder09:
As in the December update is when it started? ABSOLUTELY. I've posted many times here and across different platforms that the November battery life was STELLAR. It may have even been here on XDA where I said I have thought about factory resetting tho phone and going back to November with the only reason being for battery life. There was a notable drop after November.
[Google Pixel 7 Pro] xunholyx:
I agree. I have no issues with battery life on mine either. I leave from home at 80-85% for work and come home at about 35-40% 8hrs later.
[Google Pixel 7 Pro] simplepinoi177:
If that's the case, the article I'll link below might illuminate some...

It states that the December firmware update specifically (and all subsequent, since all updates after the previous carry-over said bugs until they're specifically dealt with) may be to blame -- the hindrance of excessive idle draining...

https://piunikaweb.com/2023/03/28/google-pixel-7-pixel-6-excessive-idle-battery-drain-issue/