از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
سرویس مجازی سازی
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
VirtualizationService
چندین VM مهمان را مدیریت می کند، محافظت شده یا غیره، که در سیستم Android اجرا می شوند، عمدتاً با مدیریت نمونه های crosvm. VirtualizationService
یک API AIDL را نشان می دهد که سرویس ها یا برنامه های سیستم می توانند از آن برای راه اندازی، نظارت و توقف VM ها استفاده کنند. برای استفاده از VirtualizationService
، virtmgr
مستقیماً اجرا کنید یا javalib یا rustlib را وارد کنید که virtmgr
به عنوان یک فرآیند فرزند اجرا می کند.
چرخه حیات VM
دسترسی به VM توسط شی IVirtualMachine
ردیابی می شود. تا زمانی که حداقل یک مرجع به شی IVirtualMachine
وجود داشته باشد، ماشین مجازی به کار خود ادامه می دهد (مگر اینکه به خودی خود خراب یا خاموش شود). اگر تمام ارجاعات به شی IVirtualMachine
قبل از خاموش شدن VM حذف شوند، VirtualizationService
به طور خودکار VM را خاموش می کند. این فرآیند به این معنی است که اگر کلاینتی که VM را راه اندازی کرده است توسط کشنده حافظه کم خاموش شود، VM نیز خاموش می شود، بنابراین از نشت منابع جلوگیری می شود.
هر VM توسط نمونه خود از crosvm مدیریت می شود که VirtualizationService
به نوبه خود از طرف مشتری آن را مدیریت می کند. VirtualizationService
در virtmgr
این پردازشهای فرزند crosvm را همانطور که لازم است با منابع اختصاصی جهانی از جمله CID اعطا شده توسط VirtualizationServiceInternal
در virtualizationservice
شروع می کند و توصیفگرهای فایل را برای تصاویر مورد نیاز VM به آنها ارسال می کند. VirtualizationService
سپس فرآیند فرزند را برای زمان مرگ آنها نظارت می کند، بنابراین می تواند مشتریان باقی مانده را بر این اساس مطلع کند.
بسته بندی VM
crosvm از دو روش مختلف برای بوت کردن یک VM پشتیبانی می کند: یا یک هسته و initrd ارائه می شود یا یک بوت لودر ارائه می شود. در هر صورت، تعداد دلخواه از تصاویر دیسک نیز می تواند ارائه شود، که ممکن است یک تصویر خام یا ترکیبی از چندین پارتیشن باشد. تصاویر مختلف توسط مشتری به عنوان توصیف کننده فایل ارائه می شود.
VirtualizationService
تصاویر دیسک کامپوزیت را در صورت تقاضا می سازد. این فرآیند ضروری است زیرا فایل دیسک کامپوزیت به طور داخلی به فایلهای تصویری پارتیشن مختلف تشکیلدهنده دیسک اشاره دارد که توسط مشتری ارسال میشوند و ممکن است مستقیماً توسط crosvm قابل دسترسی نباشند. برای حل این مشکل، VirtualizationService
تضمین می کند که اعداد توصیفگر فایل به ارث برده شده توسط crosvm با شماره های توصیفگر فایل که VirtualizationService
در ایجاد تصاویر ترکیبی استفاده می کند، یکسان است. تصویر دیسک ترکیبی از نام فایل ها به شکل /proc/self/fd/N
برای نمایش هر فایل پارتیشن استفاده می کند.
برای pVM های Microdroid، AVF شامل یک بوت لودر است که هسته را از پارتیشنی از یک تصویر دیسک کامپوزیت بارگیری می کند، طبق جریان استاندارد Android Verified Boot.
سوکت های VM (vsock)
رابط اصلی برای ارتباط بین pVM ها vsock است، یک رابط استاندارد virtio socket. هر ماشین مجازی توسط یک شناسه زمینه 32 بیتی (CID) شناسایی میشود که مشابه یک آدرس IP است که VirtualizationServiceInternal
هنگام ایجاد VirtualizationService
به ماشین مجازی اختصاص میدهد و میتواند سرویسها را در هر شماره پورتی که VM انتخاب میکند، نمایش دهد. هنگامی که ماشین مجازی در حال اجرا است، CID منحصربهفرد است، اما زمانی که ماشین مجازی پایان مییابد و تمام دستههای بایندر IVirtualMachine
به ماشین مجازی حذف میشوند، میتوان مقدار CID را بازیافت کرد.
رابط اشکال زدایی
دستور vm
برای اهداف دیباگ ارائه شده است. این دستور به توسعهدهنده اجازه میدهد یک VM را از پوسته شروع کند، گزارشهای آن را مشاهده کند و VM را خاتمه دهد. با دستور vm
یا سایر رابط های ارائه شده توسط AVF، یک VM می تواند در حالت اشکال زدایی (FULL) یا غیراشکال زدایی (NONE) راه اندازی شود. با یک VM قابل اشکالزدایی، میتوانید گزارشهای سطح سیستمعامل را ببینید، به پوسته ADB دسترسی داشته باشید، و بارگذاری خرابی یا برنامه را ضبط کنید. توصیه می شود از یک VM غیر قابل اشکال زدایی در تولید استفاده کنید. برای اطلاعات بیشتر در مورد ابزار خط فرمان و سایر رابط های اشکال زدایی که AVF ارائه می دهد، به debug/README.md مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# VirtualizationService\n\n`VirtualizationService` manages multiple guest VMs, protected or otherwise,\nrunning on an Android system, primarily by managing instances of crosvm.\n`VirtualizationService` exposes an AIDL API, which system services or apps can\nuse to start, monitor, and stop VMs. To use `VirtualizationService`, execute\n`virtmgr` directly or import [javalib](https://cs.android.com/android/platform/superproject/+/main:packages/modules/Virtualization/javalib/ \"javalib\") or [rustlib](https://cs.android.com/android/platform/superproject/+/main:packages/modules/Virtualization/vmclient/ \"rustlib\") which executes `virtmgr` as\na child process.\n\nVM lifecycle\n------------\n\nAccess to a VM is tracked by the `IVirtualMachine` object. As long as there's\nat least one reference to `IVirtualMachine` object then the VM continues to\nrun (unless it crashes or shuts down of its own accord). If all references to\nthe `IVirtualMachine` object are dropped before the VM shuts down, then\n`VirtualizationService` automatically shuts down the VM. This process implies\nthat if the client that started the VM is shut down by the low memory killer,\nthen the VM is also shut down, thus preventing resource leaks.\n\nEach VM is managed by its own instance of crosvm, which `VirtualizationService`\nin turn manages on behalf of the client. `VirtualizationService` in `virtmgr`\nstarts these crosvm child processes as required with allocated global resources\nincluding the CID granted by `VirtualizationServiceInternal` in\n`virtualizationservice`, and passes them the file descriptors for the images the\nVM needs. `VirtualizationService` then monitors the child process for when they\ndie, so it can notify any remaining clients accordingly.\n\nVM packaging\n------------\n\ncrosvm supports two different ways of booting a VM: either a kernel and initrd\nare provided or a bootloader is provided. In either case, an\narbitrary number of disk images can also be provided, which might be either\na raw image or a composite of several partitions. The various images are\nprovided by the client as file descriptors.\n\n`VirtualizationService` builds composite disk images on demand. This process is\nnecessary because the composite disk file refers internally to the various\npartition image files composing the disk, which are passed by the client and\nmight not be directly accessible by crosvm. To get around this issue,\n`VirtualizationService` ensures that the file descriptor numbers inherited by\ncrosvm are the same as the file descriptor numbers which `VirtualizationService`\nused in creating the composite images. The composite disk image uses filenames\nin the form to `/proc/self/fd/N` to represent each partition file.\n\nFor Microdroid pVMs, AVF includes a bootloader, which loads the kernel from\na partition of a composite disk image, following the standard Android\nVerified Boot flow.\n\nVM Sockets (vsock)\n------------------\n\nThe primary interface for communication between pVMs is vsock, a standard\nvirtio socket interface. Each VM is identified by a 32-bit context identifier\n(CID), which is analogous to an IP address, which\n`VirtualizationServiceInternal` assigns to the VM when `VirtualizationService`\ncreates the VM, and can expose services on whatever port numbers the VM chooses.\nThe CID is unique while the VM is running, but the CID value can be recycled\nwhen the VM is terminated and all the `IVirtualMachine` binder handles to the VM\nhave been dropped.\n\nDebug interface\n---------------\n\nThe `vm` command is provided for debug purposes. This command lets a developer\nstart a VM from the shell, view its logs, and terminate the VM. With the `vm`\ncommand or other interfaces provided by AVF, a VM can start in either\ndebuggable (FULL) or non-debuggable (NONE) mode. With a debuggable VM, you can\nsee OS-level logs, access the ADB shell, and capture crash-dump or app payload.\nIt's recommended to use a non-debuggable VM in production. For more on\nthe command line tool and other debug interfaces that AVF provides, see\n[debug/README.md](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Virtualization/docs/debug/README.md \"Debugging protected VMs\")."]]