I am studying the different logging mechanisms on Linux in case of a Kernel panic (OOPS). So far from my search on the web, I have been able to derive the following information:
apanic was an old mechanism of getting the job done.
ram_console/persistent_ram is a new mechanism.
Could someone enlighten me about the following in this regard ?
What was the old apanic mechanism, at a high-level how did this work
?
Why was the apanic mechanism deprecated, in favor of the ram_console/persistent_ram mechanism ?
What advantages does the new ram_console/persistent_ram mechinsm bring to the table.
In what way is the ram_console/persistent_ram functionally different from the old apanic approach ?
I am just looking for pointers and high level answers, in some sense a direction which I can take to research the mechanisms further. I would appreciate any relevant information in this regard.
Thanks
Find answers below for your series of questions.
What was the old apanic mechanism, at a high-level how did this work?
It is a mechanism used by Android for message logging. It writes the log message into some specific offset in mtd partition of NAND. The kernel module exports file named called "apanic" to the "debugfs". The debugfs can be mounted on some directory using the below command. " mount -t debugfs none /sys/kernel/debug" which requires debugfs configuration enabled on linux kernel.
For more information on this go through the source code in link below.
https://android.googlesource.com/kernel/msm.git/+/android-msm-2.6.35/drivers/misc/apanic.c
Why was the apanic mechanism deprecated, in favor of the ram_console/persistent_ram mechanism ?
This apanic driver is not part of a linux kernel. It is specific to android. It is deprecated in latest version of androids. The reason could be writing into nand partition may not be good idea when kernel opps happens. Since the nand_write is slow as well as has limited write cycles. This is just my opinion. But i am not sure of the actual reason .
What advantages does the new ram_console/persistent_ram mechinsm bring to the table?
It is also a logging mechanism used by android for logging console messages. Here the logging messages goes into RAM area. In case of persistent_ram , the log messages goes to persistent memory area (which will be retained ) of RAM. This driver module creates a file named "last_kmsg" in the proc directory. This message can be read in next boot if the kernel oops and stops booting. For more information go through the source code given in the below link.
https://android.googlesource.com/kernel/common.git/+/android-3.4/drivers/staging/android/ram_console.c
In what way is the ram_console/persistent_ram functionally different from the old apanic approach ?
The former is ram based and the later is mtd based.
In the latest experimental android source i am not finding the source of both. Do not know the reason.
https://android.googlesource.com/kernel/common.git/+/experimental/android-3.10-rc5/drivers/staging/android/
Hope i clarified your queries.
Regards,
Yuvaraj.A
Related
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.
It's almost an exact copy of a question from here. Sorry for this, but the audience here is much larger so I have better chance to get a precise answer.
Is it possible to remove all "user layer" application and VM from Android, just to obtain plain linux-based embedded OS with all libraries and drivers already configured? Since VM is just a process from kernel's perspective...
Looking on this what I would like to get is: Linux kernel + HAL + (maybe) a shell or some way to launch my program.
Maybe somebody already have done something like this or knows good resources about it?
Yes, it is possible (Though I never tried and not 100% sure). To do this, you have to get the source code of Android (Android is open source, so its easy to get it) and start removing all user layer application and VM. Then, you need to write a program to operate the device. Its hard to do it though.
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 :-)
The easiest way is probably to write a loop to monitor /proc/net/tcp or /proc/net/tcp6. However, it is too inefficient since I need to be notified almost immediately. The closest thing I looked at is inotify which can provide callbacks on IO events on any files. The problem is that procfs is not regular file systems and inotify does not appear to support it (at least not for /proc/net/tcp and /proc/net/tcp6).
Further, I do not want the program to have root privilege in order to implement this.
EDIT: I removed the requirement of userspace connection. Also, I'm hoping that there's a built-in kernel support such as inotify that can achieve this. It may even be too intrusive in my case to manipulate the iptables.
Anyone has any idea? Thanks!!
You could add a logging rule to your local iptables configuration that would log a message whenever a new connection is initiated, and then make the log file readable by a non-root user. This would get you (a) immediate notification of events (you could use inotify to detect writes to the file) and (b) the detecting process itself does not need root privileges.
Best thing I can think of is trying to run an on-board proxy and persuade other apps to connect through that. Some have tried to do this by altering the APN settings.
But this is ugly, may not work on all versions, and can probably be circumvented.
Unfortunately, Android just isn't designed to allow end users to install optional improvements to the behavior of the system itself, short of cracking the whole thing open (ie, rooting).
It's certainly possible to monitor outbound traffic using raw sockets. See man page for packet (7) to see how to do that. However, this may not be what you want.
If connection-tracking is enabled, it may be possible to get notifications of new connections from the kernel using netlink. The API for doing these things is awful, so consider looking at the source of a program which does it already. I think the "conntrack" binary may be supplied with some distributions (I'm not sure what it's part of).
Does anyone know where I can find the list of system call that can be used in Android Mobile phones? I guess that looking to the kernel should work, but I cannot find any *.h or *.c with the declaration of them.
Best regards
You primarily want section 2 of the linux kernel manual pages.
Very little is unique to Android, the few gotchas being in the android docs (no sys-V IPC, AF_INET sockets won't work unless you are in the network group, etc). Most of the android additions are drivers (Binder, etc) and novel usage patterns (for example of user IDs) rather than actual syscalls.
If you actually need the syscall numbers you can find them in bionic/libc/SYSCALLS.TXT within the sources
You may want to check the Bionic sources for the system call list. Since, Bionic is the C-Library, that Android works off.
Try here
It is located in SYSCALLS.TXT file inside of libc directory under certain Android version. Example above is system call on Android 11.