https://groups.google.com/forum/#!topic/android-x86/HO3rUmqZw1g
2017-11-30 8:17 GMT+08:00 Machine2A03 <aidan....@gmail.com>:
> Thank you for your reply!
>
> I am a student at Algonquin College in Ottawa, Canada. I am in the Computer
> Systems Technician program, and this project is for the Linux II course.
>
> Thank you for your clarification about how Android and Android-x86 do not
> strive achieve the same goals as a linux distribution.
>
> I spoke to the professor for this course and he advised me that Android-x86
> was a challenging subject to use for this project, but that it was an
> acceptable one.
Whether Android (and the derived Android-x86) counts as a Linux> Thank you for your reply!
>
> I am a student at Algonquin College in Ottawa, Canada. I am in the Computer
> Systems Technician program, and this project is for the Linux II course.
>
> Thank you for your clarification about how Android and Android-x86 do not
> strive achieve the same goals as a linux distribution.
>
> I spoke to the professor for this course and he advised me that Android-x86
> was a challenging subject to use for this project, but that it was an
> acceptable one.
distribution is just a matter of definition.
A general accepted definition is an operating system made from a
software collection, which is based upon the Linux kernel.
Android(-x86) fits the definition well. So it's a Linux distribution
IMO -- a non-GNU distribution.
Refer: https://en.wikipedia.org/wiki/Linux_distribution
Besides, Android-x86 is also listed in DistroWatch.com.
> The objective of the project is to write a brief document that explains the
> basics of how a specific linux-based operating system works. I need to
> provide an overview of the components that make up the operating system,
> identify how service management and package management are achieved, as well
> as explain the default partitioning scheme.
>
> In regards to the diagram I mentioned, it can be seen here. It is the first
> image in the body of the article, and it is a diagram that shows the basic
> components of the Android operating system.
>
> If one were to create a similar diagram to describe Android-x86, how would
> it differ from this one? I like to imagine this diagram with an ARM RISC CPU
> underneath it and a similar diagram for Android-x86 with an x86 CPU under
> it.
Android-x86 is just a porting of AOSP (Android open source project) to
the x86 platform.
By "porting", we mean to make AOSP run on the target device.
You should understand Google's AOSP doesn't contain hardware related code.
If you build AOSP's default taregt, the image won't run on any
hardware (no matter arm or x86)
except "goldfish", a QEMU based Android emulator.
To make Android run on a real hardware, you need to build a kernel
with appropriate drivers
and related HALs for the target peripherals -- that's what "porting" means.
This is usually done by chip vendors (e.g., Qualcomm, MTK, etc) and it's called
BSP of the target device (https://en.wikipedia.org/wiki/Board_support_package).
In this sense Android-x86 is a BSP of x86 platform.
We play the role of the chip vendor in the open source way.
Saying that, there are certain aspects make Android-x86 differ
than a traditional Android. Unlike a traditional Android image which
can only run on its target device, we made a generic image to run
on almost all x86 devices. To achieve that we modify/implement the
functions:
* Detects peripherals and load correct kernel modules
at runtime. Traditional Android usually doesn't use module
(but since Android 8.0 modules supporting is mandatory)
* Detects peripherals and load appropriate HALs at runtime.
Android-x86 also supports live mode (running on ramdisk)
and different partitioning scheme which are our unique features.
> From what I understand, the Android components have been re-compiled to run
> on the LTS kernel 4.9.54 for the x86 architecture. This, and additional
> adjustments, allow it to run on PC hardware.
>
> I see that Android-x86 makes use of other open source software, such as MESA
> for OpenGL and ALSA for sound. Would it be correct to say that MESA and ALSA
> are running behind Android and provide it with 3D graphics and audio output
> capability that is compatible with the x86-compiled kernel that Android-x86
> is running on? Does this replace and provide emulation for the original
> software that would have been running on the ARM-compiled kernel in standard
> Android?
MESA implements the OpenGL ES function required by Android.
As I said, AOSP doesn't contain any code to run on a real GPU.
The BSP provider needs to implement the OpenGL ES drivers and libraries
for the target GPU. That's what we did.
Of course we won't and can't implement it from scratch.
We just re-use the open source project MESA. We ported it to Android.
About ALSA, we didn't really use it except some ALSA tools
to configure the sound cards. It's not really necessary but simpler.
> I have learned in my studies about systemd and SysV. Are these used for
> service management in Android-x86 or is a custom service management
> implementation used? What scripts or utilities make sure that necessary
> services such as networking and display start and stay running?
> From what I can tell, on Android-x86, an Android image is mounted and a lot
> of filesystems are emulated so that Android thinks it is running on a mobile
> device. My installation of Android-x86 only uses one 16gb disk formatted in
> ext3, but various other filesystems are mounted once Android is running. I
> need to better understand Android's default partitioning scheme to be able
> to tell how Android-x86's is different.
and possible more depends on vendor's implementations.
On the other hand Android-x86 can run within a directory of one partition
in different filesystems (ext4/ntfs/vfat).
However, this is just for convenient usage. The users don't need
to re-partition their disk to install Android-x86. Of course
it's possible to run Android-x86 with standard Android partitioning scheme.