AdminConsole
Tutorials/Advanced
Advanced2 hrLinux + Automotive

Operate a Mappls client on embedded Linux

Separate runtime and map-data compatibility, stage updates, survive power loss, and expose health signals.

By the endAn embedded map runtime with atomic data activation and rollback evidence.
Real-world scenario

Build against an explicit contract

An embedded Linux device must run and update a map client under constrained storage, intermittent connectivity, and supervised process recovery.

A Mappls developer projectA restricted Linux applicationFixture data with no production credentialsA request, aggregate, or correlation ID strategy
Step 1

Define the user and system contract

An embedded Linux device must run and update a map client under constrained storage, intermittent connectivity, and supervised process recovery. Record the region, data freshness, latency budget, privacy purpose, credential owner, and fallback before choosing an SDK or endpoint.

Step 2

Pin the compatibility matrix

Record CPU/GPU, OS image, runtime build, map-data epoch, region, license, storage, and cryptographic requirements as one release manifest.

Offline & Automotive · SDK or product slice
// Illustrative lifecycle: concrete symbols vary by licensed SDK edition.
NavigationRuntime runtime(configuration);
runtime.installDataPackage(verifiedPackagePath);
runtime.setPositionProvider(vehiclePositionProvider);

auto route = runtime.plan(origin, destination, vehicleProfile);
if (route.ok()) {
  runtime.startGuidance(route.value());
}

// Keep sensor callbacks non-blocking; persist the resumable session safely.
runtime.onProgress([](const GuidanceProgress& progress) {
  tripStore.checkpoint(progress);
});
Step 3

Supervise runtime health

Run with bounded resources, expose liveness/readiness, persist only necessary state, isolate writable data, and restart without corrupting the active package.

Step 4

Use dual-slot updates

Download into an inactive slot, verify signature/structure, smoke test, switch atomically, health-gate the boot, and retain the prior slot for rollback.

Step 5

Prove the production behavior

Automate the happy path and every named failure. The release is ready only when cold boot works without network; power loss never removes the active package; health failure automatically restores the prior slot. Capture provider request identity without logging credentials or unnecessary precise location.

Recovery design

Failure modes you must exercise

GPU/runtime incompatibility

Fail fast with a typed, user-safe outcome and preserve the original request identity.

disk pressure during staging

Keep the last verified state, mark freshness honestly, and retry only within the documented idempotency boundary.

power loss between switch and acknowledgement

Reconcile durable local and provider evidence before declaring success or issuing a compensating command.

Never turn uncertainty into success

Timeout after a stateful command is an unknown outcome. Query by provider/idempotency identity or wait for authoritative events; do not blindly retry a new command.

Acceptance criteria

Definition of done

cold boot works without networkpower loss never removes the active packagehealth failure automatically restores the prior slot

Linux production checks

Runtime and data compatibility is enforcedDevice identity and activation can be rotatedUpdates are signed, resumable, and reversibleHealth and resource telemetry survive application restarts
Grounded implementation

Continue from source, contracts, and a full app

These links resolve to repository-derived evidence; unsupported package names and endpoints are not filled in from guesswork.

Study the complete Offline automotive release state machine
Tutorial complete

Run it, break it, then observe it

Start with fixture credentials, execute the failure plan, and use request logs, usage, webhook evidence, and operational metrics before promoting traffic.