How To Guide Platform-Tools v34.0.3 has a different bug - May 1, 2023 TQ2A.230505.002 Global - Unlock bootloader / Root Pixel 7 Pro [Cheetah] / SafetyNet

[roirraW "edor" ehT]

Whoohooo! [MOD][Xposed+Magisk][Pre-Release] AOSP Mods - System modifications for AOSP-based Android 12+ v2.7.1 has:

2.7.1 released in stable channel

- QQS Brightness slider (A13 - QPR2) (Quick Settings)

among other things! Glad to have it back.

 

[Lughnasadh]

Let me explain the error in v34.0.0:

As we all know the partition /super contains a few dynamic partitions. These dynamic partitions only can be handled in userspace by fastbootd mode (which is an executable binary inside the recovery's ramdisk). To flash /super there are two existing methods:
1. In bootloader mode by flashing a super.img to /super.
2. In fastbootd mode by flashing the single dynamic partitions inside of /super.

The firmware of a Pixel has got no super.img inside it, but instead of this another zip archiv (imagesXXX.zip) with all dynamic partitions and a super_empty.img. The super_empty.img is only a partition table of /super with all start/end blocks of the dynamic partitions. These start/end blocks may change with every new firmware build and that's why they are called "dynamic".

For flashing the Pixel's firmware the command fastboot flashall is used by Google. The flashing process starts in bootloader mode to flash bootloader.img + radio.img and then the flashing routine behind fastboot flashall has to decide whether to stay in bootloader mode or to switch into fastbootd mode. For Pixel devices fastboot should switch into fastbootd mode to flash the single dynamic partitions. But it won't and that's the error in v34.0.0.!

Instead of this fastboot remains in bootloader mode and tries flashing /super with a super.img. Let's have a look again at the error message that users get:

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

Due to the fact that there's no super.img (neither as a raw image nor as a sparse image) fastboot outputs that error message above. The reason for getting this error you'll find in the source (line 249):

RetCode FastBootDriver::Download(const std::string& partition, struct sparse_file* s, uint32_t size,
                                 size_t current, size_t total, bool use_crc, std::string* response,
                                 std::vector<std::string>* info) {
    prolog_(StringPrintf("Sending sparse '%s' %zu/%zu (%u KB)", partition.c_str(), current, total,
                         size / 1024));
    auto result = Download(s, use_crc, response, info);
    epilog_(result);
    return result;
}
RetCode FastBootDriver::Download(sparse_file* s, bool use_crc, std::string* response,
                                 std::vector<std::string>* info) {
    error_ = "";
    int64_t size = sparse_file_len(s, true, use_crc);
    if (size <= 0 || size > MAX_DOWNLOAD_SIZE) {
        error_ = "Sparse file is too large or invalid";
        return BAD_ARG;
    }

In short: If sparse_file size is 0 Byte or less (= no sparse_file) than output error text "Sparse file is too large or invalid".

Why does this error occure since v34.0.0?

The developer David Anderson thought it was a good idea not to boot into fastbootd mode as much as really, really needed. He wanted to save time during the flashing process (round about 50 sec.). See fully detailed in the spoiler below.

Spoiler: reasons for changing

fastboot: Avoid reboots to userspace when using flashall/update.

Reboots to fastbootd (userspace fastboot) take a long time, particularly
due to the orange AVB screen and the likelihood of devices having uart
enabled. For "flashall", there is rarely a need to actually go into
userspace, because all of super is getting thrown away. We can just
flash super in the bootloader.

In the past we didn't do this because computing super.img is expensive -
both in terms of time (due to reading dependent images) and in terms of
space (it's easily over 5GB).

But we don't actually need to fully compute super.img. We can build a
sparse_file containing the metadata/headers, with additional references
to each image file containing partition data. Liblp provides the API to
do that, and here, we simply need to translate the layout to libsparse.

On Pixel, this reduces flashall time by around 35-50 seconds, or around
20% of total time, depending on whether uart is in use.

There are some caveats, in which case we'll fall back to normal
fastbootd. This does not work on non-A/B devices, on retrofit dynamic
partition devices (Pixel 3), and in some other edge-casey scenarios. If
it fails, -v will add logging information about why.

Bue: 266982466
Test: fastboot flashall on Pixel 5+
Change-Id: Ie040da597d739faa7f834202184cec8f8e412076

(source: https://android.googlesource.com/platform/system/core/+/667b1efadd8ce8d8cf19d0684a871125cce203d3)

But something went wrong during the execution of his code. As a result of this the flashing process ends with an error and without flashing the contents of /super.
Following the log of the repo /android/platform/system/core/refs/heads/master/./fastboot several changes were made till today. But we'll have to wait for the next update, which will (hopefully) be officially released soon.

I hope it is somewhat understandable.

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.

 

[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

 

[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

 

[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

 

[simplepinoi177]

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

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....

 

[roirraW "edor" ehT]

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....

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.

 

[pndwal]

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....

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

 

[simplepinoi177]

Oh... It looked like it would be active by default (with compatible multi-voltage charger) with option to turn off once (until a reboot?) and that user is simply notified now... Am I wrong? PW

I only remembered that, when I first set up my P7P, I had to choose to enable it....

 

[LLStarks]

Google Issue Tracker

issuetracker.google.com

Pixel 7 losing n25 in recent updates is "intended behavior"

 

[roirraW "edor" ehT]

Google Issue Tracker

issuetracker.google.com

Pixel 7 losing n25 in recent updates is "intended behavior"

Ah! Now I get it. Google is The Joker! Seriously, though, is there a reason why, anywhere?

 

[Schroeder09]

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.

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.

 

[simplepinoi177]

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.

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...

 

[bluegrass55]

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.

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.

 

[Schroeder09]

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...

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.

 

[xunholyx]

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.

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.

 

[simplepinoi177]

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.

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/

 

[Schroeder09]

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/

Thanks for the info and link. The article starts out saying Google is aware and is working on it, but there isn't any specific issue in the issue tracker mentioned that we can all dogpile. There is a screenshot of a user saying they entered an issue in issue tracking. I guess I will go to that. I don't have time now.

Later in the article in one of the march updates to the article the author says someone contacted Google, Google said they were unaware of the issue, and asked the user to send their phone in for a replacement. So are they working on it or not? My guess is they're not just using intelligence guided by experience. Also, the roots of the drain don't seem to be analyzed by power users. The sources of drain they mention seem to be the generic battery usage categories found within the android system settings app as opposed to specific wakelock names that would be obtained from an app like better battery stats. I guess the ImsService thing might be the one specific wakelock mentioned in the article.

I do show high network drain. When I look in BBS wakelocks though I don't see ImsService. I think I have seen it before but not regularly. It's the same old usual offenders: gms.services, android *job.deadline* alarms, etc. See attached screenshots below.

 

[Schroeder09]

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.

What's your usage during the day over that 50% drop as far as SOT? If it's like an hour and the rest is idle drain that 50% drop is NOT normal. The pixel 2xl I came came from gets nearly as good of battery as my p7p, and I replaced the battery in that. Aftermarket batteries are never as good as OEM. This idle drain is not normal. Google play services seems to be the issue- as always- but the s23U guys have the same gms stuff. They are seeing stellar battery life. I fear this IS hardware related and is due to using inferior, cheap, junk cell antennas or modems of some sort that have to make the phone work hard to search for good signal. I hope I am wrong and that the issue is software, but I don't remember battery life ever getting better through the life of the phone. It only ever gets worse with software and is never corrected. I should just go back to the November update and stop messing with updating this phone. Use it on November, 2022 update for 5 years until I get a new phone and forget about it!

 

[xtcislove]

Quick questions:
I like to keep the abillity to use custom kernels if i update and i know i need to edit the flash all bat like this:

fastboot update image-cheetah-buildnumber.zip --disable-verity --disable-verification

1. Does pixel flasher keep verity etc diabled or do i need to tick disable verity and disable verification with advanced mode enabled?
2. If i use flash all bat or pixel flasher with verity/verfication option enabled to UPDATE the device will it wipe data?