Android Automotive应用（非Android Auto）测试模拟器及AOSP车载启动器测试问询

Hey there! Let’s tackle your two questions about Android Automotive (not Android Auto) testing—since you’re building a custom launcher on AOSP, I’ve got some practical, hands-on tips for you.

When it comes to testing non-Android Auto Automotive apps, these are the most reliable simulators to use:

• Android Studio’s Built-in Automotive Emulator: This is the go-to for most developers. Head to the SDK Manager in Android Studio, download an Automotive system image (either with Google Automotive Services or pure AOSP), and launch the emulator. It mimics the in-car UI layout, steering wheel controls, and even vehicle telemetry (like speed, fuel level) — perfect for validating your app’s core functionality without physical hardware.
• Custom AOSP Automotive Emulator: Since you’re building on AOSP, you can compile your own emulator image directly from the AOSP Automotive branch. This is ideal if you’ve modified system frameworks or services, as it matches your exact development environment. Just target a build variant like aosp_car_x86_64-userdebug during compilation, then launch it with the emulator command.
• OEM-Specific Simulators (Niche): Some car manufacturers offer their own simulators for their hardware ecosystems. These are useful if you’re targeting a specific brand’s infotainment system, but they’re less universal than the first two options. Stick with the above two unless you have a specific OEM requirement.

Testing a custom Automotive launcher on AOSP requires a mix of environment setup, functional validation, and edge-case testing. Here’s a step-by-step breakdown:

1. Set Up Your Test Environment First #

• Get your AOSP Automotive build running: Compile your custom AOSP Automotive system and deploy it to either the custom emulator mentioned above or a hardware development board. Verify that core car services (like car_service) are running via adb shell ps | grep car_service.
• Install your launcher APK: Use adb install your-launcher.apk to push the app to your test device. Double-check your manifest: you’ll need the android.permission.CAR_LAUNCHER permission and declare the android.intent.category.CAR_LAUNCHER category in your launcher activity — otherwise the system won’t recognize it as a valid home app.

2. Core Functional Testing #

• Launcher Priority & Default Behavior: Restart your test device. If your launcher doesn’t load by default, use adb shell cmd package set-home-activity com.your.package/.YourLauncherActivity to set it as the default home app. Test switching between launchers (if others are installed) to ensure smooth transitions.
• UI & Input Adaptation: Automotive screens are often wide/landscape, so test your layout across different in-car resolutions. Validate steering wheel controls (back, home, voice commands) to make sure they trigger the right actions in your launcher.
• System Integration: Test how your launcher interacts with core car features: does it display vehicle status (speed, battery) correctly? Can it launch built-in apps like media or navigation? Do system notifications (e.g., tire pressure alerts) appear properly in your launcher’s UI?

3. Advanced & Performance Testing #

• Cross-AOSP Version Compatibility: If you’re targeting multiple AOSP Automotive branches (e.g., Android 12 vs. 13 Automotive), test your launcher on emulators for each version to catch API compatibility issues.
• Performance Benchmarks: Launchers need to be snappy in cars. Use adb shell am start -W com.your.package/.YourLauncherActivity to measure cold/warm start times. Check frame rates with adb shell dumpsys gfxinfo com.your.package to ensure no jank during scrolling or transitions.
• Stability Testing: Run your launcher for extended periods, simulating daily use (frequent app switches, feature toggles). Monitor for crashes or ANRs using adb logcat or Android Studio’s Profiler, which also tracks memory and CPU usage to catch leaks.

4. Physical Hardware Testing (If Possible) #

Nothing beats testing on real hardware. If you have access to an Automotive reference device (like Google’s ARD) or an OEM development board, flash your custom AOSP build and test the launcher there. This lets you validate real-world interactions like touchscreen responsiveness, physical button feedback, and integration with actual vehicle sensors.

内容的提问来源于stack exchange，提问作者jitendra kumar