Android 車両アプリケーションの開発と分析 (11) - 車両 Android アプリケーション開発の入門ガイド

1. 序文 - モバイルインターネットの引き潮の下での自動車戦争

私が大学を卒業したばかりの2017年にさかのぼると、モバイルインターネットはすでに衰退し始めており、主要なトレーニング機関もすべてAndroid関連のトレーニングを停止しました.プログラムや多くのクロスプラットフォームフレームワークも、Android ネイティブ開発に対する市場の需要を年々減少させており、市場の需要の減少により、Android 開発に対する前例のない「量」のインタビューも作成されています。

2019年ついにインターネットから離れることを決意し、当時まだあまり熱くなかった車載Android分野に専念し、ネイティブAndroid開発に携わり続けました。そして今年、中国初の 100%外資の自動車製造プロジェクトである「上海テスラスーパーファクトリー」の建設が開始されました。

テスラのインテリジェンスとエレクトロニクスにおける大きな優位性は、スマートカーをまったく新しいレベルに押し上げました.高度な自動運転とBMSバッテリー管理システムは、世界中の人々に大きな衝撃を与えました.当時の中国の人々の目には、Tesla Laはほとんど新しいものと同義でした.エネルギー車. 今日、モデル Y とモデル 3 は、依然として新エネルギー車の分野で最も売れているモデルです。

ご存知のように、自動車産業は先進国の重要な経済柱であり、中国は世界最大の自動車生産と販売国であり、テスラの売れ行きはすぐにナマズ。、自動車業界はソフトウェア定義の自動車の時代に向かって進んでいます。Software-Defined Cars の核となる考え方は、人工知能をコアとするソフトウェア技術が自動車の未来を決定するというものであり、自動車分野におけるカーソフトウェアの重要性は、これまでにない高さに初めて引き上げられました。激しい自動車ソフトウェア技術戦争が上演されました。

2022.10.17 別の記事を更新、一部内容を削除しました参照：https://blog.csdn.net/linkwj/article/details/127398839

2. スマートカーコックピットの基本構造

車載用 Android アプリの開発に取り組む前に、自動車のコックピットの基本的な構造を大まかに理解する必要がありますが、自動車のコックピットは携帯電話とはまったく異なる構造であることを認識して初めて、より適切な開発が可能になります。今後の車載 Android アプリケーションについての学習にご協力ください。より主流の車載オペレーティングシステムアーキテクチャを紹介しましょう。

注: すべての車載オペレーティングシステムが次のアーキテクチャを使用しているわけではありません.たとえば、Tesla は Linux ベースのアーキテクチャを使用しています.

上記は、現在の主流の車のコックピットで採用されている技術アーキテクチャです. 上から下に紹介します.

T-BOX

TCU (Internet of Vehicles Control Unit) とも呼ばれる T-Box は、車に搭載されて車を制御および追跡する組み込みシステムを指し、車両情報対話システムのコアコンポーネントであり、ゲートウェイの役割を果たします。通常、GPSユニット、モバイル通信外部インターフェース電子処理ユニット、マイクロコントローラ、モバイル通信ユニット、メモリなどが含まれます。
車両の場合、T-Box は車両の障害監視、電源管理、リモートアップグレード、データ収集、スマート輸送などの機能を提供でき、車の所有者には、車両のリモートコントロールやセキュリティサービスなどの機能を提供できます。
T-BOX は周辺ハードウェアに属し、同じマザーボード上の中央制御および計装とは統合されていません。

SOC

SoC にはさまざまな定義があり、含意が豊富で適用範囲が広いため、正確な定義を与えることは困難です。一般に、SoC はシステムオンチップと呼ばれ、システムオンチップ (システムオンチップ) とも呼ばれます。これは、完全なシステムとすべてを含む製品、専用のターゲットを備えた集積回路であることを意味します。組み込みソフトウェアの内容。
自動車の SoC は、CPU と GPU を統合した最も一般的な携帯電話の SoC と非常によく似ています。現在、最も主流の自動車用SocはQualcommのSA8155で、これは携帯電話のSoc Snapdragon 855に基づいてQualcommによって開発されています。

MCU

シングルチップマイクロコンピューター (Single Chip Microcomputer) またはシングルチップマイクロコンピューターとも呼ばれるマイクロコントローラーユニット (MCU) は、中央処理装置 (Central Process Unit; 、カウンター (タイマー)、USB、A /D変換、UART、PLC、DMAなどの周辺インターフェース、液晶駆動回路まで1チップに集積したチップレベルコンピュータです。

通常、自動車のコックピットでは、SOC を統合するマザーボードに 1 つまたは複数の MCU も統合されます。

AutoSAR

Adaptive AutoSAR は、高度な自動運転に適したソフトウェアアーキテクチャプラットフォームであり、高性能コンピューティングと通信、柔軟なソフトウェア構成を提供し、アプリケーションの更新をサポートします。
Adaptive AutoSAR の主要なアーキテクチャは、ハードウェア層、ARA (AutoSAR Run-timeFor Adaptive real-time operating environment)、およびアプリケーション層に分かれています。
アプリケーション層に含まれるアプリケーションモジュール (AA) は ARA の上で実行され、各 AA は独立したプロセスとして実行されます。ARA は、Adaptive Platform に属する機能クラスタによって提供されるアプリケーションインターフェイスで構成されます。Adaptive プラットフォームは、Adaptive AutoSAR の基本機能と標準サービスを提供します。
各 AA は、他の AA へのサービスを開始できます。このアーキテクチャに基づいて、車両の機能を切り離すことができます。

ハイパーバイザー

基盤となる物理サーバーとオペレーティングシステムの間で実行される中間ソフトウェアレイヤー。複数のオペレーティングシステムとアプリケーションがハードウェアを共有できるようにします。VMM (仮想マシンモニター)、つまり仮想マシンモニターとも呼ばれます。
現在主流の車のコックピットでは、1 つの SoC で 2 つの異なるオペレーティングシステムが同時に実行されています. 1 つは車のダッシュボードを表示するための QNX システムで、もう 1 つは車載インフォテインメントのための Android システムです. 根底にある技術原理はハイパーバイザーです.

QNX

QNX は POSIX 仕様に準拠した商用の Unix ライクなリアルタイムオペレーティングシステムです. ターゲット市場は主に組み込みシステムです. 高い動作効率と高い信頼性が特徴です. この分野で 40 年近くの経験があります.自動車、鉄道輸送、航空宇宙など、高い安全性とリアルタイム性が要求される分野で使用されています。
QNX は、カーオペレーティングシステム市場で 75% 以上の市場シェアを持ち、エコロジーとコンテンツにもっと注意を払うカーエンターテイメントシステムで 60% 以上の市場シェアを持っています.安全性を重視するダッシュボードとドライバーアシスタンスの分野では、QNX の市場は、シェアはさらに高く、ほぼ100%に達しています。

2010 年、QNX は BlackBerry の親会社であるカナダの RIM Corporation に買収されました。

SOA

SOA（Service-Oriented Architecture）は、ビジネスとテクノロジーの分離を実現するだけでなく、ビジネスとテクノロジーの自由な組み合わせを実現する、ビジネス実装に基づく粗粒度で疎結合のサービス指向分散アーキテクチャです。
位置情報サービスを例にとると, 多くの車載アプリケーションは, 天気予報, 写真, ナビゲーションなどの位置情報を使用します. これらのアプリケーションはそれぞれのサービスに応じて異なるニーズを持ち, 位置情報を異なる方法で処理します. SOA はこの問題を非常にうまく解決できます.質問です。
SOAはもともとサーバー開発で使われていた技術で、現在は車載OSの分野でも使われていますが、現在のSOAの技術仕様はややこしく、国内外のホストメーカーでSOAの実装に違いがあります。
車両のオペレーティングシステムに SOA は必要ありません. 実際、これまでに発売されたモデルのほとんどは、SOA アーキテクチャを採用していないため、車両のオペレーティングシステムの今後の開発方向に過ぎません。

SAIC Zero Beam は 2021 年に、業界初の車載 SOA ソフトウェアアーキテクチャ仕様をリリースする最初の企業となります。WM Automotive Technology Group の子会社である W6 は、SOA を使用した国産初の量産車であると主張しています。

車載イーサネット

ビークルイーサネットは、イーサネットを使用して車両の電子ユニットを接続する新しいタイプのローカルエリアネットワーク技術です. 4 ペアの非シールドツイストペアケーブルを使用する従来のイーサネットとは異なり、ビークルイーサネットは 100Mbit/s を達成でき、1Gbit/s の伝送速度でも達成できますと同時に、高信頼性、低電磁放射、低消費電力、帯域幅割り当て、低遅延、および同期リアルタイム性能に対する自動車業界の要件を満たします。

車載用イーサネットは、車載環境におけるいくつかの特別なニーズを満たすように設計されています。たとえば、電気的特性 (EMI/RF) に関する車両機器の要件を満たす、高帯域幅、低遅延、オーディオとビデオの同期などのアプリケーションに関する車両機器の要件を満たす、ネットワーク管理のための車両システムのニーズを満たす、等したがって、民間イーサネットプロトコルに基づいて、車両イーサネットが物理インターフェイスの電気的特性を変更し、車両ネットワーク要件と組み合わせていくつかの新しい規格をカスタマイズしたことが理解できます。自動車用イーサネット規格については、IEEE 組織は、IEEE 802.1 および IEEE 802.3 規格に対応する補足と改訂も行いました。

できる

CANとは、Controller Area Network（CAN）の略で、自動車用電子製品の研究開発・製造で有名なドイツのBOSCH社が開発し、ついに国際規格（ISO11898）となりました。これは、世界で最も広く使用されているフィールドバスの 1 つです。北米と西ヨーロッパでは、CAN バスプロトコルが自動車用コンピュータ制御システムと組み込み産業用制御 LAN の標準バスになり、CAN を基盤とするプロトコルとして大型トラックと重機車両用に設計された J1939 プロトコルがあります。近年、その高い信頼性と優れたエラー検出能力が評価され、自動車のコンピュータ制御システムや産業環境など、周囲温度が厳しく、電磁放射が強く、振動が大きい環境で広く使用されています。
CAN は、車両オペレーティングシステムおよびアプリケーション開発で広く使用されています. 車両 Android のコアサービスの 1 つ - CarService は、基本的に、外部ハードウェア通信メッセージを上位層アプリケーションで認識できるデータに解析することです. ここでの通信メッセージは、通常、CAN メッセージです.

CAN 通信は自動車で広く使用されているため、Android プログラマーは CAN シミュレーションテストツールの使用法を習得する必要があり、場合によっては CAN メッセージを読み取って解析する必要さえあります。
なお、CANシミュレーションテストツールは非常に高価で、国産の代替品もありますが、ドイツのVictor社製の各種ツールやソフトウェアが今でも広く使われており、価格も数万から数十万と幅があります。

3D HMI 設計ツール & エンベデッドグラフィックスエンジン

オンボード SoC のコンピューティング能力の向上に伴い、最新のコックピットでは、アニメーションフィードバックをリアルタイムで生成できる 3D グラフィカルインターフェイスの導入がますます好まれ、インターフェイスの美学と使いやすさが大幅に向上しています。現在、車両開発における主流の 3D HMI 設計ツールおよびグラフィックスエンジンには、Unity 3d や Unreal (Unreal) などの昔ながらのゲーム開発ツールや、車載 HMI 設計およびグラフィックス表示専用の Kanzi が含まれています。

2016 年、フィンランドの自動車ソフトウェア会社 Rightware とその製品である Kanzi は、国内の自動車ソフトウェアプロバイダーである Thundersoft に買収されました。

以上、車のコックピットの基礎知識を紹介しました. Androidアプリプログラマーは、コックピット内で各種アプリケーションの制御や作成を担当しています. 次に、車載アプリとインターネットアプリの違いについて紹介します.

3. 車両アプリケーション開発

最終的な分析では、カー Android アプリケーションは、ユーザーとやり取りする HMI アプリケーションや、HMI なしでバックグラウンドで実行されるサービスアプリケーションなど、一連のシステムレベルのアプリケーションをカー Android システムに埋め込むことです。

一般的に言えば、車載アプリケーションの複雑さは、一般的なインターネットアプリケーションの複雑さよりも低くなります。

HMI を使用した一般的な車両アプリケーションには、車両エアコン、マルチメディアアプリケーション、デスクトップ、SystemUI、システム設定、自動車制御デバイス、Bluetooth 電話、および一部のサードパーティアプリケーションが含まれます。

HMI のないアプリケーションには、CarService、AudioService、AccountService などがあります。車載アプリケーションの開発では、多数のサービスをカスタマイズする必要があり、アプリケーション開発のワークロードの比較的大きな部分でもあります。

3.1 システムレベルのアプリケーションと一般的なアプリケーションの違い

システムアプリを実行するには Android ROM に埋め込む必要があります. 通常のアプリも ROM に埋め込むことができますが, システムアプリは Android SDK の内部 API を呼び出すことができます.これは通常のアプリでは実行できません. システムアプリは一般的に次のような特徴があります.

Android SDK 内の API にアクセスできます
動的許可を申請する必要はありません
構成可能な自動開始
アプリに署名する必要があります

次に、実際にシステムレベルのアプリケーションを手動で作成します。

3.2 システムレベルのアプリケーションを書く

Android システムアプリケーションの作成は、基本的には通常の Android アプリケーションと同じで、最初に AndroidStudio でデモを作成し、空の Activity と Application のみが必要です。

public class DemoApp extends Application {

    private Handler handler;

    @Override
    public void onCreate() {
        super.onCreate();
        Log.e("TAG", "onCreate: start");
        handler = new Handler(Looper.getMainLooper());
        handler.postDelayed(new Runnable() {
            @Override
            public void run() {
                showView();
            }
        },5000);
    }

    private void showView(){
        WindowManager manager = getSystemService(WindowManager.class);
        View view = new View(this);
        WindowManager.LayoutParams params = new WindowManager.LayoutParams(WindowManager.LayoutParams.MATCH_PARENT,WindowManager.LayoutParams.MATCH_PARENT);
        params.type = WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY;
        manager.addView(view,params);
    }
}

上記のアプリケーションロジックは非常に単純で、アプリが起動してから 5 秒後にフルスクリーンウィンドウがポップアップします。

次に、アプリを AndroidManifest.xml に登録します。

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.car"
    android:sharedUserId="android.uid.system">

    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:persistent="true"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/Theme.First">

        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

</manifest>

上記のソースコードでは、通常のアプリケーションでは使用されない 2 つのプロパティに注意する必要があります。それは、他のアプリケーションと共有される Linux ユーザー ID の名前です。デフォルトでは、Android は各アプリケーションに固有のユーザー ID を割り当てます。ただし、2 つ以上のアプリでこのプロパティを同じ値に設定すると、それらのアプリが同じ証明書セットを持っていれば、同じ ID が共有されます。同じユーザー ID を持つアプリは、互いのデータにアクセスでき、必要に応じて同じプロセスで実行できます。システムアプリケーションを開発する場合、この項目は設定する必要はありません。として構成すると、アプリケーションはシステムユーザーになり、システムユーザーのみがアクセスできるいくつかのスペースにアクセスできます。
android:sharedUserId

android.uid.system

android:persistent
アプリケーションを常に実行し続けるかどうかを構成します。デフォルトは false です。true に設定すると、アプリケーションはブートブロードキャストが送信される前に自動的に起動し、アプリケーションが強制終了された直後に再起動します。
システムアプリケーションを開発する場合、この項目は設定する必要はありません。

3.3 テストシステムの適用

3.3.1 テスト環境の準備

システムアプリのテストの方が面倒手元に開発ボードがないのでエミュレータベースでしかテストできないので、Androidソースコードをダウンロードし、Androidソースコード環境を利用してAPKをコンパイルする必要があるシステム署名付き。
Android ソースコードをダウンロードしてコンパイルするには、以下を参照してください。Android Automotive アプリケーションの開発と分析 (1) - Android Automotive の概要とコンパイル
Android ソースコードをコンパイルした後、ソースコードのコンパイル済みの FirstCarApp 部分を /aosp/ にコピーします。 packages/apps/Car/,
Android ソースコード環境に基づくアプリプロジェクトの構造は、Gradle に基づく AndroidStudio プロジェクトの構造とはまったく異なります. ディレクトリ構造は次のとおりです。

src ディレクトリの androids studio プロジェクト構造に main/java がないことに注意する必要がありますが、
このネイティブベースの記述方法は一般的ではありません。実際の開発では、Android Studio で開発を完了し、ソースコードを gerrit に送信します。Jenkins は、その後のコンパイル、署名、およびコピーのプロセスを完了するのに役立ちます。

3.3.2 アプリケーションのコンパイルと実行

Android アプリケーションをソースコード環境でコンパイルするには、Android.bp または Android.mk スクリプトを記述する必要があります.Android.bp または Android.mk がわからない場合は、Android.mk 入門ガイド | Android.mk を参照してください。Android.bp 入門チュートリアル

このテストで使用した Android.bp スクリプトは次のとおりです。

package {
    default_applicable_licenses: ["Android-Apache-2.0"],
}

android_app {
    name: "CarFirstApp",
    srcs: ["src/**/*.java"],
    resource_dirs: ["res"],
    platform_apis: true,
    certificate: "platform",
    privileged: true,
    static_libs: [
    "androidx.appcompat_appcompat",
    "com.google.android.material_material",
    ],
    optimize: {
        enabled: false,
    },
    dex_preopt: {
        enabled: false,
    },
    product_variables: {
        pdk: {
            enabled: false,
        },
    },
}

次に、Android ソースコードを 1 回コンパイルします。

# 编译Android源码
/aosp$ source build/envsetup.sh 
/aosp$ lunch 12
/aosp$ make -j 32
/aosp$ emulator -writable-system -netdelay none -netspeed full

通常、エミュレータコマンドを直接使用してコンパイル済みのエミュレータを起動できますが、この時点では、エミュレータのファイルシステムはまだ読み取り専用モードであり、 -writable-system - を追加することにより、再マウントコマンドを実行できません。 netdelay none - netspeed がフルです。remount コマンドは通常どおり使用できます。

/aosp$ adb root
/aosp$ adb remount
/aosp$ adb shell reboot

エミュレーターの再起動後、引き続き CarFristApp の apk をコンパイルします。

link@link-PC:/aosp$ make CarFirstApp
...
## 编译后输出的apk路径
============================================
[100% 4/4] Install: out/target/product/generic_car_x86/system/priv-app/CarFirstApp/CarFirstApp.apk

#### build completed successfully (2 seconds) ####

次に、adb コマンドを使用してエミュレーターに CarFristApp ディレクトリを作成し、コンパイルされた apk を system/priv-app/CarFristApp/ ディレクトリにプッシュします。

/CarFirstApp$ adb root
/CarFirstApp$ adb remount
# 创建目录
/CarFirstApp$ adb shell mkdir /system/priv-app/CarFirstApp
/CarFirstApp$ adb push CarFirstApp.apk /system/priv-app/CarFirstApp
# 重启
/CarFirstApp$ adb shell reboot

エミュレーターが再起動するのを待った後、アプリが自動的に起動し、WindowView がポップアップして画面を覆うことがわかります。気がついたかどうかはわかりませんが、自動起動なのか、画面を覆うウィンドウがポップアップするのか、許可を申請するウィンドウがありません.これは、システムレベルのアプリケーションの重要な機能です.

In the above operation, we choose to push the apk to priv-app. さらに、Android アプリケーションには次のインストールパスもあり、実際のニーズに応じて異なるディレクトリにインストールできます。このパスには、Setting、systemUI など、いくつかの基本的なシステムアプリケーションが格納されます。このディレクトリ内のアプリにはより高いシステム権限があり、それを使用する場合は、アプリを priv-app ディレクトリに配置する必要があります。
/system/priv-app
android:protectionLevel=signatureOrSystem

/system/app
このディレクトリに保存されているシステムアプリの権限は比較的低く、ルート権限があれば、これらのアプリをアンインストールできます。

/vendor/app
このディレクトリには、ベンダーメーカーのアプリが格納されます

/data/app
ユーザーがインストールしたサードパーティ製アプリ

3.4 車載アプリケーションの難しさ

車両アプリケーションの開発プロセスでは、次のような問題に遭遇することがよくあります。

デバッグに手間と時間がかかる
車載アプリ開発は実は難しくないのに面倒くさい！特にデバッグは、携帯電話アプリ開発とは異なり、車載アプリの動作環境はAOSPをベースにカスタマイズされており、無数のバグが発生することがほとんどで、システム下部のバグが上位アプリに反映されることもありますが、これにはアプリケーションの開発が必要です。作成者は、このバグの原因を正確に特定できなければなりません。
複雑な UI
今日の車載アプリケーションは、複雑でクールなインタラクティブ UI を備えていますが、車載 Android と QNX は SoC とメモリを共有しているため、ほとんどの場合、システムリソースは主流の携帯電話よりもはるかに劣っています。開発者にとって、複雑で高性能な一連の HMI を実装することは、多くの場合非常に困難です。
システム API の理解が不十分
車載アプリケーションの開発では、ほとんどの場合、システム設定など、元のシステムの既存のアプリケーションを再カスタマイズする必要があります。これには、開発者がネイティブアプリケーションの動作モードとそれらが呼び出す API についてある程度理解している必要があります。

4. 車載 Android 開発の展望

上記の内容をお読みいただければ、車載 Android の開発に関する基本的な理解はできたと思います。車の Android 開発に切り替えるようにアドバイスしていると思いますか? 答えはいいえだ！

単純な Android アプリケーションエンジニアが担当できるのは、車両のコックピット内の非常に小さな技術分野だけであり、この職業の発展の高さをすでに決定しています. この天井を破るには、その最下層に深く入り込む必要があります. Android システムとフレームワーク、HAL、さらにはネイティブのいくつかの動作原理をマスターします。さらに、Linux および自動車関連の知識も追加の学習が必要です。

現時点では、車載 Android の開発はまだ有望ですが、モバイルインターネットの普及にはほど遠い状態であり、将来的には達成されない可能性さえあります。、そして需要と供給の関係の変化により、いつか必然的に下り坂になります。

モバイルアプリの開発に比べて学ばなければならない知識が多すぎて複雑で、デバッグプロセスもモバイルアプリの開発よりも複雑で、車載開発に参入したことを後悔したことがありますが、この人生を後悔して過ごしませんか?

参考文献

スマートコックピット: インテリジェントな基本プラットフォームとアーキテクチャ (その 2)
2020 年の中国の T-BOX 業界の現状分析、乗用車用 T-Box の組立率は急速に増加している "図"車両オペレーティングシステム (3):最初の
インテリジェントコックピットオペレーティングシステム
 高度なスマートコックピットによって構築された統合 HMI ツール—Kanzi One がリリースされました
 Automotive | Android オープンソースプロジェクト | Android オープンソースプロジェクト
 Automotive Ethernet - 電子ペーパー