Can an android app read the memory (the RAM meory) of another app that is running?
Appreciate any pointers.
Do you mean the part of the memory that another app is using for code? Then No.
I assume that someone might find a way, but that would be a security issue, a bug in the system and something that would be adressed in an update. You should stay out of 'other' pieces of RAM.
Or do you mean something like internal memory where you can store a file? An app can save a file in several ways, including some that let other apps read them (example: if you take a picture with a cam-app, you can read it with any gallery app).
Related
I am trying to create an Android application which attempts to retrieve deleted/lost data in Android devices. Is there anyway to do this? I prefer to use Flutter, but willing to use any other tech stack. I think, we might need to use low level languages. Can anyone help me out :)
The thing is, we need to access the segment of memory/storage which is not in the directory and not visible in the file explorer. And we plan to use some algorithms to make sense of the data/bits we get and show it to the user
No this is impossible. You can never do it with an Android application.
Accessing the free space with an android kernel is not possible.
You can try to use memory of the phone pretend to be a hard disk and use EaseUS Data Recovery on Windows
Dear Folks,
I have idea regarding the general Memory Structure and how the OS manages the memory by using different mechanism!
I know that android uses linux kernel and there would be memory management module which would control access the way the memory is allocated to a process.
I recently had my doubt arising when i ran through the Out of memory exception in android.
Consider I have 10 images to be displayed in an activity and when my application opens the said activity all the 10 images would be loaded in memory and will be in the primary memory until my app is pushed to the background. This is how I understood so far regarding the processes in any operation system.
But I also ran into the doubt once the images are loaded in the memory and dispatched to the GUI I mean set to the activity , will not those images be present in primary memory or they will be cleared out from the memory ?
Please help me in understanding this!
I already Google -ed it, but not able to find what I needed
Thanks in Advance
This is completely wrong. You should not load 10 full sized images at all. You usually load them way smaller, directly from the disk into Thumbnails that are not a few megabytes each. You should read this article: https://developer.android.com/training/displaying-bitmaps/load-bitmap.html
I have two questions:
1 . Does the "android:installLocation" tag in the Android manifest affect updates as well as fresh installs?
I have a published app on the market with no "android:installLocation" at all, I am thinking of adding one of the following to the manifest:
android:installLocation="auto"
OR
android:installLocation="preferExternal"
Could this affect users who simply update their app? Could their app be transferred to external storage?
My second question follows on assuming the answer is "yes".
2 . If an app is moved during an update, could the data associated with the app be affected? E.g. databases or shared preference files.
The documentation says "The .apk file is saved on the external storage, but all private user data, databases, optimized .dex files, and extracted native code are saved on the internal device memory."
But I am worried that instead of the normal update, the system may perform a full uninstall/install cycle which would wipe the data. This is unacceptable in my situation.
I'm sorry that I cannot answer this question myself through experimentation however I don't have access to any devices that have external storage. Hopefully someone has done the above and can confirm the result, one way or another.
Extra info:
minSDK = 10
targetSDK = 17
Thanks for your help:
Tim
To answer your first question. Yes. It will affect updates for existing users.
But I am worried that instead of the normal update, the system may
perform a full uninstall/install cycle which would wipe the data. This
is unacceptable in my situation.
The only time this wold happen is if you changed your signing key. It is the key that identiifies your app as unique on Google Play.
Seriously you have nothing to worry about as far as that is concerned.
Your data will stay on internal storage. This is important for security.
Problems will only really occur if you store your data on the sd card and your app on internal storage. You have to account for the fact that the data might not be available. But like I say. for your scenario. You really don't have to worry.
i am developing an application where i need to capture the pictures from camera and save them with in application like in this location "/data/data/com...../images" - what i want to know is this the right approach . if not please suggest but my images should not be available to other app's.
Thanks and Regards,
puneeth
I think every approach have their drawbacks. If the picture should always be there (unless delete through app), I feel it may not be best approach. Otherwise it is Ok to use this approach (which is what I am doing too). Only caution I took was, if picture was deleted by someone, always have a default picture to display there (which saves application crash and other alignment issues).
You’re talking about the Context.getFilesDir() directory. Note that, on older phones with separate SD card storage, this area is likely to be quite limited in size, so be careful about saving lots of images here. You may want to use getExternalCacheDir() or getExternalFilesDir() instead.
I'm running into a problem where files stored in internal memory via context.openFileOutput() are disappearing after I force stop the app. I'll create 2 files, force stop the app, and when I open the app again they're gone. I'm verifying the file's existence by using context.fileList(). My understanding is that this storage is persistent, but I'm not seeing that. Is there something I'm missing?
Your help is greatly appreciated.
I think my question could have been phrased more pointedly. I didn't post code because I was hoping to hear if anyone had similar experiences or knew of any circumstances that would lead to this sort of behavior.
I did some further testing and found that the storage is very persistent; the behavior I was seeing was a compounded blend of inappropriate and inconsistent methods of interacting with the storage, as well as a broken serializer.