Orchestrator'ı yapılandırma

Orchestrator, her sanal makinede (VM) çalışan ve hizmet paketlerinin ne zaman oluşturulacağını, başlatılacağını, durdurulacağını veya imha edileceğini kontrol eden bir mekanizma sağlayan yerel bir SDV aracısıdır. Bu işlem, hizmet paketi örneklerinde işlemlerin ne zaman ve nasıl gerçekleştirileceğini belirleyen bir dizi kural tanımladığınız bir düzenleme yapılandırması aracılığıyla yapılır. Bu kurallar; araç, güç ve özel modlara dayalıdır.

Orchestrator'ı yapılandırma APEX'lerinde veya sanal makine başına yapılandırmalar aracılığıyla yapılandırabilirsiniz. Bu dağıtılmış yapılandırma sistemi, her hizmet paketinin parçalarının Hizmet Paketi Kayıt Defteri aracılığıyla bağımsız olarak güncellenmesine olanak tanır.

Şekil 1. Orchestrator yapılandırma şeması.

Araçtan bağımsız yapılandırmalar, OEM'e veya araca göre değişmez. Yapılandırma, her OEM'in tüm araçlarında aynı kalır. Araca özel yapılandırmalar, farklı OEM'lerin farklı araçlarında değişiklik gösterebilir ancak belirli bir OEM tarafından üretilen tüm araçlar için yapılandırma tümü için aynı olabilir.

Yapılandırma APEX'leri

Çalışma zamanında Orchestrator, her hizmet paketi için bir SDV düzenlemesi almak üzere hizmet paketi kayıt defterine giderek her yapılandırmayı yükler ve ayrıştırır. Daha fazla bilgi için Düzenleme meta verileri başlıklı makaleyi inceleyin.

Sanal makine başına yapılandırma

Orchestrator başlatıldığında sanal makine yapılandırmasını (varsa) yükler ve ayrıştırır. Bu yapılandırma dosyasının mutlak yolu, persist.sdv.orchestrator_config_path ve ro.boot.sdv.orchestrator_config_path sistem özellikleri aracılığıyla belirtilir.

Sistem, başlatma sırasında sanal makine yapılandırma dosyası yolunu aşağıdaki hiyerarşiye göre belirler:

1. Sistem, persist.sdv.orchestrator_config_path özelliğini kontrol eder. Değeri varsa bu yol kullanılır. Bu değer, yeniden başlatma işlemlerinde korunur veya çalışma zamanında ayarlanır.

2. persist.sdv.orchestrator_config_path boşsa sistem ro.boot.sdv.orchestrator_config_path özelliğini kontrol eder. ro.boot.sdv özelliğinin bir değeri varsa bu yol, kalıcı özelliğe kopyalanır ve mevcut başlatma ile gelecekteki tüm başlatmalar için kullanılır (geçersiz kılınmadığı sürece).

persist.sdv.orchestrator_config_path

persist.sdv.orchestrator_config_path, SDV Orchestrator aracısı tarafından yapılandırma dosyasının yolunu almak için kullanılan birincil özelliktir. Bu, kalıcı bir özelliktir. Yani değeri, cihaz yeniden başlatıldığında kaydedilir. Değeri çalışma zamanında değiştirebilirsiniz. Bu, test veya belirli senaryolar (ör. uçtan uca testler) için kullanışlıdır.

Değeri, çalışma zamanında setprop komutunu kullanarak ve derleme zamanında bir makefile (.mk uzantılı) veya kaynak komut dosyası (.rc uzantılı) kullanarak ayarlayabilirsiniz.

Özelliği çalışma zamanında ayarlama

Özelliği çalışma zamanında ayarlamak, değer yeniden başlatma işlemlerinde kaydedildiğinden test yapmak veya geçici değişiklikler yapmak için kullanışlıdır:

adb root
adb shell setprop persist.sdv.orchestrator_config_path {$path_to_file}.textproto

Özelliği derleme zamanında ayarlama

Bu özelliği cihazınızın derleme yapılandırmasının bir parçası olarak ayarlamak için ürününüzün veya anakartınızın makefile dosyasına bir satır ekleyin. Bu, yeni bir cihaz görüntüsü için varsayılan değer ayarlamak istediğinizde idealdir.

# Add this line to a product's or device's .mk file
PRODUCT_PROPERTY_OVERRIDES += persist.sdv.orchestrator_config_path={$path_to_file}.textproto

Bu özelliği bir kaynak komut dosyası içinde de ayarlayabilirsiniz:

# Add this line to an .rc file
on {$property}
    setprop persist.sdv.orchestrator_config_path {$path_to_file}.textproto

ro.boot.sdv.orchestrator_config_path

ro.boot.sdv.orchestrator_config_path, persist.sdv.orchestrator_config_path özelliğine ilk değer sağlamak için kullanılan, başlatma sırasında salt okunur bir özelliktir. Sistem başlatıldığında persist.sdv.orchestrator_config_path boşsa ro.boot.sdv.orchestrator_config_path değeri buraya kopyalanır. persist.sdv.orchestrator_config_path ayarlandıktan sonra sonraki başlatmalarda bu özellik tarafından üzerine yazılmaz.

ro.boot.sdv.orchestrator_config_path özelliğini bootconfig veya çekirdek komut satırını kullanarak ayarlayabilirsiniz.

Dosya biçimi

Yeni yapılandırmaların çalışma zamanında yüklenebilmesi için düzenleme yapılandırmasını .textproto biçiminde (ör. yapılandırılmış metin) tanımlayın.

Yapılandırma söz dizimi

Bu bölümde yapılandırma söz dizimi açıklanmaktadır.

Hizmet paketleri

Her hizmet paketi, hizmet paketi yapılandırmasıyla tanımlanmalıdır. Bu yapılandırma, paketi Orchestrator içinde tanımlar ve paket örneğinin yaşam döngüsünü yönetmek için kullanılır. Hizmet paketi yapılandırması şunları tanımlar:

• InstanceToGroupMapping, aynı hizmet paketinin örnekleri arasında bağımlılıklar oluşturmak için bir hizmet paketi örneğini bir gruba eklemenize olanak tanır.

• InstancesStates, hizmet paketi örneğinin farklı durumlarını tanımlar.

• InstancesStateConfiguration, koşul true olarak değerlendirilirse bir hizmet paketi örneğinin ayarlanması gereken durumu (InstancesStates üzerinden) tanımlar.

• ServiceBundleConfig, belirli hizmet paketi ve örnekleri hakkında bilgi içerir. Paket için ilgili InstanceToGroupMapping ve InstancesStateConfiguration değerlerini içerir.

• CustomModes, paketin yayınlamasına izin verilen özel modların listesini tanımlar. CustomModes, yetkisiz bir paketin özel modun değerini değiştirmesini önlemek için kullanılır. Hizmet paketi herhangi bir özel modda yayınlanmayabileceğinden bu alan isteğe bağlıdır. Daha fazla bilgi edinmek için Özel modlar bölümüne bakın.

Gerekli paket yapılandırması

Paket yapılandırması en azından şu özellikleri sağlar:

service_bundle_config {
    package_name: "package_name"
    service_bundle_name: "service_bundle_name"

    instance: "instance_1"
    instance: "instance_n"
}

Bu beyan, ilgili FQIN'lere sahip n hizmet paketi örneğini tanımlar:

vm_name.package_name.service_bundle_name.instance_1
…
vm_name.package_name.service_bundle_name.instance_n

Sanal makine adı, yapılandırmada açıkça belirtilmemiştir. Yapılandırma, sanal makine bazında tanımlandığından sanal makine adı her zaman yapılandırma dosyasının dağıtıldığı sanal makinenin adıdır ve düzenleme aracısı tarafından zaten bilinir.

Örnekleri yapılandırma

Hizmet paketi örneklerini bildirmenin bir etkisi yoktur. Orchestrator tarafından yürütülebilmesi için örneklerin yapılandırılması gerekir. Örneğin, Orchestrator'a bir örneğin hangi koşullarda (veya sanal makinenin ya da aracın durumunda) çalıştırılması gerektiği bildirilmelidir. Örnekleri yapılandırmak için yapılandırma durumları şu yöntemlerle tanımlanmalıdır:

• condition, sanal makine veya araç durumunda değerlendirilmesi gereken bir ifadedir.

• instances_states, koşul true olarak değerlendirilirse uygulanması gereken örnek başına bir durum grubudur.

Daha fazla bilgi edinmek için Koşullar bölümüne bakın.

service_bundle_config {
    package_name: "oem.package"
    service_bundle_name: "OemApplication"

    instance: "adaptive_light"
    instance: "reserve_light"

    state {
        condition {
            power_state: "ON"
        }

        instances_states {
            started: "adaptive_light"
            created: "reserve_light"
        }
    }
}

Örnek-grup eşlemesi

Hizmet örneklerini hizmet gruplarına dahil ederek de yapılandırabilirsiniz. Hizmet paketi yapılandırma düzeyinde, gruplara örnek ekleyebilirsiniz. Ardından, grupları sanal makine yapılandırması düzeyinde yapılandırabilirsiniz. Daha fazla bilgi edinmek için sonraki bölüme ve Hizmet paketleri başlıklı makaleye bakın.

service_bundle_config {
    package_name: "oem.package"
    service_bundle_name: "OemApplication"

    instance: "fog_front_light"
    instance: "fog_rear_light"
    instance: "turn_signal_light"
    instance: "light_flasher_display"

    # Declare that fog_light contains fog_front_light and fog_rear_light.
    group_mapping {
        group: "fog_light"
        instance: "fog_front_light"
        instance: "fog_rear_light"
    }

    # Declare that flasher_light contains turn_signal_light and light_flasher_display.
    group_mapping {
        group: "flasher_light"
        instance: "turn_signal_light"
        instance: "light_flasher_display"
    }
}

Proto şeması

Aşağıda bir proto şeması örneği verilmiştir:

// Service bundle configuration.
//
// Defines service bundle data, its instances and configuration for instances
// states depending on the state of the system
message ServiceBundleConfig {
  // Required. Name of the service bundle.
  string service_bundle_name = 1;

  // Required. Package name of the service bundle.
  string package_name = 2;

  // Required. Service instances.
  repeated string instance = 3;

  // Configuration for instances states depending on the state of the system.
  repeated InstancesStateConfiguration state = 4;

  // Mapping of groups to their member service instances.
  repeated InstanceToGroupMapping group_mapping = 5;

  // Custom modes that this service bundle is allowed to set.
  repeated string custom_mode = 6;

  // Defines the retry policies for specific instances.
  // If multiple mappings target the same instance, the one with the highest `max_retries`
  // value takes precedence. This applies across all configuration files.
  repeated InstanceToRetryMapping retry_mapping = 7;
}

// Mapping of instances to their retry configuration.
message InstanceToRetryMapping {
  // Required.
  //
  // Name of the instances for which the given retry configuration is applied.
  repeated string instance = 1;

  // Required.
  //
  // The configuration that defines the restart and retry strategy for the instances.
  RetryConfiguration retry_config = 2;

  // Configuration for retry and restart.
  // This configuration is applied after a failure on a transition or after the bundle instance
  // has crashed. Upon a successful operation, the retry counter are reset to max_retries. This
  // configuration can be applied to any service bundle, not only the monitored ones. If the
  // configuration is not provided or none of the optional fields are filled, the default behavior
  // stated is applied (the value from `ro.boot.sdv.orchestrator.recovery.max_retries`
  // or zero if not set).
  message RetryConfiguration {
    // The number of times a retry/restart operation can be performed.
    // Defines the number of times the Orchestrator retries a transition
    // after a transient failure or after a bundle crash notification.
    // This applies to creating, starting and destroying operations.
    // The retry count resets to max_retries after a successful operation.
    // If not set, the default configured value in the
    // `ro.boot.sdv.orchestrator.recovery.max_retries` is used, or-if not set-
    // it fallbacks to zero.
    optional uint32 max_retries = 1;
  }
}

// Mapping of groups to their member service instances.
message InstanceToGroupMapping {
  // Required. Names of groups to which members are added.
  //
  // Group behavior is defined in VM configuration.
  repeated string group = 1;

  // Required. Names of instances to be included in the groups.
  //
  // Can reference only instance defined in the same config file.
  repeated string instance = 2;
}

// Describes the state the service instances should be in after the state is executed.
//
// If there is no valid configuration for the instance in the specific system state, such instance is transitioned to the "destroyed" state.
//
// For the GroupsStates definition to be useful, at least one item should be present in any of the fields.
message InstancesStates {
  // Names of the instances that must be in a "created" state.
  repeated string created = 1;

  // Names of the instances that must be in a "started" state, overrides "created" state.
  repeated string started = 2;

  // Names of the instances that must not run, overrides all other states.
  repeated string destroyed = 3;
}

// Configuration for instances states depending on the state of the system.
message InstancesStateConfiguration {
  // Condition for the system state under which the related instances states should be executed by Orchestrator.
  //
  // If omitted, the related instances states are always executed.
  Condition condition = 1;

  // Required. States of service bundle instances to be executed by Orchestrator if the condition is true.
  InstancesStates instances_states = 2;
}

Sanal makine düzeyinde yapılandırma

Sanal makine yapılandırması, grup eşlemelerinin ve gruplar için yapılandırmanın tanımlanmasını sağlar. Bu, sanal makine düzeyinde hizmet paketleri arasındaki bağımlılıkları modellemek için kullanılır. Böylece, birden fazla hizmet paketinin durumunu aynı anda değiştirme esnekliği sağlanır. Bir grubun tüm örnekleri belirtilen duruma getirilir.

Orchestrator, durum değişikliğinin yürütülme sırasını garanti etmez. Orchestrator, her örneği belirtilen duruma yükseltir.

Gruplar, yapılandırma bölümlerinin herhangi birinde group adı kullanılarak dolaylı olarak tanımlanır. Örneğin, örnekten gruba eşleme, gruptan gruba eşleme ve grup yapılandırma durumları.

Gruptan gruba eşleme

Gruplar başka gruplar içerebilir. group_1, subgroup_2 içerir ifadesini kullanarak subgroup_2'deki tüm hizmet örneklerini group_1'ye eklemiş oluruz.

Örneğin:

# Declare that body contains fog_light and flasher_light.
group_mapping {
    group: "body"
    subgroup: "fog_light"
    subgroup: "flasher_light"
}

Grup yapılandırma

Grup beyan etmenin bir etkisi yoktur. Orchestrator tarafından yürütülebilmesi için grupların yapılandırılması gerekir. Örneğin, Orchestrator'a grupların hangi koşullarda veya sanal makinenin ya da aracın hangi durumunda çalışması gerektiği bildirilmelidir.

Grupları, hizmet örneklerine benzer şekilde, yani yapılandırma durumlarını kullanarak yapılandırabilirsiniz. Tek fark, söz diziminde instances_states yerine groups_states kullanılmasıdır:

state {
    condition {
        power_state: "ON"
    }

    groups_states {
        started: "Body"
        started: "Adas"
    }
}

Proto şeması

Aşağıda örnek bir proto şeması verilmiştir:

// VM configuration.
//
// Defines group-to-group mappings and configuration for groups
// states depending on the state of the system.
//
// Configurations of service bundles can also be defined in VM configuration (as well as in a separate configuration file).
message VmConfig {
  // Group to member groups mapping.
  repeated GroupToGroupMapping group_mapping = 1;

  // Configuration of group states.
  repeated GroupsStateConfiguration state = 2;

  // Required. We also allow to configure individual service bundles in the VM config, to simplify development and migration from the monolithic configuration.
  repeated ServiceBundleConfig service_bundle_config = 3;
}

// Mapping of groups to their member groups.
message GroupToGroupMapping {
  // Required. Names of groups to which members are added.
  repeated string group = 1;

  // Required. Names of member groups to be included in the groups.
  repeated string subgroup = 2;
}

// Describes the state the service instance groups should be in after the state is executed.
//
// If group configuration is valid in a specific system state, the configured state is applied to
// all group members. After that, the normal service instance configuration rules still apply:
// - "destroyed" > "started" > "created" precedence
// - not configured means the instance should be moved to the default state
//
// For the GroupsStates definition to be useful, at least one item should be present in any of the fields.
message GroupsStates {
  // Names of the groups that must be in a "created" state.
  repeated string created = 1;

  // Names of the groups that must be in a "started" state, overrides "created" state.
  repeated string started = 2;

  // Names of the groups that must not run, overrides all other states.
  repeated string destroyed = 3;
}

// Configuration for group states depending on the state of the system.
message GroupsStateConfiguration {
  // Condition for the system state under which the related group states should be executed by  Orchestrator.
  //
  // If omitted, the related groups states are always executed.
  Condition condition = 1;

  // Required. States of service bundle groups to be executed by Orchestrator if the condition  is true.
  GroupsStates groups_states = 2;
}

Yapılandırma durumları

Yapılandırma durumları (durumlar), bir hizmet örneğinin veya grubunun ne zaman başlatılacağını, durdurulacağını ya da imha edileceğini tanımlar ve conditions ile instances_states (paket yapılandırması) ve groups_states (sanal makine yapılandırması) öğelerinden oluşur.

Koşullar

Koşullar, modelin true olarak değerlendirildiğinde tanımlanan örnek durumunun uygulandığı bir boole koşuluna izin verir. Bir koşulun şu özellikleri vardır:

• Güç, araç ve özel mod gibi desteklenen sinyallere dayalı, rastgele karmaşık boole ifadesi (and veya not ifadeleriyle oluşturulur).

• (İsteğe bağlı) Koşul içermeyen yapılandırma durumu her zaman etkindir. Yani true olarak değerlendirilir.

Örnek durumları ve grup durumları

instances_states ve groups_states bu özelliklere sahiptir.

• Durumun active olduğu göz önünde bulundurulduğunda, düzenleme aracısının belirli örneklere veya gruplara uygulaması gereken durumları belirleyin.

• Gruba bir durum uygulandığında bu durum, gruptaki her hizmet paketi örneğine uygulanır. Örneklerin duruma getirilmesiyle ilgili herhangi bir sıra uygulanmaz.

Desteklenen eyaletler şunlardır:

• Service::on_start çağrıldıktan sonra started.

• created

  • Service::new çağrıldıktan sonra ancak Service::on_start çağrılmadan önce.

    VEYA

  • Service::on_stop çağrıldıktan sonra ancak Service::drop çağrılmadan önce.

• Service::drop çağrıldıktan sonra destroyed.

Kural grubu

Yapılandırma durumu, koşula bağlı olarak etkin veya etkin değil olabilir. Aynı anda birden fazla durum etkin olabilir. Bir düzenleme aracısı sinyal güncellemesi aldığında, hizmet paketlerinin yaşam döngüsü değiştirilmeden önce tüm yapılandırma durumları değerlendirilir. Hizmet örneği durumları, şu kurallara göre değerlendirilir:

• Etkin durumlardan hiçbiri hizmet örneği için geçerli olmadığında örnek yok edilir.

• Bir veya daha fazla etkin durum geçerli olduğunda şu öncelik uygulanır:

  1. destroyed mutlak önceliğe sahiptir.
  2. started, created üzerinde önceliğe sahiptir.

Proto şeması

Örnek bir proto şeması:

// A root boolean condition.
message Condition {
  // Required.
  oneof root {
    // VPM power state condition.
    string power_state = 1;
    // VPM vehicle state condition.
    string vehicle_state = 2;
    // Custom mode state condition.
    CustomState custom_state = 3;
    // Negation of a nested condition.
    Condition not = 4;
    // Logical 'and' between conditions grouped in expression.
    Expression and = 5;
    // Logical 'or' between conditions grouped in expression.
    Expression or = 6;
  }
}

// Representation of Custom state condition.
//
// Custom mode(s) are defined by the OEM and are not standardized by the platform, in contrast with
// VPM modes (i.e. power and vehicle mode).
message CustomState {
  // Custom mode being checked.
  string mode = 1;
  // State of the custom mode.
  string state = 2;
}

// A set of conditions united under an 'and' or 'or' expression.
//
// Evaluation type ('and' or 'or') depends on the field in [Condition]/[Expression], where the
// expression is being used.
//
// At least one value in at least one of the fields is required.
message Expression {
  // VPM power state condition.
  repeated string power_state = 1;
  // VPM vehicle state condition.
  repeated string vehicle_state = 2;
  // Custom mode state condition.
  repeated CustomState custom_state = 3;
  // Negation of a nested condition.
  repeated Condition not = 4;
  // Logical 'and' between conditions grouped in expression.
  repeated Expression and = 5;
  // Logical 'or' between conditions grouped in expression.
  repeated Expression or = 6;
}

Kilitlenme kurtarma ve yeniden başlatma stratejisi

Orchestrator, hizmet paketi kilitlenmelerini ve yaşam döngüsü geçiş hatalarını işlemek için güçlü bir mekanizma sağlar. Orchestrator, hizmet durumlarının bütünsel bir görünümüne sahip olduğundan ve mod geçişlerini yönettiğinden, yeniden başlatma ve yeniden deneme stratejisini yürütmek için en uygun bileşendir. Yaşam Döngüsü Yöneticisi (LM), bağlayıcı ölüm bildirimleri aracılığıyla hizmet paketi kilitlenmelerini Orchestrator'a bildirir. Orchestrator, LM'ye gereksiz bağlayıcı çağrıları yapmamak için her paketin son durumunu (başarılı olsun veya olmasın) önbelleğe alır ve bilinen son durum, istenen yeni durumla aynıysa geçişleri yeniden uygulamaz.

Yapılandırmayı yeniden dene

retry_mapping kullanarak Orchestrator yapılandırmanızda her örnek için yeniden başlatma ve yeniden deneme stratejisini tanımlayabilirsiniz. Yapılandırmada max_retries ayarlanmamışsa varsayılan değer, ro.boot.sdv.orchestrator.recovery.max_retries sistem özelliğinden alınır. Bu özellik ayarlanmazsa değer 0'a döner.

• max_retries: Geçici bir hata veya paket kilitlenme bildiriminden sonra Orchestrator'ın bir geçişi kaç kez yeniden deneyeceğini tanımlar. Yeniden deneme sayacı, başarılı bir işlemden sonra veya yeni bir mod işlendiğinde max_retries değerine sıfırlanır. Birden fazla eşleme aynı örneği hedefliyorsa en yüksek max_retries değerine sahip olan öncelikli olur.

Yapılandırma örneği

service_bundle_config {
  package_name: "oem.package"
  service_bundle_name: "OemApplication"
  instance: "fog_front_light"
  instance: "fog_rear_light"

  # Defines the restart configuration mapping for specific instances.
  retry_mapping {
    instance: "fog_front_light"
    instance: "fog_rear_light"
    retry_config {
      max_retries: 3
    }
  }
}

Kurtarma davranışı

Orchestrator'ın yeniden başlatma ve yeniden deneme mantığı, çeşitli hata senaryolarını sorunsuz bir şekilde yönetir:

• Normal çalışma sırasında kilitlenme: Bir hizmet paketi çalışırken kilitlenirse Orchestrator, yeniden başlatma stratejisini uygular ve kalan yeniden deneme sayısına göre paketi son istenen durumuna geri getirmeye çalışır.
• Mod geçişi sırasında kilitlenme: Bir paket, yeni bir modu zorunlu kılarken kilitlenirse yeniden başlatma isteği sıraya alınır ve daha sonra işlenir. İstek işlendikten sonra Orchestrator, örneğin son durumunu kontrol eder ve yalnızca örnek son istenen durumda değilse (son mod geçişinden itibaren) yeniden başlatma işlemini uygular.
• Kurtarma sırasında yeni mod: Orchestrator, bir paket yeniden başlatılırken (veya yeniden başlatılacak örnekler sırasındayken) yeni bir moda geçiş isteği alırsa devam eden kurtarma işlemini iptal eder. Yeni mod geçişi devralınır ve yeniden deneme sayacı, yeni hedef durum için yeni bir deneme grubu oluşturulmasına izin verecek şekilde sıfırlanır.

Orchestrator, yeniden deneme stratejisini belirlemek için Lifecycle Manager tarafından döndürülen farklı hata türlerini ayırt eder:

• Geçici hatalar (SERVICE_NOT_FOUND, OPERATION_FAILED, INTERNAL_ERROR): Orchestrator, herhangi bir özel temizleme işlemi yapmadan işlemi yeniden dener.
• Kalıcı hatalar (VALUE_CORRUPTED, INVALID_ARGUMENT): Orchestrator, hizmet paketinin bozuk durumda olabileceğini varsayar ve temiz bir yeniden başlatma sağlamak için işlemi yeniden denemeden önce hizmet örneğini sonlandırmaya çalışır.
• Kalıcı hatalar (PERMISSION_DENIED): İşlem yeniden denenmez ve paketin kurtarılamaz durumda olduğu kabul edilir.

Lifecycle Manager kilitlenirse tüm hizmet paketi işlemleri kaybolur. Gerçek durum bilinmediğinden Orchestrator her örneği geçersiz kılar ve her örneği son istenen duruma getirmek için kalan yeniden denemelerle bir yeniden başlatma stratejisi uygular.

Sürekli olarak kilitlenen veya başarısız olan paketler için sonsuz kurtarma döngülerini önlemek amacıyla, yeniden deneme sayacı yalnızca bir yaşam döngüsü işlemi başarılı olduktan sonra veya yeni bir mod geçişi istendiğinde max_retries değerine sıfırlanır. Bir paket, ardışık hatalar (ör. geçiş hatası ve ardından kilitlenme) nedeniyle yeniden deneme sayısını tüketirse yeniden deneme sayacı sıfırlanana kadar yeniden başlatılmaz.

Durum İzleyici'ye Durum Raporlama

Orchestrator, Health Monitor'ın (HM) kaydolduğu dahili bir bağlayıcı arayüzü sunar. Bu sayede HM, tüm hizmet paketlerinin durumuyla ilgili sürekli güncellemeler alabilir. Orchestrator, bu arayüz üzerinden her ikisini de etkin bir şekilde raporlar:

• Yaşam döngüsü durumu: Mevcut yapılandırmaya ve etkin modlara (başlatıldı, oluşturuldu veya yok edildi gibi) göre örneğin amaçlanan durumu.
• Kurtarma durumu: İstenen yaşam döngüsü durumuna ulaşma durumu. Örneğin, örneğin çalışır durumda olup olmadığını, bir hatadan sonra yeniden deneme aşamasında olup olmadığını veya tüm yeniden denemelerden sonra kurtarılamadığını gösterir.

Bu bilgiler, sinyal izleme için kaydolmamış olanlar da dahil olmak üzere tüm örnekler için raporlanır. HM, sanal makinenin durumunu bildirmek için API'lerini uygularken bu bilgileri kullanır. Daha fazla bilgiyi Sağlık izleme bölümünde bulabilirsiniz.

Örnekler

Bu bölümde, durumları koşullarla yapılandırmaya yönelik örnekler sunulmaktadır.

Temel hizmet örneği

• Koşulu yoktur ve bu nedenle her zaman etkindir.
• Tek bir hizmet örneği başlatır.

state {
  # Note: This state has no condition, hence its actions are valid throughout the lifetime of the program
  instances_states { started: "ServiceBundleName" }
}

HVAC uygulaması örneği

• Koşul: custom_state != occupancy.OCCUPANCY_EMPTY || custom_state == preheat.PREHEAT_ON olduğunda etkin.

• HVAC ile ilgili birden fazla hizmet örneğini started olarak tanımlar.

state {
  condition {
    or {
      # I.e. when the vehicle is occupied (for example, by _DRIVER / _NON_DRIVER / _PET)
      not {
        custom_state {
          mode: "occupancy"
          state: "OCCUPANCY_EMPTY"
        }
      }
      custom_state {
        mode: "preheat"
        state: "PREHEAT_ON"
      }
    }
  }

  # HVAC-related services
  instances_states {
    started: "HvacTemperatureCommand"
    started: "TempSensorDriverZone"
    started: "TempSensorPassengerZone"
    started: "RefrigerantLoop"
  }
}

Güç tasarrufu örneği

• Koşul: custom_state == system_power.SYSTEM_POWER_LOW && custom_state == range_ext.RANGE_EXT_ON olduğunda etkin.

  Bu durum, güç tasarrufu durumu olarak görülebilir.

• HVAC ile ilgili bir hizmet örneğini destroyed olarak tanımlar.

• Bu örnekte, SYSTEM_POWER_LOW ve RANGE_EXT_ON modları etkinken HVAC uygulaması RefrigerantLoop hizmet örneği olmadan çalışır:

  state {
    condition {
      and {
        custom_state {
          mode: "system_power"
          state: "SYSTEM_POWER_LOW"
        }
        custom_state {
          mode: "range_ext"
          state: "RANGE_EXT_ON"
        }
      }
    }
  
    # Disable services with high power consumption
    instances_states { destroyed: "RefrigerantLoop" }
  }
  

Gemide yaşam örneği

• Koşul: power_state == ON && vehicle_state == LIFE_ON_BOARD ise etkin.

  Bu durum, Arabada birisi var ve araba çalışıyor olarak görülebilir.

• Sıcaklık sensörlerinin çalıştığını bildirir.

• Araçta birisi olduğunda güvenlik nedeniyle sıcaklık gibi unsurlar izlenir.

state {
  condition {
    and {
      power_state: "ON"
      vehicle_state: "LIFE_ON_BOARD"
    }
  }

  # Temperature monitoring services
  instances_states {
    started: "TempSensorDriverZone"
    started: "TempSensorPassengerZone"
  }
}

Örnekler

Bu bölümde, aşağıdakileri içeren tam örnekler sunulmaktadır:

• İki örnek içeren bir hizmet paketi sunan hizmet paketi düzeyinde proto yapılandırması. Örneklerin her biri bir grubun parçasıdır.

• Modlara göre gruplarla etkileşim kurma mantığını sunan sanal makine düzeyinde bir proto yapılandırması

Hizmet paketi düzeyinde yapılandırma

# proto-file: //system/software_defined_vehicle/orchestration/distributed_config/src/protos/service_bundle_config.proto
# proto-message: ServiceBundleConfig

package_name: "oem.package"
service_bundle_name: "OemApplication"
instance: "fog_front_light"
instance: "fog_rear_light"
instance: "turn_signal_light"
custom_mode: "FOG"
custom_mode: "TURN"

group_mapping {
    group: "fog_light"
    instance: "fog_front_light"
    instance: "fog_rear_light"
}

group_mapping {
    group: "flasher_light"
    instance: "turn_signal_light"
}

state {
    condition {
        power_state: "ON"
    }

    instances_states {
        created: "turn_signal_light"
        destroyed: "fog_front_light"
        destroyed: "fog_rear_light"
    }
}

Sanal makine düzeyinde yapılandırma

# proto-file: //system/software_defined_vehicle/orchestration/distributed_config/src/protos/vm_config.proto
# proto-message: VmConfig

group_mapping {
    group: "lights"
    subgroup: "fog_light"
    subgroup: "flasher_light"
}

state {
    condition {
        custom_state {
            mode: "FOG"
            state: "ON"
        }
    }
    groups_states {
        started: "fog_light"
    }
}

state {
    condition {
        custom_state {
            mode: "TURN"
            state: "RIGHT"
        }
    }
    groups_states {
        started: "flasher_light"
    }
}

state {
    condition {
        vehicle_state: "SUSPEND_TO_RAM_ENTER"
    }
    groups_states {
        created: "lights"
    }
}

Paket yönetimi paralelliğini yapılandırma

ro.boot.sdv.max_bundles_management_threads sistem özelliği, hizmet paketi yaşam döngüsü işlemleri sırasında performansı ve kaynak tüketimini kontrol etmek için kullanılan önemli bir ayar parametresidir. Hizmet paketi işlemleri için maksimum paralellik düzeyini tanımlar ve iki temel hizmeti doğrudan etkiler:

1. Orchestration Engine: Bu hizmet, Orchestrator'ın Lifecycle Manager'a kaç eşzamanlı çağrı (ör. startService, stopService) yapabileceğini belirlemek için özelliği okur. Bu, birçok paketin aynı anda durum değiştirebileceği başlatma ve mod geçişleri sırasında performans açısından çok önemlidir.

2. Lifecycle Manager: Bu hizmet, gelen tüm istekleri işlemekten sorumlu olan Binder iş parçacığı havuzunun boyutunu hesaplamak için özelliğin değerini kullanır. Bu sayede LM, Orchestrator'dan gelen eşzamanlı istekleri işlemek için yeterli iş parçacığına sahip olur.

Bu özellik ayarlanmazsa her iki hizmet de varsayılan olarak 12 değerini alır.

Yapılandırma yöntemi

Özelliği, cihazınızın BoardConfig.mk dosyasına BOARD_BOOTCONFIG değişkenine ekleyerek ayarlayabilirsiniz. Bu sayede, cihaz her başlatıldığında değer uygulanır.

BOARD_BOOTCONFIG += \
    androidboot.sdv.max_bundles_management_threads=8

Cihazınızın değerini değiştirmek için uygun BoardConfig.mk dosyasındaki bu satırı değiştirin ve yeniden derleyin.

Başlatma süresi optimizasyonu

ro.sdv.orchestrator.state.ready, önyükleme zamanı performans optimizasyonu stratejisinin bir parçası olan write-once boole özelliğidir. Bu, Orchestration Agent'ın başlatma işlemini tamamladığını ve hizmet paketlerinin yaşam döngüsünü yönetmeye başlamaya hazır olduğunu gösterir. Temel amacı, diğer SDV aracılarının başlatma sırasını kontrol ederek Orchestrator'ın ve yönetilen hizmet paketlerinin başlatılmasına öncelik vermektir.

• Ayarlandığı yer: Düzenleme aracısı.
• Zaman: Başlatma sırası sırasında bir kez.
• Kullanım: Bu özellik, çoğu SDV aracısının (Güncelleme Yöneticisi, VSIDL sağlayıcısı, Sağlık İzleme, Hizmet Keşfi, Veri Tüneli, RPC, VPM ve Telemetri) başlatma sırasını kontrol etmek için başlatma sistemi tarafından kullanılır. Sistem, Orchestrator'ı erken başlatıp diğer temsilcilerin bu özelliği beklemesini sağlayarak Orchestrator'ın, sistem kaynakları için rekabet etmeden hizmet paketlerini başlatma gibi kritik görevine başlayabilmesini sağlar.

Performans

Sistem başlatılırken tüm aracıların aynı anda başlatılması, kaynak çakışmasına neden olarak genel başlatma sürecini yavaşlatabilir. Bu sorunu azaltmak için sistem özellikleri kullanılarak sıralı bir başlatma düzeni uygulanır:

1. Hizmet paketleri kayıt defteri: Tüm hizmet paketi meta verilerini yüklemek için ilk olarak bu hizmet başlatılır.
2. Yaşam Döngüsü Yöneticisi ve Düzenleyici: Bu temel aracılar, kayıt defteri hazır olur olmaz başlatılır. Bu erken başlangıç, Orchestrator'ın yapılandırmasını değerlendirmeye başlamasına ve hizmet paketlerini hemen başlatmaya hazırlanmasına olanak tanıdığı için çok önemlidir.
3. Diğer SDV temsilcileri: Yalnızca Orchestrator hazır olduktan sonra başlatılır.

Bu kontrollü sıra, Orchestrator'ın sistem kaynaklarını kullanarak hizmet paketlerini mümkün olan en kısa sürede başlatma önceliğine sahip olmasını sağlar. Bu da daha hızlı, daha belirgin ve daha verimli bir sistem başlatma süreci sağlar.

Orchestrator tarafından kullanılan modlar

Orkestrasyon aracısı, VPM tarafından iletilen araç ve güç modlarına etkin bir abonelik sürdürür. Orchestrator ile Araç ve Güç Yönetimi (VPM) sistemi arasında ilk bağlantı kurulduğunda Orchestrator, aşağıdaki boole sistem özelliklerini true olarak ayarlar:

• sdv.orchestrator.bootup.power_mode.ready

• sdv.orchestrator.bootup.vehicle_mode.ready

Yapılandırma dosyasını referans olarak kullanan düzenleme aracısı, alınan modların mevcut değerlerine göre çalışır durumda olması gereken hizmet paketleri grubunu dinamik olarak hesaplar. Ardından Orchestrator, yaşam döngüsü yöneticisiyle iletişim kurarak hizmet paketlerinin gerçek durumunu hesaplanan hedef durumla uyumlu hale getirmek için farklı komutlar verir.

Araç ve güç durumları

Araç modu ve güç yönetimi (VPM) aracısı, SDV bileşenlerinin aracın mevcut durumu hakkında bilgilendirilmesini sağlar. Bu durumlar arasında çalışma modu (ör. Park veya Sürüş) ve güç durumu (ör. Açık ve Askıya Alındı) yer alır. Orchestrator, Orchestrator yapılandırmasına göre hangi hizmet paketlerinin çalıştırılması gerektiğini belirlemek için bu değerleri değerlendirir. Daha fazla bilgi edinmek için Araç ve güç yönetimi başlıklı makaleyi inceleyin.

Özel modlar

Çok fazla araç modu olduğu için hepsini modelleyemiyoruz. Her OEM'nin farklı ihtiyaçları vardır ve araç modlarının standartlaştırılması tüm OEM kullanım alanlarını kapsayamaz. Bu nedenle, özel modlar olarak bilinen OEM'e özgü modları destekliyoruz. Bu modlar, mevcut araç ve güç modlarını genişletmez. Bunun yerine, yeni modlar tanımlamanın bir yolunu sunarlar.

İşlevsellik:

• Global kapsam: Özel modlar globaldir ve Orchestrator tarafından yönetilen tüm sanal makinelere eşit şekilde uygulanır.

• Oluşturma: Her özel mod değişikliği iki öğeden oluşur:

  • Ad: Özel modu temsil etmek için OEM tarafından seçilen benzersiz tanımlayıcı.

  • Değer: Özel modun mevcut durumu. Herhangi bir değer ayarlanmadığında UNDEFINED olabilir.

• Orchestrator rolü: Orchestrator, özel mod değerlerinin pasif bir alıcısı olarak görev yapar.

• Hizmet paketi rolü: Her hizmet paketi birden fazla özel moda sahip olabilir ve bunlardan herhangi birinde yeni değerler yayınlayabilir. Birden fazla hizmet paketi aynı özel moda sahip olabilir. Bu, özel bir modun farklı kaynaklardan yeni değerler alabileceği anlamına gelir.

• Doğrulama sorumluluğu: OEM'ler, geçerli durum geçişlerini sağlamaktan sorumludur. Orchestrator, yeni değerleri kabul eder.

Tahmini özellikler:

• Tahmini sayı: Güç ve araç modları, çoğu hizmet paketinin yaşam döngüsünü yönetir. Özel modlar ise tamamlayıcı bir rol oynar. Özel modların sayısının yüzlerce değil, onlarca olmasını bekliyoruz.

• Tahmini zamanlama: Modlar düzenli aralıklarla gönderilmez. Bunun yerine modlar, kapı açma, park etme işlemini başlatma, şarj döngüsünü başlatma ve OEM tarafından tanımlanan öneme sahip diğer benzer etkinlikler gibi belirli işlemlerle tetiklenen etkinliğe dayalı modlardır.

Özel mod tasarımı, belirli modları tanımlama ve yönetme esnekliği sağlarken Orchestrator'ın temel durum makinesi mantığından bağımsız kalmasına olanak tanır.

Desteklenen modlar

Hizmet paketlerinin yalnızca sahip oldukları özel modlarda yayınlanmasını sağlamak için her birinin, hizmet paketi kayıt defteriyle birlikte yerel sanal makinede bulunan Orchestrator yapılandırmasında sahip olunan özel modların listesini açıkça beyan etmesi gerekir. Bildirilmemiş bir özel modda yayınlama girişimleri yok sayılır.

Bir hizmet paketinin yayınlamasına izin verilen (ve dolayısıyla sahip olduğu) özel modları beyan etmek için service_bundle_config proto şeması aşağıdakilerle genişletilir:

// Service bundle configuration.
//
// Defines service bundle metadata, its instances, and configuration for instances
// lifecycle states depending on the state of the vehicle.
message ServiceBundleConfig {
      [...]

    // The list of custom modes that this service bundle publishes.
    repeated string custom_mode = 5;
}

Paketleri modlara göre yapılandırma

Mevcut Orchestrator proto yapılandırması (Condition bileşeni), özel modlara göre hizmet paketlerinin değiştirilmesini destekler:

message Condition {
  oneof root {
    string power_state = 1;
    string vehicle_state = 2;
    CustomState custom_state = 3;
    Condition not = 4;
    Expression and = 5;
    Expression or = 6;
  }
}

message CustomState {
  // Custom mode being checked.
  string mode = 1;
  // State of the custom mode.
  string state = 2;
}

Proto örneği

Aşağıdaki örnekte, bir hizmet paketinin örneklerinin TURN ve FOG durumuna göre başlatılacak şekilde nasıl yapılandırılacağı gösterilmektedir:

service_bundle_config {
package_name: "oem.package"
service_bundle_name: "OemApplication"
instance: "flasher_light"
// Service bundle is allowed to set values for the TURN mode
custom_mode: "TURN"
// Service bundle is allowed to set values for the FOG mode
custom_mode: "FOG"

state {
    condition {
        custom_state {
            mode: "TURN"
            state: "LEFT"
        }
    }
    instances_states {
        started: "flasher_light"
    }
}

state {
    condition {
        custom_state {
            mode: "FOG"
            state: "ON"
        }
    }
    // Group assumed to be defined containing all FOG lights instances.
    groups_states {
        started: "fog_lights"
    }
}

}

Yeni özel modlar ayarlama

Yeni bir özel mod değeri ayarlama işlemi, istenen değeri aynı sanal makinede çalışan yerel Orchestrator'a ileten hizmet paketiyle başlar. Ardından Orchestrator, hizmet paketinin belirtilen özel moda yayınlamak için gereken izinlere sahip olduğunu doğrular. Bu doğrulamayı, değeri diğer sanal makinelere yayması gerekip gerekmediğini belirlemek için .textproto içinde tanımlanan yapılandırmaya başvurarak yapar. Yayılma tamamlandıktan sonra her Orchestrator, durumunun değiştirilmesi gereken hizmet paketlerinin listesini bulmak için yapılandırmasını inceler.

RPC

Her sanal makinede çalışan her Orchestrator, yeni özel mod değerlerini dinlemek için bir RPC sunucusu oluşturur. Özel bir modu güncellemek isteyen her hizmet paketi, sunucuya bir RPC istemcisi oluşturmalıdır. Yetkisiz paketlerin sunucuya bağlanmasını önlemek için ACL'ler zorunlu kılınır.

RPC aracılığıyla yeni bir değer ayarlamak için proto tanımı aşağıdaki örneğe benzer:

syntax = "proto3";

import "google/protobuf/timestamp.proto";

package com.sdv.google.Orchestrator;

// Representation of the request used by service bundles to update a custom mode.
// Service bundles are permitted to update only the custom modes specifically designated
// for them within the Orchestrator configuration.
message SetCustomStateRequest {
  // Required.
  // The name of the custom mode.
  // The mode string can not be longer than 56 characters and can only contain
  // letters, numbers, dashes, dots and underscores: [a-zA-Z0-9_-.].
  // No other special character nor spaces should be present in the mode.
  string mode = 1;

  // Required.
  // The new value for the custom mode.
  // The value string can not be longer than 56 characters and can only contain
  // letters, numbers, dashes, dots and underscores: [a-zA-Z0-9_-.].
  // No other special character nor spaces should be present in the value.
  string value = 2;

  // Required.
  // The timestamp in which the new custom mode value was set. This is used to
  // prevent race conditions whenever different service bundles in different
  // VMs want to set a new value for the same custom mode.
  // We use this timestamp to order the requests and we promise eventual
  // consistency: while temporary inconsistencies may occur, the system will
  // eventually converges to the correct state.
  .google.protobuf.Timestamp timestamp = 3;
}

// Representation of the set custom state response.
message SetCustomStateResponse {}

// Orchestrator interface for service bundles that update the value of a
// custom mode.
// When a new value is received, it is propagated to Orchestrators running on
// other VMs.
service CustomStateService {
  // Updates the value for the custom mode.
  // Returns the error:
  // - PermissionDenied: the service is not authorized to update the custom mode.
  // - InvalidArgument: the provided mode and/or value are not valid.
  rpc SetCustomState(SetCustomStateRequest) returns (SetCustomStateResponse) {};
}

Güç geçişlerinin iptali

Orchestrator, SHUTDOWN_CANCELLED güç modu (VPM tarafından Orchestrator'a gönderilir) aracılığıyla devam eden güç geçişlerinin iptal edilmesine olanak tanır.

Örnek olarak aşağıdaki Orchestrator yapılandırmasını inceleyin:

state {
    condition {
        power_state: "SUSPEND_TO_RAM_ENTER"
    }
    instances_states {
        started: "instance-1"
        started: "instance-2"
        started: "instance-3"
    }
}

SHUTDOWN_CANCELLED modu alındığında, Orchestrator'ın davranışını iki ana senaryo belirler. Her iki durumda da SHUTDOWN_CANCELLED güç modu, sıranın sonuna eklenir. Ardından, sıraya alınan öğeler tüketildikten sonra SHUTDOWN_CANCELLED yürütülür.

1. senaryo: Devam eden mevcut mod bir güç modudur

Orchestrator bir güç modu güncellemesi yürütüyorsa devam eden modun iptal edilmesi istenir. Yaşam Döngüsü Yöneticisi, devam eden bir geçişin iptal edilmesini doğal olarak desteklemese de Orchestrator, yeni hizmet paketi isteklerinin başlatılmadığını doğrular.

Örnek: Önceki örnekteki yapılandırmada yer alan instance-1, SHUTDOWN_CANCELLED modu alındığında başlatma sürecindeyse instance-1 başlatma işlemini tamamlar. Ancak instance-2 ve instance-3, başlatıldı durumuna geçişlerini sürdürmez.

2. senaryo: İşleme sırasında bir güç modu var

Orchestrator, güç modu dışındaki bir güncellemeyi işlerken yürütülecek modlar sırasında bir güç isteği varsa güç geçişi sıradan kaldırılır. Bu, yürütülmesini engeller.

Örnek: Önceki örnekteki yapılandırmayı kullanarak, Orchestrator güçle ilgili olmayan bir güncelleme (ör. araç güncellemesi) üzerinde çalışıyorsa ve SUSPEND_TO_RAM_ENTER sıradaysa SHUTDOWN_CANCELLED almak, örneklerin (instance-1, instance-2, instance-3) hiçbirinin başlatılmamasına neden olur.

Uygulama örneği

RPC sunucusuna istemci oluşturmak için ara katman yazılımları tarafından oluşturulan kodu kullanmak isteyen bir istemcinin kataloğu aşağıdaki örneğe benzeyebilir:

# proto-file: //system/software_defined_vehicle/vsidl/language/src/protos/sdv/vsidl/v1/syntax.proto
# proto-message: VsidlEntry

package: "package_name"

service_bundle {
    name: "service_bundle_name"

    client {
        service: "com.android.sdv.orchestrator.CustomStateService"
    }
}

Kod oluştururken bağımlılığı Orchestrator kataloğuna eklemeniz gerekir:

--dependency-catalog-path orchestration/engine/stable/vsidl/*

Yeni bir değer göndermek için istemci kodu şöyle görünür:

let fqin = ServiceFqin::builder()
        .sdv_vm_name("vm_name")
        .sdv_package_name("package_name")
        .service_bundle_name("service_bundle_name")
        .service_instance_name("instance_name")
        .build()
        .unwrap();
let context_ref = ContextRef::create(fqin);
let comms = Arc::new(SdvComms { context: context_ref });
// service_bundle_name is the bundle generated with middleware code that defines
// the RPC client to "com.android.sdv.orchestrator.CustomStateService".
let client = service_bundle_name::new(comms).await.unwrap();
let rpc_client = client
        .create_rpc_client::<Client>(
            UnitName::builder()
                .vm_name(comms.context.get_self_fqin().get_sdv_vm_name())
                .package_name("com.android.sdv.orchestrator")
                .bundle_name("OrchestratorServiceBundle")
                .service_unit_name(Client::DEFAULT_UNIT_NAME)
                .build()
                .unwrap(),
            ClientOptions::default(),
        )
        .await;
let client = Arc::new(rpc_client.unwrap());
let request = SetCustomStateRequest {
mode: custom_mode_name,
value: custom_mode_value,
timestamp: MessageField::some(Timestamp::now()),
..Default::default()
};
let result = client.SetCustomState(&request).await;
// Process result

Hata ayıklama araçları

Orchestrator temsilcisi, dumpsys aracını destekler. Çalışan bir SDV örneğinde aşağıdaki komutu çalıştırarak bu aracı çağırabilirsiniz:

adb shell dumpsys com.google.sdv.ISdvAgent/orch

Orchestrator temsilcisinin dahili durumunda hata ayıklamak ve bu durumla ilgili bilgi edinmek için bu aracı kullanın. Bu işlem sonucunda şunlar gösterilir:

• Mevcut Mod Durumu: Etkin araç, güç ve özel modları görebilirsiniz.
• Özel Mod Yayıncıları: Hangi hizmetlerin özel mod yayınlayabileceğini (ve hangi modlara yayınlayabileceğini) belirleyin.
• Hizmet başına gerekli durum: Önceden tanımlanmış koşullara ve mevcut modlara göre her bir hizmet paketinin durumunu öğrenin. Bu sayede, bir hizmetin neden beklenen durumda olmayabileceğini teşhis edebilirsiniz.
• Mod Yaptırım Durumu: Devam eden zorunlu modun veya devam eden bir mod yoksa son zorunlu modun net bir resmini elde edin.
• Mod Yaptırım Sırası: Uygulanmayı bekleyen modları görüntüleyin.

Örneğin:

AGENT NAME: SDV Agent dump - Orchestrator
AGENT FQIN: instance1:com.android.sdv.orchestrator.OrchestratorServiceBundle/default
AGENT STATE: See orchestrator state below.
----------------
----------------
INTERNAL STATE REPORTERS:

*NAME: Configuration state
*REPORT:
Active modes:
MODE                          VALUE                         TIMESTAMP (scs, ns)
Power                         POWER_OFF_EXIT                -
Vehicle                       VEHICLE_ON                    -
Custom("CHARGING")            ON                            1750757590 (scs) 466507459 (ns)
Custom("TIRE_PRESSURE")       front-left                    1750757570 (scs) 554522995 (ns)

Modes allowed to publish by bundle (FQIN: modes):
com.android.sdv.sample.orchestration/CustomModeControlBundle: CHARGING, TIRE_PRESSURE

Requested state for instances:
STATE          FQIN
Started        com.android.sdv.sample.orchestration/CustomModeControlBundle/always-started-instance
Started        com.android.sdv.sample.orchestration/OrchestratedServiceBundle/my-instance
Started        com.sdv.oem.sample.diagnostics/DiagnosticsSampleWithDataItem/instance
Started        com.sdv.oem.sample.diagnostics/DiagnosticsSampleWithEvent/instance
Started        com.sdv.oem.user_preferences/UserPreferencesServiceBundle/default
----------------
*NAME: Engine state
*REPORT:
Last mode enforced was Custom("CHARGING") with value "ON"

Next modes to process: []
----------------

Orchestrator tarafından yönetilen ayrı hizmet paketleri hakkında daha fazla bilgi edinmek için Lifecycle Manager'daki mevcut dumpsys'i aşağıdaki gibi kullanın:

dumpsys google.sdv.lifecycle.ILifecycleManager/default

Böylece her hizmetin yaşam döngüsü durumu hakkında ayrıntılı bilgi edinebilirsiniz. Orchestrator dumpsys çıkışı ile Lifecycle Manager çıkışını birleştirerek sanal makinedeki hizmet paketleri yaşam döngüsünün tam bir resmini sunar.