[Arm-netbook] Ask him for Android DDK (Was: I Have An Possible Chance To Meet An ARM Senior Manager)

[Carlos Balseiro]

Alex ideas are really interesting. I will be happy if ARM just showed some concern about the continuous GPL violations commited by some of the SoC producers. Also more support for their GPUs in Linux.

-----Original Message-----

From: Alexey Eromenko
Sent: 7 Oct 2012 09:56:19 GMT
To: Linux on small ARM machines
Subject: [Arm-netbook] Ask him for Android DDK (Was: I Have An Possible Chance To Meet An ARM Senior Manager)

>If I meet him would you have any thing you would like me to talk about?

If you could ask him to help Google design a kernel space framework
(DDK, driver development kit) for Android.

If successful, it will lead to even bigger adoption of ARM, and direct
competition with Windows desktop.
Reason for ARM to push this idea: ARM could sell more higher - end
core licenses, and improve profits.

Here is my idea in detail:

Android is quickly becoming a full-blown O.S, a desktop replacement,
and it needs more low-level abilities to go way beyond one-trick-pony
apps.

Today Android has SDK (Java) and NDK, but lacks of full-scale kernel
framework (DDK, driver development kit), which sort-of limit what can
be done with Android.

I would like to hear some comments on Wish #37260.

http://code.google.com/p/android/issues/detail?id=37260

Some Android developers disagree that there must be a way for kernel
modules to exist on Android, citing security issues, but the upside of
kernel modules is a *HUGE* one, just like going from HTML-only-apps to
native apps.

My reason : On the Desktop side, for example, the benefits of software
like VirtualBox, VMware, and TrueCrypt out-benefits the risk of
viruses.

The similar concept like with Windows PC, but via Google Play, adopted
for Android reality, and eco system.

With Windows desktops, the developers have a stable kernel ABI/API for
one major version of Windows (XP,  7,...) and multiplied by number of
CPU architectures. (x86-32 and x86-64)

Plus developers (and Windows users) have root access. (Admin permission)

Ingredients :

1. Security (aka giving root access)
1.a. Via Google Play
==================
Google could charge a sum of money (say $1000), to post system-level
utilities on Google Play. This money must be used by Google for hiring
people to review all root and/or kernel applications on the market.
(as well as coloring them with red font and add system label). Perhaps
there could be a discount for non-commercial FOSS projects.

VMware must digitally sign it's system-level app, plus pay Google for
review. Obviously review can't be too deep, just basic. There is no
way to deeply review malicious closed source kernel code.
Once VMware gets Editors Choice award on Google Play, you can skip
reviewing each new coming version.

Basically the review process should be more human oriented than
software oriented. Your Google Play reviewers ask the developers about
their goals, and why they believe their software should require root
access.

VMware being a known company will get OKAY and editor's choice
approval, and get their app into Google Play market.

The traditional applications (that do not require root), will not
require manual review and will be listed in black color. This system
will allow to emulate a walled garden and reduce virus risk for most
Android users.

1.b. System App Sideloading
========================
(basically one click root)
Should have a separate entry in UI. Settings->Security->"unknown
system software" Allow installation of system-level applications and
kernel modules from unknown sources. (just under "unknown sources")

This would be useful for power users alike, for beta testing, and for
freedom reasons. Also useful for iffy projects. One - man efforts.
(big open source projects and commercial projects will have easier
time to get to Google Play quickly).

Surely today hackers can root their Android but it doesn't scale.
Companies obviously won't develop software for" rooted Android ", for
the same reason as they won't develop for" jailbroken iphone ".

2. Frozen kernel API/ABI
======================
In the upstream Linux Kernel API/ABI stability is non-existent (for
internal interfaces).

Solution: Debian-like frozen kernels, changes once per few years.
Guarantees that 3rd party closed-source kernel modules stay
binary-compliant, and work across a zoopark of devices. Debian
backports certain new drivers into old stable kernels, without
breaking API/ABI for existing 3rd party developers. i.e. Android
Open-Source project must standardize on a single kernel image, and
support it during 2-4 years.

During that time only bugfixes and driver backporting is allowed. New
kernel modules are also allowed (since they don't change internal
kernel API/ABI).

Debian stable kernels never change neither major nor minor versions,
and the only way to find out their real version is via /proc/version.

This means that 3rd party (closed-source) developers will have to
patch their applications only once every several years, and guarantees
good, if imperfect, compatibility.

NOTE: To achieve compatibility of installing kernel modules, there
must be a standard compiler tool-chain for Android, also frozen (i.e.
non-changing for few years, like in Debian).

Example :
Android 5.0 standardized on Linux 3.0.
Android 5.1 uses same kernel 3.0.x (6 months), just few new drivers
for new hardware. Plus the same compiler toolchain as in Android 5.0.
SDK + API level can go up.  No problem.
Android 5.2 again uses same kernel  3.0.x (12 months passed)
Android 5.3 again uses same kernel  3.0.x (18 months passed)
Android 6.0 - 24 months passed now. Now Android ready to take the
newest Linux kernel (3.6.x?), which will require 3rd party developers
(VMware) to update their software. The benefits of jumping to 3.6 is
that you enjoy everything the Linux community developed during those
years.

(Note : even for Windows desktops, the kernel apps need to be upgraded
every several years, when migrating from XP to 7 for example.)

Assuming VMware wants to support all CPU architectures and Android
versions 5.0/5.1/5.2/6.0 across all vendors.

VMware must test only 6 variants. CPU architectures (x86, x86-64, ARM)
multiplied by kernel versions (3.0, 3.6). Today to support Windows
XP,Vista and 7 (3 OSes) on all architectures (2 CPU Arch) VMware must
also test 6 cases. This is manageable.

Today, if someone writes a system-level utility, it will require
rooted Android to load custom kernel modules, plus different Android
versions have different and incompatible kernels.

It is wrong to switch kernels every 6 months, because 3rd party
developers can't target your platform this way.

For ARM:
Having such a DDK in place will let vendors (VMware, VirtualBox) to
port their code to Android/ARM few years from now.

3. CPU architecture matrix.
======================
Windows desktops support only 2. (x86-32 and x86-64)
In case of Android I propose to support ARMv7+neon, x86-32 and x86-64
initially, and possibly add more later.
So Android developers will have 3 architectures to care about.
Supporting ARMv5/v6/... Is not required, as we speak about Android future here.
Other CPU (MIPS, ARMv6) might run SDK, just not DDK. (at least Google
should not guarantee compatibility for those)

For ARM profits: They need to push latest and greatest architectures
early (ARMv8)...

4. Vendor customization
======================
In case of Windows, Toshiba laptops come pre-installed with different
software and drivers, than, say, Dell or Sony laptops. Yet it does not
pose any problems for 3rd party developers (VMware). If the API/ABI is
stable, vendor customization doesn't matter.

Android compliance program must add some basic DDK / kernel compatibility tests.

Best wishes,
Alexey Technologov, Open Source community member. Israel.

_______________________________________________
arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook at files.phcomp.co.uk