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.
Related
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
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 :-)
What is happening under the hood? somehow this is passed down to the OS, and someshow the OS will find the right activity / activities, and launch it? Is there a service / lib running in Android handling this? I am trying to modified the OS to override the logic of startActivity across the board, is this possible?
Thanks.
I would take a look at the Android source! Whenever I'm developing and I run into an issue I read through the source to discover what is happening under the hood; it's quite interesting! It's an insight into what's actually going on, and also very good guidelines for documentation and code formatting!
http://source.android.com/source/downloading.html
A good starting point might be ActivityManagerService
Basically, when an app is first launched, startProcessLocked() in ActivityManagerService creates a new ProcessRecord (if necessary) and then calls Process.start(), which in turns builds the arguments for zygote and sends to zygote's socket using zygoteSendArgsAndGetResult(). Of course there's more to it than that, for example if an app shares a uid, is isolated, etc. But that gives you the basic process.
Looking over the source is indeed a good way to understand what's going on. However, unless you're planning on modifying it, don't bother downloading AOSP, just use GrepCode. Easier to browse, search and everything is hyperlinked so it's easy to follow through to classes, find usages, derived methods, etc. If you download AOSP, you'll be stuck with grep, ack-grep if you're lucky and a text editor. Also, you'll only have the one version you picked to checkout. GrepCode has the code for almost every version since 1.5.
The linked text above will take you to the relevant source at GrepCode. Try it out! The only downside is that GrepCode doesn't include the native C++ layer.
A coworker and I were talking (after a fashion) about an article I read (HTC permission security risk). Basically, the argument came down to whether or not it was possible to log every action that an application was doing. Then someone (an abstract theroetical person) would go through and see if the app was doing what it was supposed to do and not trying to be all malicious like.
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing. Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
Can I get some input one way or the other? Is it completely impractical to even attempt to log what a foriegn application is doing?
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing.
Not so much "hack Dalvik" but "hack the android.* class library, and perhaps a few other things (e.g., java.net).
Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
You might be able to do some fancy pattern matching or something on the output -- given that you have determined patterns of inappropriate actions. Of course, there is also the small matter of having to manually test the app (to generate the output).
Is it completely impractical to even attempt to log what a foriegn application is doing?
From an SDK app? I damn well hope so.
From a device running a modded firmware with the aforementioned changes? I'd say it is impractical unless you have a fairly decent-sized development team, at which point it is merely expensive.
This is both possible and practical if you are compiling your own ROM. Android is based on Linux and I know several projects like this for Linux, like Linux Trace Toolkit. I also know of research into visualizing the results and detecting malicious apps from the results as well.
Another thing functionality like this is often used for is performance and reliability monitoring. You can read about the DTRACE functionality in Solaris to learn more about how this sort of stuff is used in business rather than academia.
Is it possible to programmatically restart the phone from a application (service) running on top of the Dalvik VM?
If the SDK does not provide this functionality, then how about using the NDK and calling some functions provided by the kernel? I know this option is not preferred (not stable enough libs), but if it's the only option, I'll have to consider that as well.
Hopefully not. :-)
If it were possible to restart the phone at will, a malicious app could quietly do it at random intervals and make your life unhappy.
The NDK does not provide you with any additional abilities here, because Android relies on process boundaries and Linux access rights for security, rather than a Java-language sandbox.
Why do you want to do this? Maybe there's some other way to accomplish what you're after.
powermanager.reboot is available since api level 8.
requires reboot permission
I found the correct system calls in Linux that would do the trick and after hours of fiddling around with the NDK/JNI paths, I finally managed to call the function. The result was that I need super-user permission for that. I kind of guessed that this would be the case.
Is there anyway to overcome this problem? Other than rooting the phone, which I'm still trying to avoid.
It's still possible to reboot the phone with adb. I guess that communicates with ddmd or some other daemon, so could it be possible to somehow use the same functionality?