Übersicht

Die Einstellungen für das Auto (packages/apps/Car/Settings) sind speziell für Android Automotive OS (AAOS) vorgesehen. Die Einstellungen für das Auto unterscheiden sich von den Einstellungen für das Smartphone (packages/apps/Settings). Die Einstellungen für das Auto enthalten einige bekannte Smartphone-Einstellungen, aber auch eine für das Auto optimierte visuelle Benutzeroberfläche, Optimierungen für die Ablenkung des Fahrers und zahlreiche Anpassungspunkte für OEMs.

Zusätzlich zur Übersicht über die Einstellungen für Ihr Auto finden Sie hier weitere Informationen zu den Einstellungen für Ihr Auto:

Architektur und Richtlinien

Die meisten Seiten in den Einstellungen für das Auto sind als Reihe von Fragmenten implementiert, die SettingsFragment erweitern. Jedes hat eine eigene Aktivität, die in CarSettingActivities definiert ist. Diese statischen Aktivitäten werden von BaseCarSettingsActivity erweitert. Es gibt einige Ausnahmen von dieser Regel, z. B. einige spezielle Fragmente, die BaseFragment statt SettingsFragment erweitern, und einige Aktivitäten, die sich außerhalb von CarSettingActivities befinden. Diese sollten jedoch als Ausnahmen und nicht als Muster betrachtet werden.

Statische Einstellungen

Eine statische Einstellung wird in XML mit dem Tag Preference oder CarUiPreference definiert. Bei einer SettingsFragment-Implementierung wird mit der Methode getPreferenceScreenResId() definiert, welche XML-Datei die statische Liste der anzuzeigenden Einstellungen enthält.

Dynamische Einstellungen

Für dynamische Einstellungen wird das PreferenceGroup-Tag oder eine Implementierung von PreferenceGroup verwendet.

In der CarSettings App stellen dynamische Einstellungen eine normale Reihe von Einstellungen dar, die den Nutzer zu zusätzlichen Seiten in CarSettings weiterleiten, aber über den Preference Controller und nicht in der XML-Datei hinzugefügt wurden. Ein Beispiel ist die Einstellung „Tastaturen verwalten“ unter „Sprachen und Eingabe“. Auf der Seite mit den Einstellungen werden Eingabemethoden dynamisch hinzugefügt, je nachdem, ob diese Eingabemethoden zulässig sind oder nicht.

Aktionsleisten

Oben auf jedem Einstellungsbildschirm befindet sich eine Aktionsleiste, die eine Schaltfläche „Zurück“, einen Bildschirmtitel und zusätzliche Aktions-Widgets (z. B. Schaltflächen und Schalter) enthalten kann. Diese Aktionsbalken ähneln der von Android bereitgestellten ActionBar, sind aber benutzerdefinierte Ansichten. Unter Android 11 und höher ist diese Symbolleiste im Chassis-Basislayout enthalten, das die Ansichten für die Symbolleiste und ein Frame-Layout für den Rest der App-Inhalte enthält.

Widgets für zusätzliche Aktionen sind MenuItem-Klassen und sollten in der onCreate der jeweiligen SettingsFragment oder BaseFragment erstellt werden. Eigenschaften wie Sichtbarkeit und Status sollten über Setter in der Geschäftslogik der SettingsFragment gesteuert werden.

// ExampleSettingsFragment.java
public class ExampleSettingsFragment extends SettingsFragment {

    @Override
    protected List<MenuItem> getToolbarMenuItems() {
        return Collections.singletonList(mClearConfirmButton);
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mButton = new MenuItem.Builder(getContext())
                .setTitle(R.string.text)
                .setOnClickListener(mOnClickListener)
                .setUxRestrictions(CarUxRestrictions.UX_RESTRICTIONS_NO_SETUP)
                .build();
    }

    private void updateState() {
        button.setVisible(false);
    }
}

Die Aktionsbalken unterstützen die Optimierung für Ablenkungen in den Autoeinstellungen. Legen Sie die UX-Einschränkungen bei der Erstellung in MenuItem.Builder fest.

Einstellungscontroller

Jede Seite mit Einstellungen kann verschiedene Einstellungen enthalten.

Die folgende Abbildung zeigt die Beziehung dieser Komponenten:

CarSettings-Komponenten

Abbildung 1. CarSettings-Komponenten

Die PreferenceController ist eine sitzungsspezifische Komponente, mit der sich die Geschäftslogik für bestimmte Einstellungen kapseln lässt. PreferenceControllers kann nur über XML an die entsprechende Präferenz angehängt werden.

// example_settings_fragment.xml
<PreferenceScreen
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:settings="http://schemas.android.com/apk/res-auto"
    android:title="@string/example_settings_title">
  <Preference
    android:key="@string/pk_example_preference_key"
    android:title="@string/example_preference_title"
    settings:controller="com.android.car.settings.example.ExamplePreferenceController"/>
</PreferenceScreen>

In den Einstellungen für Autos wird das Erstellen von PreferenceController durch Code ausdrücklich verhindert, um die Änderung der Einstellungenhierarchie mit minimalen Änderungen am Java-Code zu erleichtern.

Möglicherweise benötigt ein PreferenceController dynamische Daten, um richtig zu funktionieren. Beispielsweise muss ein PreferenceController, das Benachrichtigungen für eine App deaktiviert, wissen, für welche App es eine Aktion ausführen soll. Da PreferenceControllers immer in XML definiert sind, können keine zusätzlichen Konstruktorargumente angegeben werden. Stattdessen werden diese zusätzlichen Werte über öffentliche Setter für PreferenceController bereitgestellt und mit der Methode use(...) von SettingsFragment festgelegt.

// ExamplePreferenceController.java
public class ExamplePreferenceContorller extends PreferenceController<Preference> {

  private ExampleArg mExampleArg;

  public ExamplePreferenceController(...) {
    ...
  }

  public void setExampleArg(ExampleArg exampleArg) {
    mExampleArg = exampleArg;
  }
}

// ExampleSettingsFragment.java
public class ExampleSettingsFragment extends SettingsFragment {

  @Override
  @XmlRes
  protected int getPreferenceScreenResId() {
    Return R.xml.example_settings_fragment;
  }

  @Override
  public void onAttach(Context context) {
    ExampleArg arg = (ExampleArg) getArguments().getSerializeable(ARG_KEY);
    ExamplePreferenceController controller =
        use(ExamplePreferenceController.class, R.string.pk_example_preference_key);
    controller.setExampleArg(arg);
  }
}

Je häufiger die Methode use(...) verwendet wird, desto schwieriger wird es, das ursprüngliche Ziel zu erreichen, die Einstellungenhierarchie mit minimalen Änderungen am Java-Code neu anzuordnen, da große Teile des vorhandenen Fragmentcodes in das neu erstellte Fragment kopiert werden müssen. So können Sie die Herausforderung minimieren:

  • Minimieren Sie die Nutzung von use(...).
  • Versuchen Sie, jeden Aufruf von use(...) an einer Stelle im Fragment zu platzieren (z. B. in der Methode onAttach()).

Intent-Verarbeitung

Alle Intents, die von der App „Einstellungen für das Auto“ verarbeitet werden sollen, sind in der Manifestdatei definiert. Intents werden im Allgemeinen wie die meisten Standard-Android-Apps definiert und verarbeitet. Alle Aktivitäten und Intent-Filter sind im Manifest definiert.

Stammfragment ändern

Das Symbol „Schließen“ kann mit config_show_settings_root_exit_icon ein- oder ausgeblendet werden.

Design anpassen

Andere Attribute und Ressourcen anpassen

In der App „Einstellungen für das Auto“ wird hauptsächlich die CarSettingTheme verwendet, die eine Erweiterung der Theme.CarUi ist. Mit diesem Design wird das Erscheinungsbild von System-Apps standardisiert, um für Einheitlichkeit im System zu sorgen.

Einstellungen anpassen

Die Einstellungen können für folgende zusätzliche Standorte angepasst werden:

  • Das Layout einiger Basiseinstellungsklassen wird in car_preference definiert und für Builds für Autos überlagert. Alle Anpassungslayouts für die Basiseinstellungsklassen können hier ersetzt werden.
  • Für die Einstellungen für das Auto werden einige benutzerdefinierte Einstellungen verwendet, die hauptsächlich im Paket common definiert sind. Sie sollten im Modul „Autoeinstellungen“ separat von den Basiseinstellungen angezeigt werden.