I want to call functions provided in com_android_bluetooth_hid.cpp in android source from my own app. Target Android versions are >=4.4 and <=5.x. I understand JNI, and can compile my own code and call from my own app.
Would it be possible to call android's library from my app? How
Also, to call functions in that specific cpp file, are BLUETOOTH and BLUETOOTH_ADMIN permissions sufficient or something else (other permission, or root) would be required?
The cleanest way to call Android's CPP code is, generally, copying the relevant pieces to your repository and building as part of your app. Following this approach, your app will only call the public APIs - either Java or C/C++.
But this may not be relevant in cases when this code must run with special permissions, as system service, like mediaserver or Bluetooth stack.
I am afraid that the code you wish to run belongs to this second category, therefore none of the available tricks will not help.
On the other hand, a custom ROM may be a solution you are looking for. It may happen that you don't need to forge a full system. It may be enough to use a rooted device and replace the bluetooth service with your custom one.
I would still advise you to provide the missing callbacks for the service, instead of calling the functions directly from your app: you better not mix contexts between a user-space app and system service.
Related
How does Android perform security checks on native code? Suppose we declare permission X in AndroidManifest.xml, does it mean we inherit that same permission X in our native code?
How does Android perform security checks?
There are basically two ways the permissions are enforced.
First of all on kernel level: each installed app is assigned a unique (linux) user id and each time your app is started Android will spawn a process and sets the user id of that process to whatever your app userid is. Now accessing e.g. the filesystem or certain hardware features like network is enforced by using the standard linux group permission system. E.g. access to network is only allowed for a network group and your app user is part of that group if you request the network permission in your manifest.
Security in userspace like accessing certain ContentProviders or sending broadcast messages and so on simply can't be relayed to the OS. So once you call a method from either Java or native code you can be (pretty) sure that there is some software check in the end that ensures that you can't do things you have no permission for. The NDK API will most probably simply call (maybe indirectly) some Java method so there is probably no need to have separate checks for native and Java code (but Idk exactly how that is done).
It is likely that you can circumvent some of the Java checks by using native code like networking on the UI thread should work (if you have the network permission). It is also possible that there are loopholes that can only be exploited by using native code but that should be rare. It should not matter in the end what type of code you use.
#user827992
the NDK just produce some digested machine code for the dalvik, there aren't API available in C/C++ for Android; you don't have a problem about using a particular set of API that requires a certain permission because you simply can't even code that and access the API in the first place.
Not true, native code written in C/C++ is at compile time of the app compiled in native machine code for the CPU and at runtime executed directly by the CPU, no dalvik involved. You get back to dalvik if you call some Java method via JNI (through the NDK API) though.
Also there is a lot of Android API available through the NDK, thats the reason it exists.
According to the "Android logic" there is no point to do that for at least 2 reasons:
you always need to code some java lines to make your app, so your entry point will always be the java language and your java app; you can't do an apk with only C/C++ code.
the NDK just produce some digested machine code for the dalvik, there aren't API available in C/C++ for Android; you don't have a problem about using a particular set of API that requires a certain permission because you simply can't even code that and access the API in the first place.
In the end just think about an android as a java application where you can code in C/C++ your own business logic for the heavy computational stuff, everything that Google provides you in terms of API and policy is supposed to be related only with the Java language.
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).
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.
Okay, so I was looking for something like answered here. The only problem is I've been looking at that zygote fork code but I have no idea what is going on. I'm trying to figure out where exactly permissions are enforced for native method calls in Android. More basically, I want to know how the Linux Kernel is enforcing permissions. Something like enforcePermission() which I've seen in some of the android source code, except I want to know where it is at the kernel level. If someone can point me in some sort of direction or make sense of what that zygote fork code is doing I'd appreciate the hell out of it.
If that doesn't make sense it's probably because I'm an idiot or something.
Thanks!
What that post says (which is true) is that there is no special enforcePermission()-style call for native code: each permission granted effectively translates into a specific supplementary group id. Individual permissions checks are performed either using the standard Linux permissions/capabilities model, using specific code in IPC routines (so for example when you bind to certain services the services can check the calling processes membership in the appropriate group) or using specific patches the the kernel/libraries (for example network permission is explained here).
I have an apk (or .class, whatever) with a 'public static void main'-method (java style) which does some things. Compiling and installing the apk this gives works fine (from eclipse).
Now from a regular Android app I would like to invoke that code while redirecting its stdin/stdout to Input-/Output- Stream objects. Is this possible? And if so: how? And if not: is there some other way in which I can run an activity in the background with some kind of pipe/io-redirection construction?
Thanks.
Android absolutely supports pipes as well as unix domain sockets. Use of exec is somewhat discouraged, but works at the moment.
See the source of any android terminal emulator with a local shell option for an example of how to do it. Essentially your gui just replaces the terminal emulator, and your engine replaces the shell.
If using exec becomes a problem in the future, you will need to compile your engine as a jni library rather than a stand alone executable. That's not necessarily too hard - just graft it onto the ndk hello-jni example, and have a single jni function that calls main(). Call this from a java thread. Communicate with pipes as before, or rig up some other message passing scheme using jni.
Note that the "use a service" answers are going to require a java wrapper in the service too. As of the moment, you can't make a pure-native service using any supported/endorsed mechanism unless you are the platform vendor making and registering a system service.
Also be aware that your engine will need to be able to save any state, and do so at the same time the java side would need to under the android activity lifecycle (essentially, once you get paused you become killable without further notice)
You'll probably be looking at a Service and Intent based design for your app. The Android design/architecture/philosophy doesn't support streams/pipes between processes. In the case of a chess-like app the UI would be an activity and the engine might be a service. For Android the UI is the most important thing and your design will have to take that into account. When a move is made an intent could be fired off from the UI to the background service which would wrap the engine code (Java or perhaps in C via NDK). Once the reply move is ready, it would be returned back to the UI Activity and displayed. If you can't fit all of the data you want in the Intent, you may need to create a Content Provider which would allow the UI to get the missing elements. Again I'm thinking about a well made app. If the game logic doesn't take too long (or you don't need a completely 'nice' UI experience, i.e. game restart if you leave the game) you may be able to stick everything in one Activity and use an AsyncTask/Thread for game logic.
you can do it with intents :)
check android-developers