اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
VirtualizationService
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يدير VirtualizationService العديد من الأجهزة الافتراضية للضيوف، سواء كانت محمية أو غير محمية،
التي تعمل على نظام Android، وذلك بشكل أساسي من خلال إدارة مثيلات crosvm.
VirtualizationService يعرِض واجهة برمجة تطبيقات AIDL API، والتي يمكن لخدمات النظام أو التطبيقات
استخدامها لبدء تشغيل الأجهزة الافتراضية ومراقبتها وإيقافها. لاستخدام VirtualizationService، يمكنك تنفيذ
virtmgr مباشرةً أو استيراد javalib أو rustlib اللذان ينفِّذان virtmgr كأحد
العمليات الفرعية.
مراحل نشاط الأجهزة الافتراضية
يتم تتبُّع الوصول إلى جهاز افتراضي من خلال عنصر IVirtualMachine. ما دام هناك
إشارة واحدة على الأقل إلى عنصر IVirtualMachine، سيستمر تشغيل الجهاز الافتراضي (ما لم يتعطل أو يتم إيقافه تلقائيًا). إذا تم إسقاط جميع الإشارات إلى
العنصر IVirtualMachine قبل إيقاف تشغيل الجهاز الظاهري، يتم عندئذٍ
إيقاف تشغيل الجهاز الظاهري تلقائيًا من قِبلVirtualizationService. تشير هذه العملية إلى أنّه في حال تم إيقاف العميل الذي بدأ تشغيل الجهاز الظاهري من خلال أداة قتل العمليات بسبب انخفاض ذاكرة الوصول العشوائي، سيتم أيضًا إيقاف الجهاز الظاهري، ما يمنع تسرب الموارد.
تُدار كل آلة افتراضية من خلال نسخة خاصة بها من crosvm، والتي تديرها VirtualizationService
بدورهما نيابةً عن العميل. يبدأ VirtualizationService في virtmgr
عمليات crosvm الفرعية هذه حسب الحاجة باستخدام موارد عالمية مخصّصة
بما في ذلك معرّف الجلسة الذي منحه VirtualizationServiceInternal في
virtualizationservice، ويمرّر إليها أوصاف الملفات للصور التي يحتاج إليها
جهاز افتراضي. بعد ذلك، يراقب VirtualizationService العملية الفرعية لمعرفة متى
تنتهي، حتى يتمكّن من إرسال إشعار إلى أي عملاء متبقّين وفقًا لذلك.
تغليف الأجهزة الافتراضية
يتيح crosvm طريقتَين مختلفتَين لتشغيل جهاز افتراضي: إمّا توفير نواة وملف initrd
أو توفير أداة تحميل. وفي كلتا الحالتَين، يمكن أيضًا تقديم
عدد عشوائي من صور الأقراص، والتي قد تكون
صورة أولية أو مركبة من عدة أقسام. يقدّم العميل الصور المختلفة
كأوصاف للملفات.
VirtualizationService تُنشئ صور أقراص مركبة عند الطلب. هذه العملية
ضرورية لأنّ ملف القرص المركب يشير داخليًا إلى ملفات صور التقسيمات المختلفة التي تتألف منها القرص، والتي يمررها العميل
وقد لا يمكن لنظام crosvm الوصول إليها مباشرةً. لحلّ هذه المشكلة، تضمن VirtualizationService أنّ أرقام أوصاف الملفات التي اكتسبها
crosvm هي نفسها أرقام أوصاف الملفات التي استخدمتها VirtualizationService
لإنشاء الصور المركبة. تستخدم صورة القرص المركبة أسماء الملفات
بالتنسيق /proc/self/fd/N لتمثيل كل ملف قسم.
بالنسبة إلى آلات افتراضية Microdroid، يتضمّن AVF أداة تحميل تمهيدية تحمّل النواة من أحد أقسام صورة قرص مركبة، وذلك باتّباع عملية التمهيد التحقق من Android العادية.
مآخذ الأجهزة الافتراضية (vsock)
الواجهة الأساسية للتواصل بين آلات افتراضية مخصّصة للتطبيقات هي vsock، وهي واجهة مقبس virtio عادية. يتم تحديد كل جهاز افتراضي من خلال معرّف سياق مؤلف من 32 بت
(CID)، وهو مشابه لعنوان IP، والذي يُسنِده VirtualizationServiceInternal إلى الجهاز الافتراضي عند VirtualizationService
إنشاء الجهاز الافتراضي، ويمكنه عرض الخدمات على أي أرقام منافذ يختارها الجهاز الافتراضي.
يكون رقم تعريف العميل فريدًا أثناء تشغيل الجهاز الظاهري، ولكن يمكن إعادة استخدام قيمة رقم تعريف العميل
عند إنهاء تشغيل الجهاز الظاهري وإلغاء جميع عناصر تحكّم IVirtualMachine في الجهاز الظاهري.
واجهة تصحيح الأخطاء
يتم توفير الأمر vm لأغراض تصحيح الأخطاء. يتيح هذا الأمر للمطوّر
بدء تشغيل جهاز افتراضي من وحدة التحكّم، وعرض سجلّاته، وإيقاف تشغيل الجهاز. باستخدام الأمر vm
أو الواجهات الأخرى التي يوفّرها AVF، يمكن بدء تشغيل جهاز افتراضي في أحد الوضعَين التاليَين:
وضع تصحيح الأخطاء (FULL) أو وضع عدم تصحيح الأخطاء (NONE). باستخدام جهاز افتراضي قابل لتصحيح الأخطاء، يمكنك
الاطّلاع على السجلات على مستوى نظام التشغيل والوصول إلى وحدة تحكّم ADB وتسجيل بيانات تعطُّل التطبيق أو الحمولة.
يُنصح باستخدام جهاز افتراضي لا يمكن تصحيح أخطاءه في مرحلة الإنتاج. لمزيد من المعلومات عن
أداة سطر الأوامر وواجهات تصحيح الأخطاء الأخرى التي يوفّرها AVF، يُرجى الاطّلاع على
debug/README.md.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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\")."]]
