What is linux kernel in android

What is linux kernel in android

The heart of every Android product is a monolithic kernel, the Linux Kernel. The Linux kernel manages the communication and system resources between hardware and software components. The Linux Kernel makes up the lowest-level software which operates any Android or AOSP-based ROM like CopperheadOS. Google chose to build Android and AOSP on the Linux kernel for good reason; the Linux kernel offers unmatched portability. This means the Linux kernel and consequently Android can be ported to many different types of devices with ease. Portability is an excellent way to ensure a more broad user/customer base. The choice of which version of the Linux Kernel to use is important and has a broad set of consequences for security.

Originally basing Android on Linux Kernel 2.6, Google has maintained their own fork of the Linux kernel since 2010 called android-mainline, this kernel is the basis of all the individual kernel versions available on Android devices and is updated with the latest Linux kernel security patches. When a new Android device is launched, that device can be launched with the latest LTS kernel features, simply by merging Android-mainline.

The latest Android Common Kernels are used to create what Google is calling Generic Kernel Images (GKI). A GKI is nothing more than the “core” components of the kernel itself. Therefore, the drivers must be loaded in Kernel Modules and a stable Kernel Module Interface must be created. This KMI must currently be stable within the LTS version of the Linux kernel which the GKI is based on. This design direction allows for devices launched using a GKI to have less difficulty backporting of kernel features and enhancements without having to also upgrade the associated Android platform. In some ways this may help to mitigate the impact of lag-time between the choice of LTS Kernel to be used in a new device at bring-up, and when that mobile device goes to market. It also means that OEMs can upgrade device kernels independently of the Android platform on devices built from GKIs. Potentially bringing relief to those OEMs who have historically been slow to upgrade the Android platform or forego the upgrade completely.

The Generic Kernel Image project has intriguing implications for device security. The benefits for kernel fragmentation, the overall Android platform and Android OEMs readily present themselves. Some implications for the security of Android kernels are also clear, with all unnecessary drivers stripped away in a given GKI much of the tedious security work is done already. What is less clear is how actual KMI implementations play out in the wild, potentially opening an avenue for attackers to load compromised drivers. With Kernel Modules loadable ex-vivo of the Android platform, the ease of finding critical vulnerabilities may be both a blessing and a curse.

Читайте также:  Practical linux security cookbook

“On Pixel devices, it was discovered that 90% of the kernel security issues reported in the ASB (Android Security Bulletin) had already been fixed for devices that stay up to date.” — Google Documentation

We will continue to research the impact of the GKI project, and what implications KMI implementations will have in the future.

Copperhead sends out email blasts to announce major company updates, recent CopperheadOS developments, and occasionally highlight important security-related news.

Источник

What is the difference between the Linux Kernel and the Android Kernel?

What are the modifications done in linux kernel to make it an android kernel ? By this question I mean what are the differences between linux kernel and android kernel ?

3 Answers 3

I think this Android Source is a great documentation for understanding it.

And here is a list of changes done from mainline kernel for android kernel 4.14.

The largest features include:

  • 19.8% Energy Aware Scheduling (kernel/sched)
  • 13.8% Networking (net/netfilter)
  • 13.5% Sdcardfs (fs/sdcardfs)
  • 9.4% USB (drivers/usb)
  • 7.2% SoC (arch/arm64, arch/x86)
  • 6.2% f2fs (fs/f2fs — backports from upstream)
  • 6.1% Input (drivers/input/misc)
  • 5.4% FIQ Debugger (drivers/staging/android/fiq_debugger)
  • 3.6% Goldfish Emulator (drivers/platform/goldfish)
  • 3.4% Verity (drivers/md)
  • 11.6% Other

Differences from LTS

When compared to LTS (4.14.0), the Android common kernel has 355 changes, 32266 insertions, and 1546 deletions (as of February 2018).

enter image description here

The differences change from version to version (both of Linux and of Android), and the exact kernel is different for each device. A kernel for Android is a mainstream Linux kernel, with additional drivers for the specific device, and other additional functionality, such as enhanced power management or faster graphics support.

Many features in the Android kernel are later added to upstream Linux after the open-source community has accepted (and perhaps modified) them, but others are never upstreamed, either because they’re not acceptable to the Linux kernel developers, or because they’re only applicable to Android or to specific hardware.

Most drivers for android specific hardware was accepted into mainline kernel; but some features, such as the wake lock which caused a huge controversy some time ago, remains problematic because mainline and android kernel developer disagree whether it’s a good idea.

» A kernel for Android is a mainstream Linux kernel, with additional drivers for the specific device, and other additional functionality, such as enhanced power management or faster graphics support», so it’s mainly drivers? No source code changed?

@GuerlandoOCs I’m not sure what you think drivers are if not a source code change, but regardless, the «other additional functionality» I mentioned is quite big these days. There are many source code changes.

@DanHulme are the source changes patches or just code changed by hand? How can I see things that changed? I’ve read that you can patch your linux kernel to be compatible with android, but where are those patches so I can read them?

Читайте также:  Player swf для linux

Beside the device specific differences and wake lock that Dan Hulme and Lie Ryan mentions, Android removed System V IPC features (message queues, shared memory segments, semaphores) that could lead to resource leaks (http://www.kandroid.org/ndk/docs/system/libc/SYSV-IPC.html). This probably is just a matter of configuring the kernel build. Also the Android IPC of choice, called Binder, has some support in the kernel that to my knowledge is not included in standard Linux kernels.

You must log in to answer this question.

Linked

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

Platform architecture

Android is an open source, Linux-based software stack created for a wide array of devices and form factors. Figure 1 shows the major components of the Android platform.

The Android software stack

Figure 1. The Android software stack.

Linux kernel

The foundation of the Android platform is the Linux kernel. For example, the Android Runtime (ART) relies on the Linux kernel for underlying functionalities such as threading and low-level memory management.

Using a Linux kernel lets Android take advantage of key security features and lets device manufacturers develop hardware drivers for a well-known kernel.

Hardware abstraction layer (HAL)

The hardware abstraction layer (HAL) provides standard interfaces that expose device hardware capabilities to the higher-level Java API framework. The HAL consists of multiple library modules, each of which implements an interface for a specific type of hardware component, such as the camera or Bluetooth module. When a framework API makes a call to access device hardware, the Android system loads the library module for that hardware component.

Android runtime

For devices running Android version 5.0 (API level 21) or higher, each app runs in its own process and with its own instance of the Android Runtime (ART). ART is written to run multiple virtual machines on low-memory devices by executing Dalvik Executable format (DEX) files, a bytecode format designed specifically for Android that’s optimized for a minimal memory footprint. Build tools, such as d8 , compile Java sources into DEX bytecode, which can run on the Android platform.

Some of the major features of ART include the following:

  • Ahead-of-time (AOT) and just-in-time (JIT) compilation
  • Optimized garbage collection (GC)
  • On Android 9 (API level 28) and higher, conversion of an app package’s DEX files to more compact machine code
  • Better debugging support, including a dedicated sampling profiler, detailed diagnostic exceptions and crash reporting, and the ability to set watchpoints to monitor specific fields

Prior to Android version 5.0 (API level 21), Dalvik was the Android runtime. If your app runs well on ART, then it can work on Dalvik as well, but the reverse might not be true.

Читайте также:  Install oracle jre linux

Android also includes a set of core runtime libraries that provide most of the functionality of the Java programming language, including some Java 8 language features, that the Java API framework uses.

Native C/C++ libraries

Many core Android system components and services, such as ART and HAL, are built from native code that requires native libraries written in C and C++. The Android platform provides Java framework APIs to expose the functionality of some of these native libraries to apps. For example, you can access OpenGL ES through the Android framework’s Java OpenGL API to add support for drawing and manipulating 2D and 3D graphics in your app.

If you are developing an app that requires C or C++ code, you can use the Android NDK to access some of these native platform libraries directly from your native code.

Java API framework

The entire feature-set of the Android OS is available to you through APIs written in the Java language. These APIs form the building blocks you need to create Android apps by simplifying the reuse of core, modular system components and services, which include the following:

  • A rich and extensible view system you can use to build an app’s UI, including lists, grids, text boxes, buttons, and even an embeddable web browser
  • A resource manager, providing access to non-code resources such as localized strings, graphics, and layout files
  • A notification manager that enables all apps to display custom alerts in the status bar
  • An activity manager that manages the lifecycle of apps and provides a common navigation back stack
  • Content providers that enable apps to access data from other apps, such as the Contacts app, or to share their own data

Developers have full access to the same framework APIs that Android system apps use.

System apps

Android comes with a set of core apps for email, SMS messaging, calendars, internet browsing, contacts, and more. Apps included with the platform have no special status among the apps the user chooses to install. So, a third-party app can become the user’s default web browser, SMS messenger, or even the default keyboard. Some exceptions apply, such as the system’s Settings app.

The system apps function both as apps for users and to provide key capabilities that developers can access from their own app. For example, if you want your app to deliver SMS messages, you don’t need to build that functionality yourself. You can instead invoke whichever SMS app is already installed to deliver a message to the recipient you specify.

Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Last updated 2023-05-04 UTC.

Источник

Оцените статью
Adblock
detector