General May 16, 2023 QPR3 Beta 3.2 T3B3.230413.009 - Pixel 7 Pro [Cheetah] - [thread also for future Android QPR Betas]

[Lughnasadh]

Just to confirm I'm safe to click leave beta today before the release of the final next week will still be able to just install the final when it drops without getting wiped as it says in the below picture below?

As long as you ignore/don’t apply the downgrade OTA update when you receive it. Just make sure you ignore installing it and wait for the stable QPR2 build to reach your phone.

 

[Beddadizi619]

Will I be able to sideload QPR 3 beta 1 if I'm currently on 14 DP 2 as long as it has a later build date? I have a Tmo PPro7 with a locked bootloader.

 

[roirraW "edor" ehT]

Will I be able to sideload QPR 3 beta 1 if I'm currently on 14 DP 2 as long as it has a later build date? I have a Tmo PPro7 with a locked bootloader.

Not without wiping. That would be a technical downgrade. Downgrades of Android OS, especially major version without wiping, can cause unpredictable results. The later build date doesn't matter, since you'd be going from a higher Android version.

However, if you are prepared to wipe and try it anyway, do feel free to let us know your experience. But not recommended.

 

[Clark Joseph Kent]

Thread Cleaned.

And let's be nice and play nice shall we, I will ask you to review the Forum Rules again:

2.3 Flaming / Lack of respect: XDA is about sharing and this does not involve virtual yelling (flaming) or rudeness. Flaming or posting with a lack of respect is unacceptable. Treat new members in the manner in which you would like to have been treated when you were a new member. When dealing with any member, provide them with guidance, advice and instructions when you can, showing them respect and courtesy. Never post in a demanding, argumentative, disrespectful or self-righteous manner.

 

[Markeee]

Can I sideload from beta to stable March if my bootloader is still locked without a wipe ?

 

[dd805bb]

I hit the F it button and dirty flashed March official instead of waiting for the official OTA.. Nothing happened. Booted fine. I am rooted so you can't do that on a locked BL. It does rollback from Beta to official so I would guess their official OTA will just have the newer BL.
AGAIN FOR THOSE THAT DONT KNOW, YOU CAN NOT DO THAT UNLESS ROOTED! Just saying. All my modules loading fine, and I am on Magisk 25209 official. FYI.

 

[roirraW "edor" ehT]

Can I sideload from beta to stable March if my bootloader is still locked without a wipe ?

Full OTA Images for Nexus and Pixel Devices | Google Play services | Google Developers

developers.google.com

This page contains full OTA update packages that allow you to restore your Nexus or Pixel device's original factory firmware. You will find these files useful if you have experienced a failure to take an OTA. This has the same effect as flashing the corresponding factory image, but without the need to wipe the device or unlock the bootloader.

I hit the F it button and dirty flashed March official instead of waiting for the official OTA.. Nothing happened. Booted fine. I am rooted so you can't do that on a locked BL. It does rollback from Beta to official so I would guess their official OTA will just have the newer BL.
AGAIN FOR THOSE THAT DONT KNOW, YOU CAN NOT DO THAT UNLESS ROOTED! Just saying. All my modules loading fine, and I am on Magisk 25209 official. FYI.

To clarify, all you need is to have the bootloader unlocked - you don't have to actually be rooted. Otherwise, you can also use the OTA method above if your bootloader is locked.

 

[dd805bb]

Full OTA Images for Nexus and Pixel Devices | Google Play services | Google Developers

developers.google.com

To clarify, all you need is to have the bootloader unlocked - you don't have to actually be rooted. Otherwise, you can also use the OTA method above if your bootloader is locked.

I only said that so people know I am rooted and on an unlocked BL. And correct you don't need to be rooted, you need an unlocked BL.

 

[albsat]

I have a question. If I put the patched magisk init boot image (same name as original) in the firmware file, would it update correctly it directly via fastboot? Just trying to skip the second step to install the patched init boot image via fastboot.

 

[roirraW "edor" ehT]

I have a question. If I put the patched magisk init boot image (same name as original) in the firmware file, would it update correctly it directly via fastboot? Just trying to skip the second step to install the patched init boot image via fastboot.

I don't think it will flash the files if they're modified. You can do it this way, instead, though:

You're right, I forgot all about that, sorry I'm guilty, I don't manually modify the script
@whitewallman
You can't add --slot-all to the update image line

Your can refer to this as template, this one works to flash both slot.
In fact it even allows you to flash the patched file before rebooting to system

@ECHO OFF

PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot.exe --slot all  flash bootloader bootloader-xxx.img
fastboot.exe reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot.exe --slot all  flash radio radio-xxx.img
fastboot.exe reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot.exe  --skip-reboot update image-xxx.zip
echo Switching active slot to the other ...
fastboot.exe --set-active=other
echo rebooting to bootloader ...
fastboot.exe reboot bootloader
ping -n 5 127.0.0.1 >nul
fastboot.exe  --skip-reboot update image-xxx.zip
echo rebooting to bootloader ...
fastboot.exe reboot bootloader
ping -n 5 127.0.0.1 >nul
echo flashing Magisk patched image ...
fastboot.exe --slot all  flash init_boot magisk_patched_xxx.img
echo rebooting to system ...
fastboot.exe reboot

Note that you can remove the stuff having to do with flashing both slots, as it's useless. I re-tested just yesterday with the same firmware flashed to both slots, and once you successfully boot one of the slots, it's impossible to boot the other slot because as @Lughnasadh has pointed out, Google switched to storing some information for your running Android slot on the other slot to save storage space or something like that.

So you can adjust it to:

@ECHO OFF

PATH=%PATH%;"%SYSTEMROOT%\System32"
fastboot.exe flash bootloader bootloader-xxx.img
echo rebooting to bootloader #1 of 3...
fastboot.exe reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot.exe flash radio radio-xxx.img
echo rebooting to bootloader #2 of 3...
fastboot.exe reboot-bootloader
ping -n 5 127.0.0.1 >nul
fastboot.exe  --skip-reboot update image-xxx.zip
echo rebooting to bootloader #3 of 3...
fastboot.exe reboot bootloader
ping -n 5 127.0.0.1 >nul
echo flashing Magisk patched image ...
fastboot.exe flash init_boot magisk_patched_xxx.img
echo rebooting to system ...
fastboot.exe reboot

 

[Lughnasadh]

I have a question. If I put the patched magisk init boot image (same name as original) in the firmware file, would it update correctly it directly via fastboot? Just trying to skip the second step to install the patched init boot image via fastboot.

I don't think it will flash the files if they're modified. You can do it this way, instead, though:

Doing it this way should be ok, but as The Rode Warrior pointed out, you can also do it the way he suggested. Or, as another option if you are trying to skip manual steps, just use Pixel Flasher.

By the way, one user has reported that that replacing the stock init_boot.img with the patched one in the firmware file does work.

 

[badabing2003]

The PATH=%PATH%;"%SYSTEMROOT%\System32" is optional, if that's where you keep your extracted Platform-Tools.

The PATH=%PATH%;"%SYSTEMROOT%\System32" comes from the flash_all.bat script by Google, it is on the first line after the comments.
This is probably due to fastboot.exe having dependencies on windows binaries which are in system32,.
Typically the PATH environment would already have system32 in the path, the script is making sure it has by adding it just in case the user env settings has been modified intentionally or unintentionally.
It's just a safety measure added by Google.

By the way, one user has reported that that replacing the stock init_boot.img with the patched one in the firmware file does work.

Yes, this is how early versions of PF used to do, by repacking the patched boot into the firmware and flashing.
It no longer does that because that is slow and unnecessary.
What it currently does is:

• it builds a modified flash_all script (called flash-phone.bat)
• Uses full path to Android platform tools, this assures to pick up the correct fastboot instead of some random one in the system path
• Specifies the device ID, this assures to apply to the correct device, if multiple devices happen to be connected to the PC
• Adds / removes options like -w , verity, verification ... depending on what the user has chosen
• adds --skip-reboot to the last step of image update to make sure the phone does not boot to system
• Flashes the patch
• - Reboots to system

Here's what got generated with March update for my p7p
I redacted the device ID
I had chosen to flash to inactive slot.

chcp 437
@ECHO OFF
:: This is a generated file by PixelFlasher v4.8.0.0

PATH=%PATH%;"%SYSTEMROOT%\System32"
echo Switching active slot to the other ...
"C:\Android\platform-tools\fastboot.exe" -s REDACT --set-active=other
"C:\Android\platform-tools\fastboot.exe" -s REDACT --verbose  flash bootloader bootloader-cheetah-cloudripper-1.0-9618366.img
"C:\Android\platform-tools\fastboot.exe" -s REDACT reboot-bootloader
ping -n 5 127.0.0.1 >nul
"C:\Android\platform-tools\fastboot.exe" -s REDACT --verbose  flash radio radio-cheetah-g5300g-221229-230210-b-9589366.img
"C:\Android\platform-tools\fastboot.exe" -s REDACT reboot-bootloader
ping -n 5 127.0.0.1 >nul
"C:\Android\platform-tools\fastboot.exe" -s REDACT --verbose  --skip-reboot update image-cheetah-tq2a.230305.008.c1.zip
echo rebooting to bootloader ...
"C:\Android\platform-tools\fastboot.exe" -s REDACT reboot bootloader
echo Sleeping 5-10 seconds ...
ping -n 5 127.0.0.1 >nul
ping -n 5 127.0.0.1 >nul
echo flashing pf_boot ...
"C:\Android\platform-tools\fastboot.exe" -s REDACT --verbose  flash init_boot pf_boot.img
echo rebooting to system ...
"C:\Android\platform-tools\fastboot.exe" -s REDACT reboot

 

[roirraW "edor" ehT]

The PATH=%PATH%;"%SYSTEMROOT%\System32" comes from the flash_all.bat script by Google, it is on the first line after the comments.
This is probably due to fastboot.exe having dependencies on windows binaries which are in system32,.
Typically the PATH environment would already have system32 in the path, the script is making sure it has by adding it just in case the user env settings has been modified intentionally or unintentionally.
It's just a safety measure added by Google.

Ah, thank you! Indeed, I verified in a virtual PC that System32 is already usually in the path, but it makes sense for the script to make sure.

I removed my optional advice from my post.

Yes, this is how early versions of PF used to do, by repacking the patched boot into the firmware and flashing.
It no longer does that because that is slow and unnecessary.
What it currently does is:

• it builds a modified flash_all script (called flash-phone.bat)
• Uses full path to Android platform tools, this assures to pick up the correct fastboot instead of some random one in the system path
• Specifies the device ID, this assures to apply to the correct device, if multiple devices happen to be connected to the PC
• Adds / removes options like -w , verity, verification ... depending on what the user has chosen
• adds --skip-reboot to the last step of image update to make sure the phone does not boot to system
• Flashes the patch
• - Reboots to system

Here's what got generated with March update for my p7p
I redacted the device ID
I had chosen to flash to inactive slot.

chcp 437
@ECHO OFF
:: This is a generated file by PixelFlasher v4.8.0.0

PATH=%PATH%;"%SYSTEMROOT%\System32"
echo Switching active slot to the other ...
"C:\Android\platform-tools\fastboot.exe" -s REDACT --set-active=other
"C:\Android\platform-tools\fastboot.exe" -s REDACT --verbose  flash bootloader bootloader-cheetah-cloudripper-1.0-9618366.img
"C:\Android\platform-tools\fastboot.exe" -s REDACT reboot-bootloader
ping -n 5 127.0.0.1 >nul
"C:\Android\platform-tools\fastboot.exe" -s REDACT --verbose  flash radio radio-cheetah-g5300g-221229-230210-b-9589366.img
"C:\Android\platform-tools\fastboot.exe" -s REDACT reboot-bootloader
ping -n 5 127.0.0.1 >nul
"C:\Android\platform-tools\fastboot.exe" -s REDACT --verbose  --skip-reboot update image-cheetah-tq2a.230305.008.c1.zip
echo rebooting to bootloader ...
"C:\Android\platform-tools\fastboot.exe" -s REDACT reboot bootloader
echo Sleeping 5-10 seconds ...
ping -n 5 127.0.0.1 >nul
ping -n 5 127.0.0.1 >nul
echo flashing pf_boot ...
"C:\Android\platform-tools\fastboot.exe" -s REDACT --verbose  flash init_boot pf_boot.img
echo rebooting to system ...
"C:\Android\platform-tools\fastboot.exe" -s REDACT reboot

Interesting, and thank you!

 

[roirraW "edor" ehT]

LOL, Google can't quite get the https://www.google.com/android/beta page correct. A few minutes ago, they changed it to QPR2 in both places, now they're both QPR3, and they should change only the one on the left to QPR2.

Edit: I was reading it wrong, anyway. Was thinking the left side was for QPR2 Stable.

 

[Lughnasadh]

LOL, Google can't quite get the https://www.google.com/android/beta page correct. A few minutes ago, they changed it to QPR2 in both places, now they're both QPR3, and they should change only the one on the left to QPR2.

View attachment 5863495

Hopefully this means the QPR3 beta is about to drop.

 

[Dr.Pepper]

Yeah, buddy(c)
I guess, its sooon)

 

[roirraW "edor" ehT]

Other known issues​

Based on our testing, you might encounter the following issues when using Android 13 QPR3. These issues are already known, so there's no need to file additional reports for similar issues.

Android Platform​

• If the user tries to open the camera by pressing the power button twice, the camera displays a black screen instead.
• In some cases when a work profile is switched on or off, the device reboots instead.
• The list of Recent apps sometimes becomes unresponsive if the screen orientation is changed while the list is open.

Factory images for Google Pixel | Android Developers

Instructions for downloading and installing QPR Beta system images for Pixel devices

developer.android.com

Pixel 7 Pro

cheetah-t3b1.230224.005-factory-08d6844d.zip

08d6844d038fe0f104121c8d5967328d5f12817bd68e9cea80f74a12965f52ee

OTA images for Google Pixel | Android Developers

Instructions for downloading and installing QPR beta system images for Pixel devices

developer.android.com

Pixel 7 Pro

cheetah-ota-t3b1.230224.005-b9ea6269.zip

b9ea62698c96f7d66e74c0104410388436ad1df00ac88c5c76c3134610ca82e9

Release notes | Android Developers

Release notes and known issues for the latest Android 13 builds.

developer.android.com

Release notes​

bookmark
Beta 1

Release date	March 15, 2023
Build	T3B1.230224.005
Security patch level	March 2023
Google Play services	23.08.15

About Android 13 QPR3​

Following the stable release of Android 13 to AOSP, we continue to update the platform with fixes and improvements that are then rolled out to supported devices. These releases happen on a quarterly cadence through Quarterly Platform Releases (QPRs), which are delivered both to AOSP and to Google Pixel devices as part of Feature Drops.
Although these updates don't include app-impacting API changes, we provide images of the latest QPR beta builds so you can test your app with these builds as needed.
Unlike developer previews and betas for unreleased versions of Android, these builds are suitable for general use. However, please review any known issues that are listed on this page.
Android 13 QPR3 builds on the updates in Android 13 QPR2 and the initial Android 13 release and includes the next round of refinements such as bug fixes and improvements to stability and performance.

How to get QPR3 Beta 1​

You can install Android 13 QPR3 Beta 1 on any of the following Google Pixel devices:

• Pixel 4a and 4a (5G)
• Pixel 5 and 5a
• Pixel 6 and 6 Pro
• Pixel 6a
• Pixel 7 and 7 Pro

See Get Android 13 QPR beta builds for details on how to get started.

General advisories​

Be aware of these general advisories about the release:

• This release might have various stability, battery, or performance issues.
• For users with accessibility needs, this release might not be appropriate for daily use.
• Some apps might not function as expected when running on this release. This limitation includes Google's apps as well as other apps.
• Android 13 QPR beta builds aren't Compatibility Test Suite (CTS)‑approved, but they have passed preliminary testing and provide a stable set of pre-release APIs for developers. Apps that depend on CTS-approved builds or use SafetyNet APIs might not work normally on Android 13 QPR beta builds.

Get support​

Two primary support channels are available to you when developing and testing with Android 13 QPR3. The channel you should use to get support depends on where you are encountering your issue.

• Support for device-specific issues, system issues, and issues with Google apps: Use the Issue Tracker to create new issues and to view and track issues that you and other developers have submitted.
  Before creating your own issue, check the known issues listed on this page and search the lists of top open issues and recently created issues to see if someone else has already reported it. You can subscribe and vote for an issue by clicking star this issue .
  See Where to report issues to find an issue template that best matches the type of issue that you are encountering.
• Support for issues with other apps: Contact the app developer directly.

To discuss issues or ideas with other developers working with the Android 13 QPR Beta, join the android_beta community on Reddit.

Top resolved issues​

The following issues have been resolved in Android 13 QPR3 Beta 1:

• Fixed an issue where the clock text on the lockscreen was the wrong color.
• Fixed an issue where Bluetooth audio wasn't working on some devices.
• Fixed an issue where the fingerprint icon that is normally displayed on screen to indicate the position of the fingerprint sensor erroneously changed to an exclamation point (!).
• Fixed an issue where live wallpapers could not be selected or used.
• Fixed an issue where widgets, app icon positions, and other configurable options on the home screen were reset after installing an OTA update.
• Fixed an issue that caused a device to be unenrolled from Face Unlock after installing an OTA update.

Top open issues​

See top open issues for the latest list of top open issues that have been reported.

Other known issues​

Based on our testing, you might encounter the following issues when using Android 13 QPR3. These issues are already known, so there's no need to file additional reports for similar issues.

Android Platform​

• If the user tries to open the camera by pressing the power button twice, the camera displays a black screen instead.
• In some cases when a work profile is switched on or off, the device reboots instead.
• The list of Recent apps sometimes becomes unresponsive if the screen orientation is changed while the list is open.

 

[Lughnasadh]

https://twitter.com/i/web/status/1636099191553286144

 

[kiekan]

Just flashed t3b1.230224.005 using the factory image. Successfully rooted and got AOSP mods working.

Does anyone else notice that screen looks significantly darker when using the adaptive display color setting?

 

[Gordietm]

Just flashed t3b1.230224.005 using the factory image. Successfully rooted and got AOSP mods working.

Does anyone else notice that screen looks significantly darker when using the adaptive display color setting?

I noticed that myself. Definitely darker.