新闻来源:http://www.kroah.com/log/linux/android-kernel-problems.html
As the Android kernel code is now gone from the Linux kernel, as of the 2.6.33 kernel release, I'm starting to get a lot of questions about what happened, and what to do next with regards to Android. So here's my opinion on the whole matter...
First off, let me say that I love the Android phone platform. Until last week, I used my developer G1, that I bought, every day. It worked wonderfully for me, and as a user, I was more than happy.
I'm also very happy about Android from a technical perspective. It's amazing that Google has taken the Linux kernel, and nothing else from a "traditional" Linux system, and created a portable and robust phone platform. It's so different that you can drop in a "real" Linux system image on top of the Android system, and they both work just fine with no changes needed.
Android also solves the problem that the phone manufacturers had been having for many years: a free version of Java and a unified application layer that programmers can write to that will work on all phone platforms that integrate it. Because of this, all of the existing "Linux Phone Consortium" groups are doomed and will probably close up silently very soon now, if they haven't already.
What's wrong?
So, what happened with the Android kernel code that caused it to be deleted? In short, no one cared about the code, so it was removed. As I've stated before, code in the staging tree needs to be worked on to be merged to the main kernel tree, or it will be deleted.
But there's a much bigger problem here.
The Android kernel code is more than just the few weird drivers that were in the drivers/staging/android subdirectory in the kernel. In order to get a working Android system, you need the new lock type they have created, as well as hooks in the core system for their security model.
In order to write a driver for hardware to work on Android, you need to properly integrate into this new lock, as well as sometimes the bizarre security model. Oh, and then there's the totally-different framebuffer driver infrastructure as well.
This means that any drivers written for Android hardware platforms, can not get merged into the main kernel tree because they have dependencies on code that only lives in Google's kernel tree, causing it to fail to build in the kernel.org tree.
Because of this, Google has now prevented a large chunk of hardware drivers and platform code from ever getting merged into the main kernel tree. Effectively creating a kernel branch that a number of different vendors are now relying on.
Now branches in the Linux kernel source tree are fine and they happen with every distro release. But this is much worse. Because Google doesn't have their code merged into the mainline, these companies creating drivers and platform code are locked out from ever contributing it back to the kernel community. The kernel community has for years been telling these companies to get their code merged, so that they can take advantage of the security fixes, and handle the rapid API churn automatically. And these companies have listened, as is shown by the larger number of companies contributing to the kernel every release.
But now they are stuck. Companies with Android-specific platform and drivers can not contribute upstream, which causes these companies a much larger maintenance and development cycle.
What would be needed to get the Android core code merged?
When the Android code was merged into the staging tree, a number of kernel developers reviewed the code and pointed out places that needed to be cleaned up, and changed, in order for it to be accepted. A number of these changes will affect the kernel/userspace boundry, so some changes to the Android userspace logic would also need to be changed if these kernel changes are made, preventing anyone except a Google employee from making the changes necessary.
So, what to do?
I really don't know. Google shows no sign of working to get their code upstream anymore. Some companies are trying to strip the Android-specific interfaces from their codebase and push that upstream, but that causes a much larger engineering effort, and is a pain that just should not be necessary.
Hope
I do hold out hope that Google does come around and works to fix their codebase to get it merged upstream to stop the huge blockage that they have now caused in a large number of embedded Linux hardware companies.
I've privately offered in the past to help this work get done, and am doing again here publicly. But I need the help of the Google developers to make it happen, without them, nothing can change.
The good news is that it looks like all of the kernel/userspace api changes will have no affect at all on any Android code higher up the stack (like applications), so all of this work can be done with no problem in the overall system.
I'll be giving a talk about this whole Android mess at the CE Linux Forum 2010 conference. Hopefully it improves before then, otherwise CELF will be continuing the long-held tradition of having keynotes in which the presenter yells at the attendees for all of the bad things they are doing.
分享到:
相关推荐
在内容上,本书结合使用情景,全面、深入、细致地分析Android系统的源代码,涉及到Linux内核层、硬件抽象层(HAL)、运行时库层(Runtime)、应用程序框架层(Application Framework)以及应用程序层(Application)。...
iTop4412_kernel_public:iTop4412_kernel_public存储库,android4.0,linux,ubuntu使用此内核源代码,包括scp和pop核心板
在内容上,本书结合使用情景,全面、深入、细致地分析Android系统的源代码,涉及到Linux内核层、硬件抽象层(HAL)、运行时库层(Runtime)、应用程序框架层(Application Framework)以及应用程序层(Application)。...
|-- kernel (Linux2.6的源代码) |-- packages (Android的各种应用程序) |-- prebuilt (Android在各种平台下编译的预置脚本) |-- recovery (与目标的恢复功能相关) `-- system (Android的底层的一些库)
最底层的是一个 Linux Kernel,加载了几个移动设备必要的系统驱动(这么说来 Android 基础系统是要以 GPL 发布了?不知道 34 家厂商的硬件开发商们是怎么样想的);上面是类库和 Runtime,绿色的类库部分可以看 到...
----------------------------------- Android 编程基础 1 封面----------------------------------- Android 编程基础 2 开放手机联盟 --Open --Open --Open --Open Handset Handset Handset Handset Alliance ...
11.2.2 media库中的audio框架281 11.2.3 本地代码284 11.2.4 jni代码288 11.2.5 java代码289 11.3 移植audio系统的必备技术289 11.3.1 移植audio系统所要做的工作289 11.3.2 分析硬件抽象层290 11.3.3 ...
11.2.2 media库中的audio框架281 11.2.3 本地代码284 11.2.4 jni代码288 11.2.5 java代码289 11.3 移植audio系统的必备技术289 11.3.1 移植audio系统所要做的工作289 11.3.2 分析硬件抽象层290 11.3.3 ...
其整个系统由应用程序,应用程序框架,应用程序库,Android运行库,Linux内核(Linux Kernel)五个部分组成。Android操作系统内置了一部分应用程序, 包括电子邮件客户端、SMS程序、日历、地图、浏览器、通讯录以及...
虽然Android系统非常庞大且错综复杂,需要充分Android内部内核空间以Linux Kernel作为基石,上层用户空间由本机系统库,虚拟机运行环境,框架层组成,通过系统调用(Syscall)连通系统的内核空间与用户空间。...
11.2.2 media库中的audio框架281 11.2.3 本地代码284 11.2.4 jni代码288 11.2.5 java代码289 11.3 移植audio系统的必备技术289 11.3.1 移植audio系统所要做的工作289 11.3.2 分析硬件抽象层290 11.3.3 ...
Android原始学习这是一个个人学习Android 4.4.4 r1源码的记录仓库文件按编译出来的模块存放: bootable编译成aboot.img文件(实际是一个bootloader ELF文件) kernel编程成boot.img的前半部,也就是Linux kernel...
答:Linux Kernel(Linux 内核)、Libraries(系统运行类库或者C/C++核心库)、Application Framawork(开源框架)、Applications(核心应用程序) 21、什么是ANR,如何避免它? 答:ANR(Application Not Responding):应用...
11.1.2 代码库(code repository) 158 11.1.3 邮件列表(mailing list) 159 11.1.4 缺陷追踪系统(bug tracking system) 160 11.1.5 wiki 161 11.1.6 其他 161 11.2 开源项目托管网站 162 第12章 开源组织和社区 ...
DynBW,动态内核构建包装器DynBW是易于使用的内核构建脚本,用于与Android兼容的内核源代码。 它具有高度的灵活性和实用性-都不需要花哨的半图形界面。 它的目标是简化和自动化构建内核的过程,以适应内核构建方案的...
如果该修补程序已经在上游Linux中,请发布符合以下修补程序要求的修补程序的反向端口。 更少的好处:在树外开发补丁(从上游Linux的角度来看)。 除非这些问题解决了Android特有的错误,否则除非与进行协调,否则...
BlackBox内核BlackBox Kernel与以下设备兼容-小米Redmi Note 5 Pro(Whyred) Android第一代(新芽) Yu Yureka(蕃茄)从源代码构建自定义内核初始化Linux发行版,克隆存储库并执行构建脚本// Establish ...
2、自动检测 Ext.SDK.7z 中的 SDK、NDK 版本进行设置,支持最新的 android-ndk-r9c-windows-x86+android-sdk_r24.3.3-windows 3、自动检测旁边的 jdk-7/8u*-windows-*.exe 进行安装,支持最新的 jdk-8u102-windows-i...
System.AI的核心是用纯C#编写的,并且完全是托管代码。 入门 在不同平台上启动的详细说明: : System.AI中包含的库 图书馆 状态 版本 网络扩展 稳定的 0.1 MKL * 开发/上一个 0.1 PyType.NET 稳定的 1.0 系统...