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.
Related
Good day.i wanted to know if android storage low,does it affect an app performance?Because same app is fast on another device and same is pretty much lagging on another one which has like 2GB of free memory from 12GB of memory.So they both on same device and i just was wondering should it be considered to the lack of storage or its something wrong with my app?
2 GB of free memory (what you have) is good enough for any small or mid-sized app to perform alright. Problems may occur it the app is highly resource intensive and has a lot of run-time graphics load/unload. You should try checking and optimizing your app if it falls under the first category.
Here are a few official performance tips that might help you: [Link]
Avoid Creating Unnecessary Objects
Prefer Static Over Virtual
Use Static Final For Constants
Avoid Internal Getters/Setters
Use Enhanced For Loop Syntax
Consider Package Instead of Private Access with Private Inner Classes
Avoid Using Floating-Point
Know and Use the Libraries
Use Native Methods Carefully
Use Native Methods Judiciously
Even a private member/function of my class can be accessed by reflection by using setAccessible(true). Is there a way to prevent this kind of access from outside code?
I read something, here on stack-overflow, that I can use SecurityManager for prevention of reflection in applets(not sure how it works, though), but is there a similar mechanism for Android as well? Maybe an annotation or clever-programming?
Taking a step back, what you're observing is a difference in security philosophy, between the Java execution model as originally embodied in JVMs at Sun and the execution model of Android.
The original Java VM design was intended for a system wherein multiple, mutually-suspicious applications (or "applets" in the Java parlance) would simultaneously inhabit a single address space, running in a single VM. Because the designers didn't want one app to be able to mess with another, they went through great pains to define an intra-VM security model that would disallow things such as one object touching the private fields of another object of a different class.
That said, the Java library ended up having various "escape hatches" out of the security model. One of those is setAccessible() on reflection objects, as you note.
Android's model is different: Android uses processes as the security boundary and unit of application isolation, instead of trying to insinuate it into the process as was done with traditional JVMs. This renders moot the entirety of the Java security model, except in that it helps an application "save it from itself." That is, it's good design to not have an object poke into another object's private parts, and the default Java security model provides just that.
Leaving aside the question of people modifying your code, with Android, as an application author, you control all the code that ends up running inside the process of your app. If you choose to include code that calls setAccessible() that's your business. You might be shooting yourself in the foot, but you certainly won't be shooting any other apps' feet, since the Android security model, running as it as at the layer of processes, inherently doesn't let that happen. Likewise, using native code will totally break you out of the Java object model, which allows for the possibility of things going totally higgledy-piggledy in the process but also allows you to express some things in a more productive manner than you could in Java. It's a trade-off, but it's a per-application-developer tradeoff and not one that particularly impacts anything else that's happening on your phone / device.
I know this doesn't directly answer your question, but I hope it provided some useful context.
Is there a way to prevent this kind of access from outside code?
Not really.
is there a similar mechanism for Android as well?
Even if there is (and I am not aware that such a thing exists), anyone can remove it, by decompiling your code (assuming they do not have your source already), getting rid of the protection, and recompiling the code.
Bear in mind that ProGuard, when used properly, will obfuscate your private classes and methods for your production APK builds. That, plus a lack of documentation, will make it tedious for anyone to gain access to those private classes and methods.
I don't believe that you can ever really 100% protect from users using reflection on your project with malicious intent. You can make it more difficult for users to do it by doing things like obfuscating your code, but it is still possible to reflect on the obfuscated code.
I don't believe SecurityManager can be used for the purpose that you are suggesting, though I could be wrong.
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 :-)
Can someone explain why ashmem was created?
I'm browsing through mm/ashmem.c right now. As near as I can tell, the kernel is thinking of ashmem as file-backed memory that can be mmap'd. But then, why go to the trouble of implementing ashmem? It seems like the same functionality could be achieved by mounting a RAM fs and then using filemap/mmap to share memory.
I'm sure that ashmem can do more fancy stuff -- from looking at the code, it seems to have something to do with pinning/unpinning pages?
Ashmem allows processes which are not related by ancestry to share memory maps by name, which are cleaned up automatically.
Plain old anonymous mmaps and System V shared memory lack some of these requirements.
System V shared memory segments stick around when no longer referenced by running programs (which is sometimes a feature, sometimes a nuisance).
Anonymous shared mmaps can be passed from a parent to child processes, which is inflexible since sometimes you want processes not related that way to share memory.
Can someone explain why ashmem was created?
David Turner (a regular on Android NDK) answered this in Why was bionic/libc/include/sys/shm.h removed?:
... System V IPCs have been removed for cupcake. See
bionic/libc/docs/SYSV-IPC.TXT for details.
In brief, System V IPCs are leaky by design and do not play well in
Android's runtime environment where killing processes to make room for
other ones is just normal and very common. The end result is that any
code that relies on these IPCs could end up filling up the kernel's
internal table of SysV IPC keys, something that can only safely be
resolved by a reboot.
We want to provide alternative mechanism in the future that don't have
the same problems. One thing we provide at the moment is ashmem, which
was designed specifically for Android to avoid that kind of problem
(though it's not as well documented as it should). We probably need
something similar for semaphores and/or message queues.
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.