Automotive Grade Linux / Collabora
Daniel Stone <daniels@collabora.com>

What is the App Framework?

Why is the App Framework?

• App Framework developed by IoT.bzh

• Developed for AGL IVI applications

• Based on JSON + WebSockets

• Communication separated between services in different

• processes

• Clients and services can be written in any language

• Heavily integrated with SMACK

• Communication separated between services in different processes

• Allows common authentication between security domains

• Clients and services can be written in any language

• Portable to multi-ECU solutions

• Communication separated between services in different processes

  •  ... but is JSON + WebSockets the best transport mechanism?

  • IoT.bzh proposing to replace JSON with binary serialisation due to performance overhead

  • Not always the best signalling for every usecase

• Allows common authentication between security domains

  • ... but that authentication is heavily based on SMACK

  • Reliant on UNIX process model and privilege inheritance

  • Complex, difficult to get right

  • (to the point it’s a FAQ)

  • Still no support for WAM-like usecases

• Clients and services can be written in any language

  • Few helpers and bindings for many languages

  • Lacks rich features compared to other IPC and RPC systems: deeper API integration (FFI, callbacks), service enumeration and discovery●

• Portable to multi-ECU solutions

  • ... but, SMACK

  • Enumeration and discovery also undefined

• Requires bespoke effort and binding for every language and app

• No community support buy-in outside AGL-IVI & IoT.bzh

• AGL app framework is not production ready (lacks features, performance, etc)

• Toyota proposing to replace app framework (?) as part of PR effort

• IC EG proposing to avoid IVI app framework

• ... a lot of effort for little help

• AGL production-readiness model emphasises tier-1 needs

• AGL IC effort has own clearly defined architecture

• AGL IVI supposed to be ‘innovation’ area

  • New technology development

  • Emphasis on collaboration with upstream open community

  • Success stories: PipeWire, Wayland, etc

• Restart from fundamentals, focus on base requirements

• Activity, lifecycle, lifetime management of services

• Authentication domains

• Inter-service discovery, enumeration, connection (like Android intents and Binder, D-Bus, cloud services)

• Restart from upstream OSS projects

  • Consider systemd sessions and scopes for lifecycle

    • Works with standard UNIX services

    • Works with modern container workloads e.g. CRI

    • Uses cgroups for isolation and separation

    • Monitoring process lifecycle, bidirectional notification

  • Reconsider authorization strategy

    • Investigate alternate authorization mechanisms not based on single LSM

    • Use of privileged sockets (as in Wayland privilege model), network namespaces, to differentiate different services

    • Alternate authorization mechanisms such as OAuth2/JWT or ephemeral certificates (as in Kubernetes) for remote services

  • Strongly reconsider IPC mechanisms

    • Most other IPC services (Binder, D-Bus, gRPC, others) already handle common problems

    • Authorization, performance, tracing: key considerations

    • Service enumeration and discovery: helpful addition on top of existing app FW

    • Investigate domain-specific solutions: like WirePlumber for audio, Wayland for window management, etc

       

• Accept limitations of current resourcing and funding

• We do not have enough engineering time to produce a complete app framework from scratch

• AGL should be close to open upstream communities

• Focus on the glue: reuse, improve, integrate, iterate!

● Detailed time estimates for new app framework:

● ...

● Please discuss! :)

Collaboration between Virt, IVI and IC EG's , gathering needs and requirements.