I am new to android technology. Can somebody answer few of my question:
What are the similarities and differences between linux kernel and android kernel?
What is the minimum hardware requirement for mobile device to have android support?
Whether it is required to have a touch-screen mobile to run android technology?
Q1. The Android kernel is the Linux kernel with added device drivers for the hardware components that are not supported by the pure Linux kernel. However, there are also other differences. Quoted from here, and here:
The Android kernel code is more than
just the few weird drivers that were
in the
drivers/staging/androidsubdirectory 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.
You may also refer to this page for an opinion on this matter.
Q2. You may take a look at the Android 2.3 Compatibility Definition
(I haven't read it). For 3.0 the requirements are (quoted from here):
1GHZ processor, 512MB RAM, a display
screen that is at least 3.5-inches in
size
Q3. No, your device does not need to have a touchscreen to be compatible with Android. Refer to the compatibility guide above, but this is also evidenced by the first Android testing devices, that were running android (picture).
Related
I've always liked cheap smartphones ($ 50) because with little money I can have a powerful system with lots of sensors and things like that. So I wondered if it was possible to use the hardware without using the very limited android APIs, programming it at a low level then, of course with the root. In particular I wanted to see how the LTE module worked and experiment with this having full control, the Android API does not allow it to do much.
UPDATE: I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.
The first layer of software for the phone is the bootloader. It tells the processor what partition to load into memory for executing the kernel. This is the level that is usually blocked by manufacturers because of greedy corporate reasons that are beyond the scope of this site.
The second layer of the phone is the linux kernel. Rooting is the process of gaining root user access to this layer. Root is the main administrator user account that has permission to do anything to the device. Accessing this layer is what most people refer to rooting. A large portion of the kernel is written in C, with other parts in c++. What happens at this level is where all the magic is. For most phone this is where the code for the modem resides. Talking to this can usually be done via at commands of serial. Sensors are also programmed at this level and communicate via drivers. Root access is not normally needed to read sensor data, its just a case of permissions usually.
The next level is the android operating system, the java instance runs on top of that, which in turn executes the android operating system. This is the portion that most users will see and is primarily written in java. In reality you can run any kind of user interface at this level.
A very brief view of android apps.
The android api provides a way for java developers to write "apps" that communicate with the kernel and access different parts of the phone's hardware. These apps can also be written using c++. Only until recently has google integrated c++ into android studio, but the most common and still most effective method of doing so is using the QT framework.
It's a bit problematic.
Hardware manufacturers do that actually.
Take into account that Android is Linux much like other distributions.
The manufacturers develop hardware and then compile a version Android that sits on top of it. Each Android compilation is specifically tailored to the hardware and equipped with drivers that enable the main OS access to the different hardware capabilities.
For example, some tables will tweak the Android OS to not support cellular communication because they decided to cut costs and deliver the tablet without a cellular module.
From here you have 2 options:
To hack a specific hardware and understand how the OS communicates with the hardware.
Find hardware manufacturers that release some/all of their Android OS code. This is a much simpler way as you can both learn and extend the Android OS for that specific device.
An example of the 2nd way is Sony who has AOSP that allows low-level access to some of the Sony devices.
Also, there is always the Android NDK which gives you a more low-level access to Android but you are still constrained by the KIT API so I'm not sure it will help you.
I'm using something called libhybris, a wrapper that permit the use of android driver blobs in Linux.
Is Way To Run Machine Code Instead Android OS In Android Devices ?
I Want Remove Android Os And Work With Cpu And Other Devices Directly .
What Compiler I Can Use ?
MASM is an x86 assembler, so it would not be suitable for most Android devices as the vast majority use ARM-based processors.
That said, Android phones are computers just like any other and can be programmed in assembly. The first thing you'll need to do is select a device running a well documented CPU and chipset.
Since you'll be removing Android and plan on programming in assembly you'll need to write your own routines for nearly everything. An understanding of the CPU, power management and some form of I/O (you can avoid having to write complex display code if you plan to interface with the phone through serial communication, for example).
Unfortunately, much of the information required for successfully writing your own OS for an Android device is unavailable so you'll need some hardware analysis tools to assist in reverse engineering some of this information. A logic analyzer may be useful in sniffing some of the protocols used between chips, although much of modern phones is done on a single SoC, so you'll need to experiment heavily and compile information from a wide variety of online sources.
Aside from that, it's smooth sailing. Programming an OS in assembly for Android is pretty much the same as programming an OS in assembly for any other computer and you'll find it to be rather familiar territory.
Does any one know the real difference between stock & aosp kernel? If know please describe in detail or give me any reference.
Currently I want to build an aosp kernel based on htc stock kernel.
Android uses slightly different approach. To interact with the hardware it has a special intermediate layer between drivers and Linux kernel (called Hardware Abstraction Layer). So, even if you port kernel to a new device, this does not mean that drivers will work there. I guess you understand this.
As for the question itself, I can recommend you to find a book of Karim Yaghmour
"Embedded Android". There is main differences between stock Linux kernel and Android modifications are considered.
I'm trying to chose the ARM development board for education purpose.
The goal is to learn how to run and play around with systems like Android (version 2.0 or higher),Linux, Windows CE. It must support touch-screen, Ethernet, USB host and device.
I've found many boards, the most interesting is Android6410. I've search Google and it seems that it is not very popular. Has anyone used it? Is it well documented? What about the support? How about the performance under Android?
I've also found some other development boards:
http://www.friendlyarm.net/products/mini2440?lang=en - the most popular one but probably it is too slow for android 2.0.
http://www.friendlyarm.net/products/mini6410?lang=en - the same CPU like Android6410 but it seems to be a new product so the support may be pretty bad
http://beagleboard.org/ - quite interesting and popular but no touch-screen in standard version. The external ones are very expensive (twice as expensive as the board itself)
http://pandaboard.org/ - very fast but also doesn't have standard touch-screen connector, no Windows CE support
Any hints will be appreciated.
Samsung has provided an android kernel, as well as a reasonably current "generic" linux kernel) that, amongst other Samsung SoCs, also supports the 6410. The Git repos are here:
https://android.googlesource.com/kernel/samsung
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git
These do provide smdk6410 defconfig targets.
You also need an odroid bootloader (uboot for 6410) to be able to flash new kernels onto the board and/or the SDcard it boots from, as Samsung uses a special "fastboot" utility for this purpose (very different from OMAP which just puts the kernel into a file).
I can't comment on the performance of the device compared to others, as I haven't run extensive benchmark tests or anything, sorry. You're right, it's way ahead of 2440; it's an ARM1136 CPU, so it'll end up somewhat slower than the Cortex-A chips from omap3/4 boards.
Try the FL6410: http://www.arm9board.net/sel/prddetail.aspx?id=363&pid=200
A nice board with great Android support!
I am working on a system on which currently linux kernel and microwindows windowing system is running. Code of current linux system drivers is available to me. I want to port android on it, just as a hobby project.
can you please tell me what all understanding of linux-kernel is required to port it?
Please give me references (Books, Tutorials) to build-up understandings.
Thanks, Sunny.
P.S. I have basic understanding of linux.
Configuration of device is
450 Mhz ARM9,
64 MB RAM,
256 MB NAND
480x272 resolution.
Since you already have Linux up and running on your board you most likely won't need to have a deep understanding of the kernel. It will need to be modified, however, to include the following additional Android specific features. This may be as easy as applying some patches but it could be more involved.
Low Memory Killer
Android Logger
Android Shared Memory Subsystem (Ashmem)
Android Power Management (Wakelocks)
Binder IPC
In user space, Android uses its own display software called Surface Manager so you won't be using the Nano-X Window System (formerly known as Microwindows).
For an overview of what will likely be involved in a port, I would give the Android Porting Guide a read.
Websites on porting Android to other ARM based devices that may include helpful tips:
Beagleboard (Cortex)
Rowboat (I tried this one and it works)
Embinux
Zoom OMAP (Cortex)
OMAPpedia
Nokia Internet Tablet (ARM9E)
NITdroid
Neo 1973 (ARM9TDMI)
Benno Leslie's Blog
Intel Bulverde Evaluation Board (XScale)
NemusTech Blog
Sharp Zaurus SL-C760 (XScale)
EU Edge Blog
Online groups that may be able to help:
Android Porting
Android Internals
Android Platform
To start porting Android, a basic understanding of the changes to the linux kernels is required. Also, you'll need to understand which drivers besides the Linux are required.
linuxfordevices describes what was changed to the Linux kernel for the sake of Android. They also provide handy links like a diff of the changes they made....
On Android architecture, I found the youtube presentation Android Architecture]1 helpful.
I expect some issues in the display resolution. Android applications expect a number of standard resolutions. As a first step, I suggest to limit display to the next smaller size and then improve on this once it is up and running.
Since I've looked into Adroid for use in e-readers, I'm very interested in the porting myself. For this reason, I have registered for a (web based) training on android hardware (porting). I have looked for books etc. on the subject, but the books I found were much more on using Android and writing applications.
Have a look at these books as well:
Android - A Programmers Guide
Professional Android Application Development