Fixed
Status Update
No update yet.
Comments
ya...@google.com
bo...@google.com
ke...@netflix.com
what is in update.zip ? can you share that file to triage this issue
bo...@google.com
MHC19Q for Nexus 5X (bullhead) - https://dl.google.com/dl/android/aosp//bullhead-ota-mhc19q-8fe67a2b.zip
N4F26T for Nexus 5X (bullhead) -https://dl.google.com/dl/android/aosp/bullhead-ota-n4f26t-648ce802.zip
WW-12.2.5.23 for Asus ZenFone Go (ASUS_X014D) -http://dlcdnet.asus.com/pub/ASUS/ZenFone/ZB452KG/UL-ASUS_X014D-WW-12.2.5.23-user.zip
Look like, this happens only with a big images.
N4F26T for Nexus 5X (bullhead) -
WW-12.2.5.23 for Asus ZenFone Go (ASUS_X014D) -
Look like, this happens only with a big images.
zh...@google.com
On Windows 10 (x64)
sy...@syntezzz.ru
related to (and probably worked around for now by) internal bug http://b/36046324
i do think we should also start shipping a 64-bit Windows platform tools package.
we should also consider changing android::base::ReadFdToString to call fstat and pre-size the vector. not worthwhile for reading things like /proc/uptime, but the default expansion behavior for a huge file like a full OTA update is going to result in substantial overhead. (which will explain the regression between .3 and .4, since the former will have allocated exactly the necessary number of bytes.)
lastly (and maybe not worth doing at all, depending on how soon we can get folks to use a 64-bit platform tools on Windows, since all the other platforms are already 64-bit-only), we could consider rewriting the adb sideload code to (a) mmap/munmap rather than actually read in to physical memory or (b) pread. i'm not sure what the performance impact of pread would be (especially on Windows where there is no pread equivalent).
i do think we should also start shipping a 64-bit Windows platform tools package.
we should also consider changing android::base::ReadFdToString to call fstat and pre-size the vector. not worthwhile for reading things like /proc/uptime, but the default expansion behavior for a huge file like a full OTA update is going to result in substantial overhead. (which will explain the regression between .3 and .4, since the former will have allocated exactly the necessary number of bytes.)
lastly (and maybe not worth doing at all, depending on how soon we can get folks to use a 64-bit platform tools on Windows, since all the other platforms are already 64-bit-only), we could consider rewriting the adb sideload code to (a) mmap/munmap rather than actually read in to physical memory or (b) pread. i'm not sure what the performance impact of pread would be (especially on Windows where there is no pread equivalent).
bo...@google.com
Correction to #5: Windows does support pread() - it's in ReadFile()'s OVERLAPPED parameter.
bo...@google.com
@7: we'd still need to write the pread wrapper, though. (similar if we went with mmap/munmap.)
https://android-review.googlesource.com/#/c/355481/ pre-sizes the vector, which should be enough to undo the regression from '.3 to '.4...
ja...@google.com
Comment has been deleted.
ki...@gmail.com
Hi I'm getting the same issue on Windows 10 when I try to sideload a TWRP backup.
- adb devices gives my device
- adb usb gives error: closed
- adb sideload 6.13.771.4_ckpv5.zip gives
loading: '6.13.771.4_ckpv5.zip'...
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Please can somebody help with this issue I've been trying to sort this for 3 days. Thanks.
- adb devices gives my device
- adb usb gives error: closed
- adb sideload 6.13.771.4_ckpv5.zip gives
loading: '6.13.771.4_ckpv5.zip'...
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Please can somebody help with this issue I've been trying to sort this for 3 days. Thanks.
ki...@gmail.com
I also get this problem. Is there a workaround?
wh...@gmail.com
I also get this error message when trying to update Android OS 7.1.1 from N6F26R to N6F26U security patch for Nexus 6. Please help. Thank you.
ch...@gmail.com
It happens when i try to flash any rom to my OnePlus 3, how can i solve it?
ch...@gmail.com
Trying to sideload via adb on Win10 gives me this as well. Nexus 6 trying to sideload from 7.0 to 7.1.1 (N6F26U, Mar 2017)
ch...@gmail.com
My Nexus 9 is on a bootloop and is locked so this was my way out of the bootloop but I've got the same error std::bad_alloc...
If someone has found a way to suppress this error let us know !
If someone has found a way to suppress this error let us know !
ch...@gmail.com
As this bug is in 25.0.4 only, simply revert to platform tools 25.0.3 to successfully sideload the image. This solved both my 'std::bad_alloc' error and bootloop error (hopefully).
ch...@gmail.com Restricted+
Restricted+
Comment has been deleted.
ch...@gmail.com Restricted
Restricted
Comment has been deleted.
Description
Android Studio Version: Giraffe | 2022.3.1
Emulator Version (Emulator--> Extended Controls--> Emulator Version): 32.1.14-10330179
HAXM / KVM Version: HVF 13.5.0
Android SDK Tools: 26.1.1
Host Operating System: macOS 13.5
CPU Manufacturer: Other CPU:
64-bit CPU
RAM: 16384 MB
GPU:
Build Fingerprint:
AVD Details: Name: Pixel_C_Tablet_API_33
CPU/ABI: arm64
Path: /Users/tomas/.android/avd/Pixel_C_API_33.avd
Target: google_apis [Google APIs] (API level 33)
Skin: 2560x1800
SD Card: 512 MB
AvdId: Pixel_C_Tablet_API_33
PlayStore.enabled: false
avd.ini.displayname: Pixel C Tablet API 33
avd.ini.encoding: UTF-8
disk.dataPartition.size: 6G
fastboot.chosenSnapshotFile:
fastboot.forceChosenSnapshotBoot: no
fastboot.forceColdBoot: no
fastboot.forceFastBoot: yes
hw.accelerometer: yes
hw.arc: false
hw.audioInput: yes
hw.battery: yes
hw.camera.back: virtualscene
hw.camera.front: emulated
hw.cpu.ncore: 4
hw.dPad: no
hw.device.hash2: MD5:b6f369a5174fab4bbf46015b0d842ec6
hw.device.manufacturer: Google
hw.gps: no
hw.gpu.enabled: yes
hw.gpu.mode: auto
hw.initialOrientation: landscape
hw.keyboard: yes
hw.lcd.density: 320
hw.lcd.height: 1800
hw.lcd.width: 2560
hw.mainKeys: no
hw.ramSize: 1536
hw.sdCard: yes
hw.sensors.orientation: yes
hw.sensors.proximity: yes
hw.trackBall: no
image.sysdir.1: system-images/android-33/google_apis/arm64-v8a/
runtime.network.latency: none
runtime.network.speed: full
showDeviceFrame: no
skin.dynamic: yes
skin.path.backup: /Users/tomas/Library/Android/sdk/skins/pixel_c
tag.display: Google APIs
vm.heapSize: 192
Steps to Reproduce Bug:Call PackageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_HINGE_ANGLE) and this method returns true on Pixel C tablet.
Expected Behavior:
Returns false on Pixel C tablet.
Observed Behavior: