As a part of low-level monitoring application, that needs to monitor some changes in sysfs I should use udev interface instead of inotify. It's pretty clear that most of android devices, and all devices that I really need to run this application on, are using udev for enumerating devices and apply policies. The standard way to interact with udev from C-application is to use libudev (libudev.h), but there is no libudev.so in /lib directory and no include directory at all. So I need to get ARM port of this library or do some workaround here. Please, help me with this problem, since I'm not good in cross-compiling and libudev specific questions.
Note: I have root access on all devices, that I going to run this application on.
Related
Is it possible to disable or remove the root access programmatically on Android? Thank you
A "user" (vs "userdebug" or "eng") build of official Android sources does not feature any sort of root access as a designed feature.
This is what you normally get on a production end-user device from a name brand vendor. In contrast, it is not uncommon for cheap devices of uncertain origin to ship with one of the other build varieties (though that is not necessarily a bad thing, as such half-finished builds often have flaws you need this capability to fix).
Of course nearly any software project has the potentially to be intentionally exploited, and someone's modified customization of Android could include anything under the sun, but those are different topics and far too broad for Stack Overflow where questions must be specific.
In terms of removing exploits or escalation toolkits installed as part of a custom ROM - to remove them, you would have to ask a question that was specific about what they were and how they worked. It is likely however that you would need to have the capability to make lasting changes to the system partition, something that can be as much about hardware locking and bootloader/recovery capabilities as it is about having root access after a complete boot (root can't make a lasting change if the flash is locked; conversely, if you can write to the flash without booting the normal system, root matters less).
I'm trying an app that require to enable a cloud based file system to my device. For this I've to have FUSE support in my Android device . I'm using Android version 4.4.2 on a Asus tablet. However I searched a lot but couldn't find some satisfactory answer to ensure that whether Android support Fuse. Thus I have few question as below ,
1.According to my search result When I run cat /proc/filesystems on an app (Terminal Emulator for Android) that provides Linux terminal I found the result of cat shows "Fuse" there . Is that mean my system support Fuse interface to allow install an user space file system ?
I also found in some forum either Fuse should come as built inside kernel or it should be as fuse.ko module under /system/lib/module . But my system doesn't contain fuse.ko hence does it mean I don't have fuse ?
In short, my question is how to ensure FUSE on android device ? I'm a beginner in Android programming so any help is much appreciated . Thanks in advance.
Modern versions of Android utilize Fuse internally, for example to implement the emulated External Storage.
However, Android is locked down and so neither 3rd party applications, not in most cases the human user, are allowed to add additional filesystems.
For stock Android the only choice will be to implement file-system-like operations within application code, creating a private API that replicates basic file operations, without actually using any files. Anywhere in the code you are writing or porting and need to access one of the remote "files", you would substitute your API for the actual file one. A good example of this would be Android assets - they look a lot like files and have many similar operations, but at runtime they actually are not files but an Android-unique storage mechanism.
Anything else would require modifying Android away from stock configuration (ie, root hacks, etc).
To check what your version of Android on your device supports, download a terminal emulator, and from the command line, run the following snippet of commands minus the parentheses...
"cat /proc/filesystems"
And scroll through the results looking for fuse. This will be a list of supported filesystems weather it be compiled into the kernel or loadable module.
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 compiling an Android ROM from source, and I have one application that I want it to be pre-installed and have it run with root permission.
How can I grant root access to this specific application, without rooting entire ROM?
Hopefully you don't need root...
Typical stock Android ROMs provide root privileges to very few things, in line with the principle of least privilege. Instead, apps are granted the precise permissions they need.
Why exactly do you need this app to have root permissions? You should first look through the list of all the internal unpublished Android permissions to see if one of them does what you want. Since you're building a system app, you can even use signature permissions which are not normally available to other apps. You just need to ensure that your app is signed by the key with which you build the Android ROM - you can then distribute it with the ROM or separately, and it will still have access to the permissions you require.
The advantages of doing it this way are:
If your app is compromised or buggy, the effects are limited.
Your actual Java code has these permissions so there's no need to craft fiddly command lines.
So if you can possibly do your task this way, do.
But if you really do...
If you really do need root, then things get tricky.
You have three options. In order of preference:
Add a new system service.
Add some alternative setuid-root binary which does just what you need.
Modify the su binary to check exactly who is calling it.
If you really do need root, then I would add a new system service. This can run as root. You would then add suitable extra APIs so that your app can call into it - and the permissions can be signature-level so that only your system app can call it. This is the architecturally 'correct' way to do it in Android-land.
The second or third options involve creating some command-line tool which does what you want, but I don't know a secure way for such a tool to check who is calling it. It may be acceptable to allow any app to call this functionality. If so, a new setuid-root executable might be the way to go. However, as I say, I don't know a way to stop other apps running it.
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.