I have a shared library that I build with the Android NDK, which ends up being 80MB (yes, huge!). I absolutely cannot shrink it down in size. The problem is, when the Android application is being installed the shared library cannot fit in /system on my phone because only 300K is free. So when the application tries to run, it crashes with a SIGBUS error since not all of the library is there. Freeing any more space in /system would be near impossible without possibly breaking a lot of things.
So, I was wondering if there is another way to link to this library by putting it on another partition like /data which has 150MB free. Does anyone have any ideas on this?
You can install .so files also to /data/data/YOURPACKAGE/lib/
You'll have to research how to do it, though, since I don't have experience on it.
Edit: take a look at this post: http://www.aton.com/android-native-libraries-for-java-applications/
So, I was wondering if there is another way to link to this library by putting it on another partition like /data which has 150MB free.
You are welcome to write your own firmware.
Otherwise, you cannot change what happens with this sort of thing.
Related
i´m trying to find a way how to delete and restore files in android - not using android file explorer tools or external tools for forensic analysis.
So far i understand that most devices has ext4 file system and that erased data still exist, only metadata are deleted.
I´ve read few articles about forensic analysis but they all use tools.
I guess i have to use Adb shell and find a header of the file and alter it, but haven´t found any explanation how.
Am i heading right direction or wrong ? Any help appreciated.
(I have one rooted and not rooted device, both higher than 5.0 Android)
I'm afraid you will need to use tools. Consider the question, "I want to hammer a nail into mahogany without using tools?" How would you answer that question? A hammer is the natural instrument one would us to accomplish the task. But it's a tool. I suppose you could use a rock, but technically speakinng, that's also why a tool. It's why we talk about prehistoric humans as being tool users, even if they are using tools made out of an axe.
In this particular case, you'll want to take a full image backup of the disk partition which will require root, and then use a program like photorec to recover the deleted files.
I had a problem with my pc and I had to format the c drive without being able to access it, good things is that i only lost my app files, bad news is that I lost my app files hahah (not really laughing at all, more like a crying laugh). I used to test my app in my phone so i have it installed there, i have half of the progress I've made backed up (too bad i didn't change the app's folder, I am gonna do it from now on) but i would reaply like to recover it, so... Is there any way that can be done? If not well... learned the lesson the hard way I guess
You may be able to retrieve the java classes and resources from the apk. First, you can try pulling the apk from your Android device:
How do I get an apk file from an Android device?
Second, try retrieving java files from the apk:
how to extract code of apk file
It is called reverse engineering.
Here's a tool that might help you: https://ibotpeaches.github.io/Apktool/
Hope you will recover your code ;)
I'm porting a rather large game engine written in C++ from Windows/Mac to Android. There is a lot of pre-existing code to read assets for games. In addition, there is quite a bit of code doing file system calls (stat'ing the files to make sure they exist, looking up all of the files and directories inside of a directory, etc.)
Right now, I'm focusing on just getting something up and running as quickly as possible, so I'd prefer not to have to rewrite a lot of this. What would be a good way of getting our game assets onto the device and accessing them with minimal changes to our existing standard C++ file system API usage?
I've got some basic support implemented already using the Asset Manager API, but that doesn't support the file system calls and I'm concerned that the 1 MB asset size limit is going to bite me at some point.
I've also looked at OBB, but the tools for creating an OBB file don't look like they are part of the current SDK/NDK. Otherwise, that looks like it would be perfect.
Is it a horrible idea to package up all of the files and just extract them on the SD Card the first time the app is run? Or is there some better way of dealing with this?
Update: I'm also not very concerned on being able to run on a broad range of devices, I am specifically looking at newish tablets, probably the 10.1" Samsung Galaxy tab.
We ran into a similar problem in developing our (data-file-heavy) app, and we ended up deciding to keep the APK tiny and simply download our data files on first run; they're going to have to be downloaded either way, but a small APK works much better on older devices without a lot of internal storage. Plus, you can potentially rig up a way for people to copy over the files directly from their computer if they have a limited data plan or a slow internet connection on their phone.
The "Downloader" sample app in apps-for-android (confusingly buried under "Samples") is almost a fully-implemented solution for this - you can pretty much just plug in the particulars of your data files and let it do the rest.
I wrote an app that relies on putting a good amount of native code into the Android filesystem. I did this by packaging the files into the APK as 'resources'. Instead of pushing them to the SD card, you can put then into the application's private namespace, I.E. /data/data/com.yourdomain.yourapp/nativeFolder.
For details on how to accomplish this, you can see my answer to this question.
It's fairly simple to package to just unpack them on the first run and never worry about them again. Also, since they're under the application's namespace, they should be deleted if/when someone were to decide to delete your app.
EDIT:
This method can be used to put anything into the app's private area; /data/data/com.yourdomain.yourapp/
However, as far as I know, your application has to be the one to create all the folders and sub-folders in this area. Luckily this is fairly easy to do. For example to have your app make a folder:
Process mkdir = Runtime.getRuntime().exec("mkdir " +localPath);
That works as it would in most linux shells. I walked through the assets folder I packaged into my APK, made the corresponding directories and copied all the native files to those directories.
What you might be more concerned with is the limited Android shell. There are many commands that you might want that aren't present. stat for example isn't available, so all of this may be moot if your native code can't make it's system calls.
I would like to write application (as background service) which will encrypt whole file system totally. The questions are:
Is it possible, such that all Android services will work smoothly? Like, say Microsoft's BitLocker?
If so - can someone point me to some sources/docs?
No this is not possible thought the API.
You'd have to get the source code of Android and try to implement that yourself baking your own custom system image.
However I don't think it is possible at all.
Encrypted file system would be possible only via kernel-mode driver, which means a custom ROM for a device.
Its not clear if you are doing this to be secure, or only in order for a trojan to claim payment for restoring the files ;)
Encrypting files after they have been written in plaintext will leave the plaintext spread around your Flash (or disk) until that space is later reclaimed for new files. Its basically not secure. You have to encrypt before bytes get written to disk.
Android runs on Linux, and device drivers for storage, whilst modular, are compiled into the kernel. So unless you are distributing a custom Android image, you cannot post-install install a driver on someone's device.
There has been discussion like this on the mailing list here.
I am doing a forensic course and as a requirement I have been asked to develop a forensic investigation tool (windows based) for Google's Android OS. The requirement is such that given an image file, the tool should be able to display the databases that the applications are using, call history, messages and etc..
I have little experience in Java but I have no experience in Android development. The research so far has given me nothing on how to go about this. If anyone could point me in the right direction I would much appreciate it.
Thanks in advance.
Step 1 would be mounting the filesystem. Since Android is Linux based, there's a huge array of filesystems available, and individual vendors may or may not decide to write their own filesystems, just for the fun of it. On Windows, your options include ext2fsd or ext2read, among other possibilities.
Once you've got the filesystem mounted, then you get to deal with the per-application data storage. I'd wager a fair amount of applications use SQLite3, because it is an amazing tool. But you'll have to figure out, for each type of data you want to read, where it is stored and in what format. (The standard file(1) tool on Linux systems can come in handy, it knows heuristics that are surprisingly good at showing what type of file you might be dealing with.)
If you have the .apk of an application, a tool such as dex2jar, used in combinaison with something like jd-gui, can get you the JAVA source-code of the application (which can help, if not obfuscated).
After that, an .apk is basically a zip-file -- which means opening it with an unzip-ing application will allow you to get the images and resources it uses.
Then, databases used by Android applications tend to be SQLite, on which you can do SQL queries, using an SQLite client.