Concept Designs

This documents existing solutions for geo-related features (sometimes known as location-based services, LBS) which could be integrated into Apertis for providing geolocation, geofencing, geocoding and navigation routing support for application bundles. As of version 0.3.0, the recommended solutions for most of the geo-requirements for Apertis are already implemented as open source libraries which can be integrated into Apertis. Some of them require upstream work to add smaller missing features. Larger pieces of work need to be done to add address completion and geofencing features to existing open source projects. [Read More]

Apertis will store several types of information – media files, documents, contacts, e-mails, applications and their preferences, chat logs, and more. Much of this content will be stored with the application that generates or consumes it. A file manager would be very cumbersome for finding content in all these locations, and some of these data types are not strictly files. A powerful search system needs to be implemented to facilitate convenient access to the user’s data. [Read More]

This documents a suggested design for an inter-domain communication system, which exports services between different domains. Some domains can be trusted such as the automotive domain. Some domains are untrusted such as the consumer-electronics domain. Those domains can execute on a variety of possible configurations. The major considerations with an inter-domain communication system are: Security. The purpose of having separate domains is for security, so that untrusted code (application bundles) can be run in one domain while minimizing the attack surface of the safety-critical systems which drive the car. [Read More]

This design explains how the Apertis platform will be made localizable and how it will be localized to specific locales. “Internationalization” (“i18n”) is the term used for the process of ensuring that a software component can be localized. “Localization” (“l10n”) is the process of adding the necessary data and configuration so an internationalized software adapts to a specific locale. A locale is the definition of the subset of a user’s environment that depends on language and cultural conventions. [Read More]

This document covers the management of media content in the Apertis platform. There are several types of media content to handle in the platform: images, audio, video and documents. We can identify the following operations with media: Media Indexing: extracting metadata from media content and store it in a format that allows fast retrieval. Media Browsing: locate the media content and access its metadata. Solution provides a general overview of the technologies used, like an executive summary of Appendix: Media management technologies, as well as a high level view of the solution proposed. [Read More]

This document covers the various requirements for multimedia handling in the Apertis platform. The FreeScale I.MX/6 platform provides several IP blocks offering low-power and hardware-accelerated features: GPU : For display and 3D transformation/processing VPU : For decoding and encoding video streams The Apertis platform will provide robust and novel end-user features by getting the most out of those hardware components. However, in order to retain power efficiency, care must be taken in the way those components are exposed to applications running on the platform. [Read More]

This document describes how multiple users are expected to use the Apertis system, and works mostly as a guide and recommendations to help designing the system. It is intended to act as an “umbrella” document covering the multi-user topic in general, and will be supplemented by more concrete documents describing particular use-cases and recommendations for how those use-cases can be addressed. The driving force behind having a multi-user system is to allow customization of the system. [Read More]

This document describes one particular set of use-cases for how multiple users are expected to use the Apertis system, using the Multiuser Design document as a base. It starts by describing the use cases that are believed to be important in the automotive context, followed by a technical analysis and recommendations. The specific set of use cases on which this document focuses is a “transactional” temporary switch between users, which is a relatively unusual situation in mainstream computing, but has been identified as a situation that is more likely to arise in an automotive environment. [Read More]

Introduction This documents how system services and apps in Apertis may store preferences and persistent data. It considers the security architecture for storage and access to these data; separation of schemas, default values and user-provided values; and guidelines for how to present preferences in the UI. The Applications Design, and Global Search Design documents are relevant reading. The Applications Design and the Global Search Design reference the need for storage of persistent data for apps. [Read More]

Introduction This design identifies circumstances that, though undesired because of the risk of loss of functionality, cannot be completely avoided and provides suggestions for dealing with them in such a way that as little functionality as possible is lost. Note that improving D-Bus’ robustness is a topic that will be covered in a later stage in its own design document. About securing D-Bus services, please see the security design. Requirements Minimize loss of data and loss of functionality due to data corruption in these abnormal circumstances: [Read More]