commit | a835472a0b14a5a30569452fa32a112f0f46a5ba | [log] [tgz] |
---|---|---|
author | A. Cody Schuffelen <[email protected]> | Thu Jun 06 18:31:54 2024 -0700 |
committer | A. Cody Schuffelen <[email protected]> | Fri Jun 07 13:42:25 2024 -0700 |
tree | 7880c2af2322908a373c9699e4beface35f6daa3 | |
parent | e206565d87f1d1c9491ea5ee72295e7f17efd7c0 [diff] |
Mitigations for "adb not ready yet" suspend issues Suspending a device includes issuing some device commands to suspend servies where the host side is not snapshot-aware. These commands are issued through running `adb shell`. If the `adb` background server is not yet running, that gets started by the first device. This raises two issues: 1. After the adb server comes up, there may be a delay before `adb_connection_maintainer` informs `adb` background server that the device exists. If the server doesn't know, there might be an error like `adb: device '0.0.0.0:6520' not found` 2. The `adb` background server runs in the working directory of the first `adb` invocation. Because `run_cvd` has its working directory in the host runtime directory of the device, this looks like a still-running device process when trying to clear the runtime directory to create a new device instance: ``` Instance directory files in use. Try `cvd reset`? Observed PIDs: 3396063 ``` (1) is fixed by using `adb wait-for-device` and (2) is fixed by running `adb` commands with a working directory of `/`. Design for solutions by by fmayle@ and khei@. Repro: ``` $ adb kill-server $ cvd start --snapshot_compatible --daemon --enable_virtiofs=false --gpu_mode=guest_swiftshader $ cvd suspend $ cvd snapshot_take --snapshot_path=$HOME/cf-snapshot $ cvd resume $ cvd stop $ cvd start ``` Bug: 345542598 Test: Repro instructions Change-Id: If46c93ef2a5bebac3efa6fe510f9a34bbbbc8eaa
Make sure virtualization with KVM is available.
grep -c -w "vmx\|svm" /proc/cpuinfo
This should return a non-zero value. If running on a cloud machine, this may take cloud-vendor-specific steps to enable. For Google Compute Engine specifically, see the GCE guide.
ARM specific steps:
/dev/kvm
. Note that this method can also be used to confirm support of KVM on any environment.Download, build, and install the host debian packages:
sudo apt install -y git devscripts config-package-dev debhelper-compat golang curl git clone https://github.com/google/android-cuttlefish cd android-cuttlefish sudo apt install devscripts equivs for dir in base frontend; do pushd $dir sudo mk-build-deps -i dpkg-buildpackage -uc -us popd done sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f sudo usermod -aG kvm,cvdnetwork,render $USER sudo reboot
The reboot will trigger installing additional kernel modules and applying udev rules.
Go to http://ci.android.com/
Enter a branch name. Start with aosp-main
if you don‘t know what you’re looking for
Navigate to aosp_cf_x86_64_phone
and click on userdebug
for the latest build
aosp-main-throttled
and device target aosp_cf_arm64_only_phone-trunk_staging-userdebug
Click on Artifacts
Scroll down to the OTA images. These packages look like aosp_cf_x86_64_phone-img-xxxxxx.zip
-- it will always have img
in the name. Download this file
Scroll down to cvd-host_package.tar.gz
. You should always download a host package from the same build as your images.
On your local system, combine the packages:
mkdir cf cd cf tar xvf /path/to/cvd-host_package.tar.gz unzip /path/to/aosp_cf_x86_64_phone-img-xxxxxx.zip
Launch cuttlefish with:
$ HOME=$PWD ./bin/launch_cvd
You can use adb
to debug it, just like a physical device:
$ ./bin/adb -e shell
When launching with ---start_webrtc
(the default), you can see a list of all available devices at https://localhost:8443
. For more information, see the WebRTC on Cuttlefish documentation.
You will need to stop the virtual device within the same directory as you used to launch the device.
$ HOME=$PWD ./bin/stop_cvd