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.
Related
I am implementing an Android ODM system. I would like to create a VirtualDisplay constructed around an ImageReader so that the process providing the virtual display will receive the series of frames coming out of SurfaceFlinger as HardwareBuffer instances.
The intention is to fetch out the Linux dmabuf handle to each received HardwareBuffer by using AHardwareBuffer_fromHardwareBuffer() to get the corresponding native object, then convert it to an EGLImage with eglCreateNativeClientBufferANDROID() and then finally use eglExportDMABUFImageMESA() to obtain the dmabuf filedescriptor.
The critical piece of API -- AHardwareBuffer_fromHardwareBuffer() -- lives in the native library called "libandroid". Google documentation (see https://source.android.com/devices/architecture/images/vndk_design_android_o.pdf) explicitly indicates that vendor programs are prohibited from using API in libandroid.
This seems strange, because libandroid is already exposed in the application NDK. I think this means that backward portability in all future Android releases is therefore already demanded of libandroid.
Is there any existing way that I can make my vendor program link against this API? If not, could AHardwareBuffer_fromHardwareBuffer() be migrated out to the VNDK in a similar way as some of the other native C++ API's related to AHardwareBuffer have been?
Updated:
It's a pre-installed service that needs (in addition to doing these VirtualDisplay and ImageReader mechanics) to do some interaction with a custom HAL (so: not anything that implements one of the standard Google HIDL interfaces) that my customer is implementing.
I think that relegates us to needing to pre-install into the /vendor partition, right? I don't know whether this technically speaking makes me a "VNDK process", but the restriction against linking against libandroid kicks in anytime that I put "vendor: true" into the Blueprint file.
This pre-installed service sits in the AOSP tree because I'd like to sign it with the platform key so that the service can set its android:persistent property in AndroidManifest.xml to avoid it being subject to arbitrary shutdown from ActivityManager.
Other pre-installed applications will go badly if this VirtualDisplay doesn't end get instantiated. I'm uncertain what this means for GSI. Maybe you're likely to say that, with a GSI image installed for testing, none of those other preinstalled apps are present either so there's no problem.
Is this process a regular application (APK that provides Activities, Services, etc.) that just happens to be pre-installed on the device? I'd imagine it is if you're using VirtualDisplay and ImageReader. If so, there should be no problem using libandroid.
The restriction on libandroid is specifically for VNDK processes, i.e. lower level parts of the system. The restriction is there because several things in libandroid depend on the Android Framework, ART runtime, etc. as well as unversioned and non-fixed internal interfaces to them. So the usual versioning of VNDK-available libraries, where literally vndk binaries from old versions of the OS must work on newer versions of the OS, doesn't work for libandroid because of those dependencies on non-stable internal interfaces.
But if you're writing something that sits above the framework and is only using public APIs, then it's not a VNDK process and those restrictions don't apply.
(Note: I work on Android and have been involved in AHardwareBuffer APIs. But I'm not a VNDK expert nor an expert on the rules around vendor processes and vendor-preinstalled applications. So take this as reflecting my own personal understanding, and not an official statement from the Android team: if there's official documentation that contradicts what I've said, it's probably right and I'm wrong.)
Game mod apps like XmodGames are certainly able to read another process's memory, because it needs to get some variables which belong to the game's process.
It is known that on Android it needs root and on iOS jailbreak.
So how does it manage to do this programmatically, because as far as I know, Android has no API for reading another process's memory, iOS also.
It looks like the mod uses some low-level kernel syscalls or something.
Have you taken a look on IPC and AIDL?
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 want to access Android API classes outside an Android project. For example is it possible to get an object to the Context of the device connected to a machine or the running emulator?
This will allow access to a system services like PowerManager or ActivityManager outside an Android device. If not via Context object, is there any other way to access the system services for a device/avd outside Android?
No way. Distributed android API classes are merely stubs good enough to compile against them.
Even most innocent stuff is stubbed out to throw RuntimeException on invocation. If you like to know status of the system, you will have to use SDK tools. Or write app exposing android objects via some remote access technology
I very much doubt that it is possible. The distributed SDK classes do not include many parts of the internal API. See, for example, this thread. Besides, what use would there be to have a system service object like PowerManager without a system (or an emulation of one) to back it up?
It sounds like what you're trying to do is not really access things on the device, as much as remotely control the device. In this case, there are some external tools that you should look into. The tools are mainly focused on testing, and are based on instrumentation for apps. You can look at robotium and monkeyrunner, to start with, as they provide a bit of functionality that might help you accomplish what you want. Other than that, you can also do what those tools do and write an app which listens for intents from adb, performs actions based on those intents, etc..., but you'll obviously be doing a lot of communication at a high level, so this might not be the most efficient (and I'm not sure how you'd transfer much data, which would be required for real RPC, which it sounds like you want to do).
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.