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?
Related
I have been searching for this answer for days and can't find a straightforward answer. I am working on an application written in C++ and that has been ported to Android. I am able to launch and run without too much hassle. My task is to figure out how much RAM our app is using dynamically so that we can handle memory issues dynamically-- which in my mind means that I need to have something in my C++ that can somehow be aware of system characteristics. What I have been able to do, is in my Java code, I can pull certain metrics that belong to my app via the getMemoryInfo call. Like in this post: Programmatically find Android system info
However, I would really like to be able to probe this from our C++ code so that we can handle everything in there...
Is this even possible?
If it is, are the calls unrealistically expensive?
If it is not, how is it possible to manage your memory through the native code rather than the Java code? i.e. If I see that I only have x amount of RAM available, I can dynamically change how much memory I want allocated to something in my C++ code to accommodate what the system has to offer.
Something along the lines of:
Ex. C++ Code:
if (android.os.thisApp.RAM left < 20 )
allocate 10M
else
allocate 20M
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 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).
Suppose you have an application that spawns a local HTTP server on an Android device.
Will there be any advantage to running it in a separate application instead of spawning a separate thread?
Since the heap size is capped per application, I'm assuming that there is more breathing space for memory when running a separate application.
Apart from this, in terms of performance are there any other benefits (or disadvantages) such as a bigger chunk of CPU time?
The one big disadvantage I see that happens when running application components in different threads is that the two parts will be in different DVMs. This can make sharing Preference changes, Listeners, Observers, ect, not work as you would expect, you would also have to make sure all DB access is synchronized.
To counter this point if you synchronization correctly and don't need preferences you can use bundles or AIDL to communicate back and forth from the 2 applications. The best bet is AIDL for 2-way continuous communication, but be aware AIDL can be expensive. The other option for communication is a socket... but this goes against the SDK that is provided. A trick I have learned when doing this is to create an API jar file to include in both applications that will handle all communications (by way of intent or AIDL - blackbox approach).
Personally I think application components that are similar should stay in the same DVM and application unless they can run as stand alone then you have to be the judge of that.
Have you though about running the HTTP server as on ongoing foreground service? This would uncouple your design as well as make things easy and lighter.
Using separate processes can significantly increase the memory footprint of your app. Not only do you get a multiple of the core Dalvik overhead (figure 2-3MB per process), but none of the RAM used by your app can be shared (such as static symbols and such in your code).
Plus you have more CPU overhead because you now need to do IPC for any interaction between those different parts of your app that cross boundaries. And you have a lot more complexity in implementation because you actually need to implement that IPC and figure out how to correctly manage these different parts of the app that are running in isolated address spaces.
For the vast majority of situations, I don't think it is good to use multiple processes.
There is a remote service example in SDK.
If you go with two apps, you will absolutely need remote service. And that is only way to communicate among apps, as my experience.
From my viewpoint, it is not good with the concept "server" to be used on a cell phone. But perhaps you have your reason...
First, you don't need separate application for that, you define another process for your own application. In most cases doing such thing will boost your performance because there is bigger chance that your process will actually run on separated physical process. How ever the Android OS does not support this yet, not event in Android 4.03.
So the only benefit you will get from this is memory, witch in my opinion should not be a reason for opening another process.
In most cases you will get a boost in the performance of you app if you run your server in a separate process via service but not always.
NOTE: service can run in a separate process of its own but for that you have to provide android:service tag in the xml.
One big flaw in this type of design which I think you already know is that , in android each process runs in its own virtual machine.So if you spawn a new process it will get its own VM. Now you yourself consider which is better.Running one VM for the whole application or running two of them. (In most cases I have heard of at least in android 1 VM is more than sufficient to handle everything you need)
Apart from that another flaw is that when you separate the process from the main process of your app e.x you are running your server service in a separate process then it may not shutdown even though your app comes across an exception or error as its a separate process from that of the main process and is not tied to the life cycle of your app anymore.So it can lead to some unexpected behavior and can cause your app to malfunction.
If you are OK to take the risk than go with it otherwise go with threads(I would recommend Asynctask within a service) for the purpose you are seeking as it will provide you with almost the same functionality while being safe inside the application scope/lifecycle.
hope this helps.
I have implemented a simple shared memeory code which is scattered in the two processes(1 acts writer and other acts as reader). But I want manage this SHM code(just like a memory manager),which works independent of any reader/writer processes. By simply giving some hooks/pointers to out side, Can any one suggests me a way for this. or any related code or links regarding related information to this ? One more this Can I use Zygote process to make it happen please suggest ?
An application cannot "share" its memory using plain pointers on a modern operating system. This is something which requires the assistance of the OS, and is highly dependent on the OS in question. For instance, on Linux the best bet would be to use SysV Shared Memory.
Make sure you understand the overhead of multiple process shared memory and ask yourself if just using threads would not suffice. In most cases, threads will suffice, or if not you should re-think your model to use a message passing/shared nothing model.
Have a look at what Boost.Iterprocess can do for you. Especially have a look at the Managed Memory Segments section.