Introduce a new instance-specific composite disk When we originally designed the composite disk, it was our intention that only the disk overlay.img would be instance-specific. The composite.img would refer to files that were effectively read-only and usable by all multi-tenant instances. This would minimize disk space requirements and launch times. The composite disk, and the images it referred to, could be shared by all instances. However, we quickly broke this when "magic state" that was being passed through crosvm's kernel cmdline feature stopped working, after landing the Cuttlefish Bootloader. We had to repack at least one partition on every launch, per instance, and that meant we needed a per-instance composite.img. For crosvm this has a small cost, because as long as the instance-specific files are put into instance-specific locations, only the composite.img meta file has to be rewritten. But for QEMU, it's very expensive. It's also not a very high fidelity solution, and doesn't match how real device clusters would be provisioned. The u-boot environment problem was later fixed to push the changing state into vendor_boot.img cmdline or bootconfig, but this still involves composite disk modifications, and has all the same problems above. This change adds another hard disk which is explicitly for "persistent" instance-specific data. This hard disk will not be overlayed, because the partitions in the disk are not shared between instances, and writes are expected to persist powerwashing, factory reset, OTA, etc. This disk houses the recently added FRP block, and the U-Boot environment, but later we will add a 'factory partition' to replace the config_server. This change does not fully remove the need for a per-instance composite disk, because we still need to repack the vendor_boot images -- but once we can pass an instance ID or other properties through the U-Boot env or factory partition, we can move composite.img back to the assembler step. Bug: 183006588 Change-Id: I8e5332a1032b550cc93c797928e7cb202a30d2fb
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.
Download, build, and install the host debian package:
git clone https://github.com/google/android-cuttlefish cd android-cuttlefish debuild -i -us -uc -b sudo dpkg -i ../cuttlefish-common_*_amd64.deb || sudo apt-get install -f 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-master if you don‘t know what you’re looking for
Navigate to aosp_cf_x86_phone and click on userdebug for the latest build
Click on Artifacts
Scroll down to the OTA images. These packages look like aosp_cf_x86_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_phone-img-xxxxxx.zip
Launch cuttlefish with:
$ HOME=$PWD ./bin/launch_cvd
$ HOME=$PWD ./bin/stop_cvd
You can use adb to debug it, just like a physical device:
$ ./bin/adb -e shell
You can use the TightVNC JViewer. Once you have downloaded the TightVNC Java Viewer JAR in a ZIP archive, run it with
$ java -jar tightvnc-jviewer.jar -ScalingFactor=50 -Tunneling=no -host=localhost -port=6444
Click “Connect” and you should see a lock screen!