#aosp

Introduction 

Security-Enhanced Linux (SELinux) is a core security mechanism in the Android Open Source Project (AOSP) that enforces robust access control. Unlike traditional Discretionary Access Control (DAC), which relies on user-based permissions, SELinux uses Mandatory Access Control (MAC) to restrict system interactions based on predefined policies. Android integrated SELinux starting from version 4.3. It runs in either permissive mode, which logs violations, or enforcing mode, which blocks unauthorized actions. 

Understanding SELinux policies, labels, and domains is essential for embedded developers working on middleware, HAL, and system daemons in order to secure Android devices. Sensitive system components are protected, unauthorized access is limited, and privilege escalation is avoided with proper SELinux configuration. This blog discusses best practices for creating security policies, how SELinux functions within AOSP, and a real-world example of using SELinux on a binderized HAL. Developers can strengthen embedded systems against exploits and security breaches by becoming proficient with SELinux. 

What is SELinux? 

With mandatory access control (MAC) policies that limit programs' capabilities beyond conventional discretionary access controls (DAC), SELinux is a security architecture built into the Linux kernel. It guarantees that an application's activities stay contained within predetermined bounds even in the event that it is compromised. 

Core Concepts of SELinux 

Labels: Every process and object (like files, directories, and ports) in the system is assigned a security label. A key component of SELinux's decision-making process is these labels. 

Type Enforcement (TE): The main SELinux mechanism is Type Enforcement (TE), in which policies specify how types (labels) linked to objects and processes can communicate. A process named httpd_t (Apache), for example, can be made to only access files with the label httpd_sys_content_t. 

Roles and Users: To manage permissions more precisely, SELinux defines roles and users. Nonetheless, type enforcement continues to be the main focus in many implementations. 

SELinux in AOSP 

SELinux integration with Android 

Google strengthened Android's security by integrating SELinux into the platform starting with version 4.3. SELinux functions in two ways in AOSP: 

Permissive Mode: Violators are recorded but not stopped; SELinux rules are not enforced. 

Enforcing Mode: SELinux rules are put into effect, and infractions are recorded and prevented. For strong security, Android devices try to run in enforcing mode. 

Advantages of SELinux in Android 

Privilege escalation is mitigated: SELinux restricts an application's behavior even if it acquires unauthorized privileges, avoiding more widespread system compromises. 

Protection Against Malware: By limiting applications' access to private information or system components, SELinux policies can lessen the possible impact of malware. 

Enhanced Multi-User Security: SELinux makes sure that user data is kept separate and safe from other users and applications by implementing stringent access controls. 

Implementing SELinux in AOSP 

Configuring the Linux kernel for SELinux: Make sure the kernel is compiled with SELinux support. This entails turning on particular security module configuration options. 

Filesystem Labeling: Give filesystem objects the proper security labels. This can be accomplished by setting default labels in filesystem images or by using tools such as restorecon. 

Compilation of Policies: Using tools like checkpolicy, create SELinux policies that are specific to the needs of your system. 

Policy Loading: Use tools like load_policy or incorporate the compiled policies into the system's initialization procedure to load them into the kernel. 

Writing SELinux Policies 

IVI (In-Vehicle Infotainment), ADAS (Advanced Driver Assistance Systems), and telematics are among the vital services that Android Automotive OS (AAOS) manages in automotive embedded systems. SELinux policies are necessary to enforce stringent access controls across all system components, especially middleware services, Binderized HALs, and system daemons, in order to ensure security in such a system. In order to make sure that only authorized system components can access and alter vehicle data, we'll map SELinux policy writing to a real-world automotive example below using a binderized HAL. 

Determine Types and Domains 

Consider a Vehicle HAL (VHAL) in an automotive system, which gives users access to information about the vehicle, including its speed, fuel level, engine status, and door lock condition. The telematics module, navigation app, and IVI system are among the system elements with which the Vehicle HAL service communicates. 

The hal_vehicle_t domain is where the Vehicle HAL daemon operates. 

vehicle_data_t is the label for vehicle data files. 

The ivi_system_t domain is where the IVI system operates. 

The telematics_t domain is where the Telematics service functions. 

By defining these domains, unauthorized applications are prevented from accessing vital vehicle parameters and controlled access between various system components is ensured. 

Tools and Resources 

SELinux Notebook: An open-source resource that provides comprehensive insights into SELinux concepts and implementations. GitHub - SELinuxProject/selinux-notebook 

NSA's SELinux Implementation Report: An in-depth report detailing the implementation of SELinux as a Linux Security Module. Implementing SELinux as a Linux Security Module 

Conclusion 

With SELinux included in AOSP, developers can implement strict access controls, isolate processes, and keep sensitive information safe. 

Whether you're building embedded Android systems, HAL layers, or automotive and IoT device middleware, SELinux offers a secure framework to ensure system integrity. 

Android is more than just a mobile operating system—it's a powerful middleware that seamlessly connects apps to the underlying hardware through a layered architecture of frameworks, services, and abstraction layers. The Android System Services, which control essential features like window handling, power management, telephony, and more, are at the core of this framework. By serving as a bridge, these services guarantee seamless communication between the hardware abstraction layer (HAL), the framework, and user applications. 

The internal operations of Android System Services are examined in this blog, along with how they interact with HAL and apps. 

Understanding Android System Services 

Essential parts of AOSP, Android System Services oversee fundamental features like power, connectivity, phone, and security. Through Binder IPC, these services enable smooth communication between applications, the framework, and hardware while operating inside SystemServer. Because each service is registered in ServiceManager, it is available throughout the system, including ActivityManagerService, PowerManagerService, and TelephonyService. By serving as go-betweens, system services make sure that applications communicate with hardware through the Hardware Abstraction Layer (HAL) without requiring direct access. 

Comprehending these services aids developers in extending AOSP functionalities, improving performance, and troubleshooting issues while preserving security and modularity within the Android ecosystem. 

Key Components of Android System Services 

SystemServer: The process in charge of launching and overseeing essential system functions. 

ServiceManager: A central registry that maintains a record of every system service that is available. 

Binder IPC: Applications, framework elements, and system services can interact thanks to the communication mechanism known as Binder IPC. 

HAL (Hardware Abstraction Layer): System services can communicate with hardware through the Hardware Abstraction Layer (HAL), which offers a common interface for hardware-specific implementations. 

System Service Types 

System services can be divided into groups according to how they work: 

Core Services: ActivityManagerService, WindowManagerService, and PackageManagerService 

Hardware Services: SensorService, AudioService, and PowerManagerService 

Connectivity Services: Bluetooth, WiFi, and Telephony Services 

Security Services: SELinuxManagerService and KeystoreService 

Each system service registers with ServiceManager for worldwide accessibility and operates as a distinct thread or process inside SystemServer. 

How System Services Interact with Apps and HAL 

To understand system service interactions, let’s break it down into three communication flows: 

1. Applications to System Services (Interaction at the Framework Layer) 

Through the Android Framework APIs, an application can interact with the appropriate system service to carry out system-level tasks (like adjusting brightness or connecting to WiFi). 

For instance, determining the battery level: 

The BatteryManager API's getBatteryPercentage() method is invoked by the application. 

BatteryManagerService receives the request and retrieves the most recent battery status. 

The data is returned to the application by BatteryManagerService. 

Important Takeaway: The application never communicates with the kernel or HAL directly. It always passes via the system services and framework APIs. 

2. HAL (Hardware Interaction) System Services 

The HAL is necessary for system services to communicate with hardware. In order to guarantee that system services function independently of particular hardware implementations, HAL acts as an abstraction layer. 

For instance, Changing the Screen's Brightness: 

App Request: The user adjusts brightness through the user interface. 

System Service Interaction: DisplayManagerService receives the request and notifies PowerManagerService. 

HAL Communication: Power HAL, which has direct hardware control, is called by PowerManagerService via Binder IPC. 

Hardware Execution: By interacting with the display driver, the Power HAL modifies the brightness. 

Feedback Loop: The system service updates the user interface after the HAL verifies the brightness change. 

Key Takeaway: Android is flexible and adaptable because HAL guarantees that system services can function across various hardware implementations. 

3. From System Services to System Services – Inter-Service Exchange 

Frequently, several services collaborate to complete a task. Android's system service interactions are smooth because services communicate via Binder IPC. 

Example: Intent Processing for Launching a Camera App: 

An intent is triggered when the user launches the camera app. 

After processing the intent, ActivityManagerService makes a request to CameraService. 

Permission Validation: CameraService uses PackageManagerService to verify app permissions. 

HAL Interaction: Camera HAL sets up the hardware and communicates with CameraService. 

Data Processing: MediaService processes the captured images before FileManagerService ensures storage. 

Key Takeaway: To effectively handle a single request, several system services work together. 

Practical Example: How a Phone Call Works in AOSP 

A call is initiated by the user (app layer interaction)  To start a call, the Dialer app asks TelecomManager to do so. 

TelephonyService receives the request from TelecomManager. 

RIL and TelephonyService Interact at the Hal Layer  After processing the request, TelephonyService sends it to the Radio Interface Layer (RIL).  As a component of HAL, RIL is in charge of interacting with modern hardware. 

RIL Gives the Modem a Command  The request is converted by RIL into AT commands that the modem can comprehend.  A connection is made between the modem and the network. 

The call status has been updated  The modem notifies RIL of the call status.  TelephonyService notifies the user interface by updating the CallState. 

Audio Routing & Call Connection  AudioService uses the speaker or earpiece to route audio.  Signal quality and LTE/VoLTE switching are managed by NetworkService. 

Call Terminations: Procedure for Cleaning  TelephonyService notifies RIL to end the connection when the user hangs up.  TelephonyService modifies the user interface while RIL tells the modem to end the call. 

Important Takeaway:  Without direct app-to-hardware communication, the entire process—which includes hardware control, HAL interactions, and multiple system services—operates without a hitch. 

Debugging Techniques for AOSP 

Debugging AOSP builds requires an understanding of these interactions. The following are some essential debugging techniques: 

Using Service Status with Dumpsys  To see a list of all active services, run:  adb shell dumpsys activity services 

Using logcat to check logs  For service activity monitoring, use:  adb logcat -s ActivityManager 

Verifying the Service Registration  To see if a particular service is operating, run:  adb shell service list 

Following HAL Strace calls  To monitor system calls from a service to HAL, use:  strace -p  

Conclusion 

The framework, hardware, and apps all work together seamlessly thanks to Android System Services. They oversee essential features like connectivity, power, and security, making sure the system runs smoothly. These services maximize performance while preserving modularity and security by utilizing Binder IPC. From resource management to facilitating seamless app experiences, Android's well-organized design enables it to effectively handle complicated tasks. 

Después de casi dos décadas de participación pública en el desarrollo del sistema operativo Android a través del Android Open Source Project (AOSP), Google ha optado por una estrategia más interna en todos los desarrollos relacionados con Android, lo que efectivamente hace que este proceso sea privado. La compañía sostiene que este cambio no implicará que el sistema operativo se convierta en un…

An update on Google's Android SafetyCore Program that Google auto installs and may actually keep re-installing.

The App blurs out parts of photos, and it collects the following data: call logs, contacts, location, your microphone, and possibly more. Though at present the app

“doesn’t provide client-side scanning used to report things to Google or anyone else. It provides on-device machine learning models usable by applications to classify content as being spam, scams, malware, etc. This allows apps to check content locally without sharing it with a service and mark it with warnings for users.”

Linux: El sistema operativo que usas sin saberlo Desde la llegada de los sistemas operativos, las computadoras se volvieron más accesibles para el público general. Con Windows y sus interfaces gráficas, su uso se masificó hasta el punto en que hoy casi todo el mundo tiene un ordenador en casa. Pero hay un sistema operativo que probablemente usas todos los días sin siquiera notarlo: Linux. A…

Our team is pleased to inform you that Android 14 has been successfully ported onto the NXP i.MX 8M Plus Verdin SoM. This accomplishment reflects our ability to remain at the forefront of embedded systems and is consistent with our dedication to being Toradex's reliable product design and development partner.

Why Android 14 on NXP i.MX 8M Plus?

The NXP i.MX 8M Plus is ideal for complex embedded solutions that need machine learning capabilities because of its powerful Cortex-A53 processors, integrated Neural Processing Unit (NPU), and Cortex-M7 for real-time tasks. Performance is further optimized with Android 14's new features and improvements, particularly for edge devices. We allow developers to create high-performance applications for a variety of industries, such as IoT and AI on the edge, with this successful port. Additionally, Android 14 facilitates remote device management, which is a crucial feature for apps that integrate with the Toradex Torizon IoT platform.

The Porting Process: Overcoming Challenges

Our engineering team made sure Android 14 supported every feature of the NXP i.MX 8M Plus Verdin SoM. For more complex AI tasks, this required making sure the Neural Processing Unit was compatible and optimizing performance for the quad-core Cortex-A53 processors. The user experience was seamless due to the seamless integration of Bluetooth 5.3 and Wi-Fi 5. Our close collaboration with Toradex was significant during this process. The integration was made easier by their thorough documentation, powerful development tools, and cooperative support. We were able to speed up development while preserving scalability for upcoming projects by using their Verdin carrier boards.

Real-World Applications and Use Cases

For embedded engineers, this successful porting creates new opportunities. Whether creating AI-powered camera solutions, smart Internet of Things gadgets, or complicated machine learning apps, Android 14 on the NXP i.MX 8M Plus enables a quicker time to market and lower development risks. Applications in healthcare, smart home products, and industrial automation can benefit most from this.

Partnering with Toradex

As Toradex's proud product design and development partner, we are committed to assisting businesses in creatively utilizing embedded systems. Our services guarantee that clients can concentrate on developing their applications while we manage the complex requirements of the operating system and low-level drivers by providing embedded Linux, FreeRTOS, and now Android 14 support.

What's Next?

We look forward to continuing to bring the latest software innovations to the embedded systems community. Our successful Android 14 port on the NXP i.MX 8M Plus Verdin is just the beginning, and we’re excited to see how developers will use this technology to create the next generation of intelligent devices.