Übersicht

Die Autoeinstellungen (packages/apps/Car/Settings) werden speziell für das Android Automotive OS (AAOS): Autoeinstellungen unterscheiden sich von Telefoneinstellungen (packages/apps/Settings) In den Autoeinstellungen finden Sie zwar bekannte Telefoneinstellungen, Die Autoeinstellungen bieten eine visuelle Benutzeroberfläche für Autos, Optimierungen der Ablenkung des Fahrers und zahlreiche Anpassungsmöglichkeiten für OEMs.

Sehen Sie sich zusätzlich zur unten angegebenen Übersicht über die Autoeinstellungen die zugehörigen Weitere Informationen zu den Autoeinstellungen:

• Autoeinstellungen hinzufügen
• Autoeinstellungen neu anordnen
• Ablenkungsoptimierung in den Autoeinstellungen
• Suchindexierung der Autoeinstellungen
• Dual Pane anpassen

Architektur und Richtlinien

Die meisten Seiten in den Autoeinstellungen sind als eine Reihe von Fragmenten implementiert. die SettingsFragment erweitern, wobei für jede eine eigene Aktivität definiert ist in CarSettingActivities Diese statischen Aktivitäten sind eine Erweiterung von BaseCarSettingsActivity. Es gibt jedoch einige Ausnahmen von dieser Regel, z. B. einige spezielle Fragmente, die sich BaseFragment statt SettingsFragment und einige Aktivitäten außerhalb von CarSettingActivities, die alle als Ausnahmen und nicht als zu verfolgende Muster betrachtet werden sollten.

Statische Einstellungen

Eine statische Einstellung wird in XML mithilfe der Preference-Klasse definiert. oder CarUiPreference Tag. Eine SettingsFragment-Implementierung verwendet die getPreferenceScreenResId() -Methode zu definieren, welche XML-Datei die statische Liste der anzuzeigenden Einstellungen enthält.

Dynamische Einstellungen

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

Innerhalb der CarSettings-App stellen dynamische Einstellungen einen normalen Satz von die den Nutzer auf zusätzliche Seiten in CarSettings leiten, die über die Einstellungen Controller anstelle des XML-Codes. Ein Beispiel hierfür ist das Tool „Tastaturen verwalten“, unter Sprachen und Eingabeeinstellung, die dynamisch Eingaben hinzufügt zur Einstellungsseite hinzu, je nachdem, ob diese Eingabemethoden ob sie zulässig sind oder nicht.

Aktionsleisten

Auf jedem Einstellungsbildschirm befindet sich oben eine Aktionsleiste, die einen "Zurück" Navigation, Bildschirmtitel und ergänzende Aktions-Widgets (z. B. Tasten und Schaltern). Diese Aktionsleisten ähneln der ActionBar. die von Android bereitgestellt werden, sondern sind benutzerdefinierte Ansichten. Unter Android 11 und höher ist im Layout des Gehäuses enthalten, das die Ansichten für die Symbolleiste und ein Frame-Layout für den Rest des App-Inhalts.

Ergänzende Aktions-Widgets sind MenuItem-Klassen und sollten in den onCreate der entsprechenden SettingsFragment oder BaseFragment Eigenschaften wie Sichtbarkeit, Status usw. sollten von Settern in der Geschäftslogik des 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 Aktionsleisten unterstützen Ablenkungsoptimierung in den Autoeinstellungen Lege bei der Erstellung in der MenuItem.Builder die UXRestrictions-Einstellungen fest.

Bevorzugte Controller

Jede Einstellungsseite kann verschiedene Einstellungen:

In der folgenden Abbildung sehen Sie, wie diese Komponenten zusammenhängen:

Abbildung 1. CarSettings-Komponenten

Die PreferenceController ist eine Lebenszykluskomponente berücksichtigt, die bei der die Geschäftslogik für bestimmte Präferenzen zu kapseln. PreferenceControllers kann nur mit der entsprechenden Einstellung über XML.

// 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>

Die Autoeinstellungen verhindern ausdrücklich das Erstellen von PreferenceController um die Einstellungshierarchie mit minimalen Änderungen am Java-Code vornehmen.

Es ist möglich, dass für PreferenceController dynamische Daten erforderlich sind. um ordnungsgemäß zu funktionieren. Beispiel: Eine PreferenceController, die Benachrichtigungen für eine App müssen wissen, auf welche App sie reagieren soll. Da PreferenceControllers immer in XML definiert sind, gibt es keine zusätzliche Konstruktorargumente bereitzustellen. Stattdessen werden diese zusätzlichen Werte werden über öffentliche Setter in der PreferenceController bereitgestellt und mithilfe der use(...)-Methode aus SettingsFragment.

// 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, die Daten das ursprüngliche Ziel, die Einstellungshierarchie mit minimalen Änderungen des Java-Codes, da große Abschnitte des vorhandenen Fragmentcodes in das neu erstellte Fragment. Eine Möglichkeit, dies zu minimieren, ist Folgendes:

• Nutzung von use(...) minimieren.
• Versuchen Sie, jeden Aufruf von use(...) an einer Stelle im Fragment zu belassen beispielsweise in der Methode onAttach().

Intent-Verarbeitung

Alle Intents die von der App „Auto-Einstellungen“ verwaltet werden sollen, sind in den Manifest -Datei. Intents werden im Allgemeinen wie die meisten Android-Standard-Apps definiert und mit allen im Manifest definierten Aktivitäten und Intent-Filtern.

Stammfragment ändern

Bei Bedarf kann das Exit-Symbol mit config_show_settings_root_exit_icon ein- oder ausgeblendet werden.

Design anpassen

Andere Attribute und Ressourcen anpassen

Die App „Autoeinstellungen“ verwendet hauptsächlich CarSettingTheme, Dies ist eine Erweiterung von Theme.CarUi. Mit diesem Thema wird die Design von System-Apps, um Einheitlichkeit im System zu gewährleisten.

<ph type="x-smartling-placeholder">

Einstellungen anpassen

Das Anpassen der Einstellungen umfasst folgende zusätzliche Bereiche:

• Das Layout einiger grundlegender Präferenzklassen ist in car_preference definiert und überlagert für Autobauten. Alle Anpassungslayouts für die grundlegenden Präferenzklassen können ersetzt werden.
• In den Autoeinstellungen werden einige benutzerdefinierte Einstellungen verwendet, die hauptsächlich in den common Paket. Diese sollten im Modul „Autoeinstellungen“ getrennt von die Basispräferenzklassen.