Design and Optimization Practices for In‑Car Android App Development

With the rapid rise of new‑energy vehicle manufacturers, automotive intelligence has become a hot trend. Many mobile applications, including NetEase Cloud Music and its Look live‑streaming feature, are exploring car‑head‑unit (HU) scenarios. This article shares the author's experiences and insights gained during that process.

Current Car‑Head‑Unit Development Types and Characteristics

There are three main ways to integrate an app into a car:

Phone‑app extension (e.g., Huawei HiCar) – the mobile app uses the HiCar SDK and runs on the phone while the HU renders the UI.

OpenAPI – the car manufacturer calls server‑side APIs provided by the app vendor.

Independent HU app – a standalone app installed directly on the car’s system, which is the most common approach today.

1. Phone‑App Extension (Huawei HiCar Example)

This method does not require a separate HU APK. The phone app integrates the HiCar SDK and relies on Android’s MediaSession framework for data templating and UI rendering on the HU. Developers only need to supply media data; the HU handles screen adaptation and UI consistency.

The Media Data Tree must be defined by the developer. Playback events are delivered via onPlayFromMediaId with a mediaId that can encode a hierarchy such as tab → page → listId → songId , following the pattern used in Android’s Universal Android Music Player sample.

Key characteristics of this integration:

Easy to adopt – development stays within the existing mobile project.

Convenient adaptation – HiCar provides templates, handling UI rendering, card management, and task continuation.

Simple updates – updating the phone app automatically updates the HU presentation.

Platform limitation – works only with specific phone‑HU combos (e.g., Huawei phones with HiCar‑enabled HUs).

2. OpenAPI Integration

The vendor exposes server‑side APIs; the car manufacturer designs its own UI and calls the appropriate endpoints. This approach reduces the vendor’s development effort but requires the manufacturer’s resources and introduces limited controllability and iteration difficulty.

Low vendor manpower cost.

Broad environment compatibility.

Limited control over data and usage metrics.

Iteration depends on the manufacturer’s development cycle.

3. Independent HU App Integration

Because OpenAPI has notable drawbacks, the independent app model is preferred. It resembles standard mobile app development but must address HU‑specific challenges such as fragmented OS versions (Android 4.3 – 10), limited testing devices, and weaker performance.

Fragmented HU OS landscape.

Need for concise, voice‑friendly UI.

Scarcity of test HUs.

Wide version span and performance constraints.

Solution Design

1. Multi‑Channel Capability Abstraction

To hide platform differences, an EnvironmentDependency interface abstracts channel‑specific SDKs, while a generic MediaSession implementation handles standard controls. Business code interacts only with a DependencyWrapper proxy, invoking methods without knowing the underlying channel. Event callbacks are abstracted via an EventCallback interface. Channel‑specific code is isolated using Gradle product flavors.

flavorDimensions "channel
    productFlavors {
        // Xiaopeng
        xp {
            dimension "channel"
            buildConfigField "String", "channel", "\"xp\""
        }
        // BYD
        byd {
            dimension "channel"
            buildConfigField "String", "channel", "\"byd\""
        }
        // ...
    }

2. Voice Control Design and Implementation

Key questions include whether the app implements its own voice engine or relies on the HU’s built‑in assistant, how to trigger voice (button, long‑press, double‑click), and how to map recognized text to actions. A robust solution adds a semantic‑recognition layer after speech‑to‑text, and the overall interaction is modeled as a state machine.

For cross‑manufacturer support, common commands (play, pause, next, previous, favorite, search) are encapsulated in a generic interface; each manufacturer implements a server that receives these commands, while the client merely forwards them.

3. Multi‑Resolution Adaptation

Given varied HU screen sizes (landscape, portrait, exotic aspect ratios), the team recommends fluid layouts using RecyclerView orientation changes, ConstraintLayout percent attributes, and Guideline. For rare screens, a “sw” qualifier can isolate custom resources. When physical devices are unavailable, adb shell wm size WIDTHxHEIGHT simulates different resolutions.

Performance Optimization

1. Reduce Package Size

Compress images, obfuscate resources, and minimize Dex files.

2. Decrease Process Count

Merge auxiliary processes into the main process to lower CPU and memory usage.

3. Reduce Thread Count

Limit background threads to avoid excessive context switching.

4. IO Optimization

Eliminate unnecessary file reads/writes during startup.

5. Minimize Activity Transitions

Combine related Activities, pre‑fetch data, and batch network requests to cut launch latency.

6. Layout and Overdraw Reduction

A case study with a car‑manufacturer partner showed a cold‑start time drop from ~8 s to <3 s after:

Removing unused code (≈80% size reduction).

Merging playback into the main process and removing AIDL (≈2 s).

Combining LoadingActivity with the main Activity (≈0.5 s).

Consolidating multiple API calls (≈0.2 s).

Quantitative metrics guided each optimization step.

Pitfalls and Lessons Learned

1. Pre‑installed RN Pages Crash

In pre‑installed scenarios, libjsexecutor.so failed to load because SoLoader omitted the app’s native library path for system apps. The fix was to set a custom SystemLoadLibraryWrapper :

SoLoader.setSystemLoadLibraryWrapper {
    ReLinker.loadLibrary(context, it)
}

2. Network Issues on Test HUs

Custom iptables rules blocked external traffic. Clearing the rules with:

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

resolved connectivity.

3. SSL Handshake Failures

Some HUs reset system time on boot, causing certificate validation errors. Adjusting the system clock fixed the SSLHandshakeException.

Beyond Technology

Car‑manufacturer project management is meticulous and risk‑averse, leading to longer test cycles and extensive feedback loops.

Early alignment on delivery standards (performance targets, feature scope) is essential.

Current HU integration processes suffer from incomplete documentation, scarce test devices, and unstable emulators; proactive risk assessment and communication are key.

Conclusion

The article outlines the current state of car‑head‑unit development, shares architectural decisions, performance‑tuning techniques, and common pitfalls, aiming to help developers bring their mobile applications onto automotive platforms successfully.