I am preparing to build a custom Android ROM and I have come across some misunderstandings that I need clarified before moving forward. My Android ROM will be rebranded and I would like to customize the OS stack but I am not sure I fully understand the concept of HAL(Hardware abstraction layer). I understand that I can create kernel modules to extend the OS but I am not sure what the HAL purpose is within the stack. How does the HAL and the kernel interact if at all?
What is the HAL?
When is the HAL implemented?
Another layer of the stack I am looking at is the Android System Services layer. Would it be possible to add / modify a system service on the stack? If so, would I need to create a Binder IPC for the System Service to be called from the application framework?
I have read the documentation from the AOSP website but that is where my misunderstandings is coming from.
If anyone can help me overcome these shortcomings I would greatly appreciate it!
Ok, so I can answer your question about HAL but not so much about messing with Android services.
HAL is basically all of the files in the /dev directory on Linux systems. These files communicate with the kernel module/driver when you write to it. This basically, if the driver of the certain device you want to write to allows it, allows you to communicate with the device from a very high level point. Take a look into basic tutorials about writing kernel modules and udev. In the case of building Android though, you probably won't have to mess around with this and know it through and through unless you are making custom kernels and stuff.
Related
Now wait just one moment before you mark this as a duplicate, because this is a very specific question.
I'm not asking if you can write an application using another language which is a binding using the NDK; what I want to know is:
At a hardware level, how does dalvik interact with the Linux kernel on android devices?
The answer to (1) as I understand it, is that because android is fundamentally a Linux system, this is done via syscalls. Which is to say, at some level the davlik/art VM must interact with the C Linux kernel through a C API.
If you had root permission on a device, why could you not do the same thing from a native system binary?
So, certainly it would be a painful experience, but technically is there any reason why it would not be possible to write an application purely in C, without using the android run-time at all?
(Note: Not without the run-time; obviously the run-time must be present to do various things like device initialization; but a stand alone binary that did not interact with the run-time).
(I can think of a few reasons why this might be the case, specifically the run-time requiring exclusive hardware access to various hardware, but I can't find any specific documentation about it)
It is possible, this is how daemons work on Android (think RILD for example). However you cannot gain access to the Android facilities (graphics, location, etc) as there is no API from C.
Note that in order to speak to the Android API, your process needs to be a child of zygote. If you spawn a process from an ADB shell, or from init you will not be a fork() of zygote and will not have direct access to the JVM.
I'm hoping to write a tweak to record all activities running on a rooted Android phone. For example, I want to record the information such as:
2012-07-31 15:03 app1:Activity01:onCreate()
2012-07-31 15:04 app1:Activity01:onStart()
...
2012-07-31 15:05 app1:Activity01:onPause()
2012-07-31 15:05 app2:Activity01:onResume()
Is is possible to do it? If so, please kindly tell me where to find the related information, books or domain knowledge I should study to accomplish this task. I'm new on Android programming but familiar with C++ and Java.
Thanks a lot!
Each Android app is executed in its own process running its own instance of the Dalvik VM. The VM normally does not provide the information you are looking for across process boundaries.
If you feel like really hacking your Android you could investigate into these two approaches:
Modify the Android API classes, basically building your own android.jar, where you can override and extend existing functionality.
Try to use the VM's debugging facility to gain access to its runtime state (see e.g. Dalvik VM debug monitor).
Bottomline: Rooting your phone is child's play compared to those hacks.
However, I would advise against trying to 'hook' into Android the way you described, both for performance and stability reasons.
So the answer was it ain't possible in a normal app, even on a rooted phone.
See comments :-)
I'm going to implement aodv protocol as a linux module for a research project, and I need to implement it on Android later.I wonder if I could compile my codes into the android kernel and have my module work as in Linux (kernel 2.6 up).
Any suggestions would be greatly appreciated.
(P.S. There are already some aodv implementations on Android, such aodv-on-android and UoB JAdhoc, however, those are implemented in Java, not involving kernels)
The tagline goes: Android is Linux, so anything (portable) you do on Linux should be simple to make happen on Android.
This is mostly true, however there are a few things you'll want to keep in mind:
Portability: If you're writing your implementation on x86 and then moving the module to ARM for Android, be careful not to use any capabilities that don't exist on both. However, for something like a network protocol, you probably won't be running into a lot of these. The only one that comes to mind is the NIC.
Dalvik: Generic Linux distributions tend to run fairly close to the OS, meaning they regularly make system calls or libc calls, and the semantics of interactions with the kernel mostly carry over to the application. Android, however, has essentially a Java environment build on top of that, and the majority of applications only interact with that framework. For you, this means you will want to be aware of the possible need to modify the Android framework in order to make changes visible to applications.
The above point depends on your use case, however. If you plan on augmenting routing for existing applications to use aodv, then you'll want to hack around with Dalvik. If you'll be writing one proof of concept application, then you can write the portions that interact with aodv in C using the NDK, and avoid having to modify the application framework.
You probably already know this, but the kernel built system is sophisticated enough that you should be able to get away with writing your module once and compiling it for two architectures or platforms just by changing your configuration.
Hope this helps.
I am getting into making my own embedded system and I wanted to use an open source OS to run on it but I can't seem to find any information for making a completely customized GUI (Meaning desktop Icons, Menus, and windows). Would anyone know how to go about doing this? Or could point me into the right direction to research?
You've got quite a vague question there :
Here is an article on how to port Android to an embedded system
Information for making a completely customized GUI (Meaning desktop Icons, Menus, and windows)
You can start by learning android development.
Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.
Have you picked out a development kit for this yet? If you get a Beagleboard or something with a TI processor, there are great resources for getting started with Android or Linux. The beagleboard would be a particularly good choice, due to a rather active community.
Freescale also has good support, particularly with its Linux builder LTIB.
I am not entirely familiar with how one would go about re-inventing a GUI for Android, but in Linux a good place to start might be with GTK+ or Qt libraries.
What are the key differences between Android, iOS and Blackberry OS in terms of level of accessibility by application developers (i.e. access to the video input, sound input, phone functionalities, to which extent, etc.)?
PS: Assume latest version of each OS.
EDIT: Can someone turn this into a wiki so we can compile answers from people that don"t necessarily have experience in all 3 plaforms.
I'm not familiar with BlackBerry, but on Android and iOS you can access just about anything. Until recently iOS had some restrictions about camera access (see this), but I belive those have been solved. Because Android is open-source, you can theoretically go as deep as you want as far as accessing the hardware, but you may or may not be able to get any deeper through the standard Android API than you can through the iOS API.
On Android, you can do a lot more to override default functionality. For example, you can create your own launcher screen or phone application. The iOS approval process wouldn't allow these kinds of applications.
API hardware access really isn't an issue on either platform, the bigger concern is overriding default software (almost never possible in iOS) and what types of applications iOS allows.
Each platform has its own nice and bad parts. I have been working on both Android and BB. I wish I could take only nice parts from both to create a platform of a dev dream! :)
For instance, I could take these features from BB:
The greates feature I like in BB is the simplicity of the application architecture - you can always count on your main UIApplication instance - OS never kills it.
Also I do like the simplicity the Dialog class provides - it is very easy to implement business logic related to user choice - while Dialog screen is shown the code execution just stops and waits for user input.
From Android I'd take the following:
Network communication. On BB this is a real nightmare (BES, BIS, WIFI, Direct TCP without APN, Direct TCP with APN, WAP, WAP2, Unite - who's next? :)).
For file manipulations you just use a native/usual Java API.
Nice looking UI components are available right out of the box.
I should add I'm not happy with GPS related stuff on both platforms, however maybe it is due to GPS hardware limitations rather than API creators.
Thanks!
BlackBerry is a pain, once I made a project for it (the JDE version was 4.7 back then) and it didn't had an ArrayList. WTF?