Is it possible to preserve system data (not SD card data) on Android emulator when it is shutdown?
My specific problem is that I am trying to import a new root certificate into the /system/etc/security/cacerts.bks file, but that requires a restart, and when I do restart the emulator the file gets reverted to original state.
The file is a part of the system image, and is not a part of the files created under .avd folder.
Found a link on how to backup/modify a system image. The comments are not in English, but the commands are pretty straightforward.
I think that I once managed to do this by finding a temporary file that contained the modified /system image of the running emulator, and saving a copy which I later substituted for the initial image in an avd that I made to hack on.
Unfortunately I don't remember where I found the temp file. Playing with it at the moment the file called out in the avd seems to be changing and I can't find indication of any other candidates that are open. Perhaps what I did was copy that while the emulator was still running? At the moment dummy files I create in /system after remounting it writable seem to persist across emulator destruction and recreation without any effort on my part.
Additionally, are you sure that an actual reboot of the emulator is needed, that simply using the adb shell to 'stop' and then 'start' the android framework won't do the trick?
Related
I'm facing an issue trying to get the app root folder, the problem comes in an emulator with Marshmallow. When I do context.getFilesDir() it returns a wrong path:
data/user/0/com.android.appname/files/
When it should be:
data/data/com.android.appname/files/
Somebody know why is this happening and how to solve it or another way to get the right path to the app root folder?
/data/user/0/com.android.appname/files/ is a perfectly valid path to be returned by getFilesDir(). That directory will be usable by your app.
adb is not your app. Its view of the filesystem will be different.
The exact location of where getFilesDir() maps to on the actual filesystem — or where tools like adb will see it — will vary based on several criteria, including OS version, which user account is running your app (remember: Android supports multiple users!), and possibly device manufacturer/custom ROM changes.
I am working on a custom android device using the i.MX53 board from NXP (formerly Freescale). I have the OS source code, various intermediate files, and the final resulting files once produced by another developer (who customized the OS, but has since left our company). I now need to modify the contents of the system partition on these devices. I have attempted to build and load a new system.img file using make_ext4fs.exe and the directory which contains the original collection of files the prior developer must have used. I believe I have created a nearly identical system image, as the one previously used. They are both ext4, 200MB.
There is a utility for this board (called MfgTool) which copies and mounts images automatically for you at the click of a button. That MfgTool successfully writes my image to the device. When I try to boot, however, it fails and just loops with the custom boot image being displayed. If I swap out the new system image and restore the prior one in this process, everything works again. So it has to simply be a matter of getting this system image built correctly.
What might be the cause? What difference in the images might cause this? Is it possible there is a signature needed, or some other kind of protection which I'm failing to account for?
Replace one of the system image service executable with a shell that dump kmsg and logcat to a file (in data partition or external storage for example) and then call the original executable. Then, boot to your previous system and collect those logs.
It turned out that my primary problem was that I need to set the mount point for the image to "system" NOT "/system" when it was created via make_ext4fs despite all documentation out there to the contrary! I figured this out by carefully reading the ASOP source: ...build\tools\releasetools\img_from_target_files.
Of note, after this hurdle, I ran it another problem where the device was acting funky. That turned out to be the result of not having any symbolic links in the image. It seems like at the least you normally have symbolic links directing your "bash" commands to the toolbox binary in system/bin. I don't know how you normally get those, but creating those links and then bundling them into the image fixed that. I suggest checking the bin directory for symbolic links if you manually create a system image like this.
Scenario: After running my app once, I go into the Settings->Apps->App and click Clear Data. Upon trying to run the app again it fails to restore some required files for the app to run properly. The call to context.getExternalFilesDir(null) returns a null pointer. Attempting to create a file using the null pointer tries to create the file in the root folder (ie: "\myFileName.txt") which is not where I want the files to go and a read only part of the system.
After looking through numerous questions on here I can cross of that
This is not a permission issue, if I do not clear the data I can write files till my hearts content.
This also does not seem to be a 'we have left a lock or reference to the file' issue as the folder does not exist, I am not getting a lstat error and lsof is listing no files, even if I can not follow the links, under my package's name.
When I start the app the second time and it fails to write the files because of the null pointer, the system is left in its broken state and only a device reset appears to fix it. If I browse to the Android/data folder in an android file explorer I see a file, not a folder, called 'com.myapps.packag' there. But it has no associated information (It shows up as a ? icon, 0.00B in size, -rw for its stats and no date created/updated.. this looks like empty default information to me).
If I browse into the folder via ADB shell access and do an ls -al on the data folder I get the error in the title:
lstat 'com.myapps.package' failed: Device or resource busy
and that is it.
lsof reports no files open by anything under the packages name. Trying to scan the list of files seems fairly useless as most of them will not resolve (My device is not rooted so I can not get root access to have it display the information properly).
Basically I am at the end of things I could find on here and through Google to try out and see why the second running of the app appears to be failing to create its package folder.
Oh, if it matters I am using Android OS 4.2.2 (API 17)
Can you check what is the state of the media by using Environment.getExternalStorageState()
You can then understand the current state of connection of your app with the external storage.
Returns the current state of the primary "external" storage device.
Returns
one of MEDIA_UNKNOWN, MEDIA_REMOVED, MEDIA_UNMOUNTED, MEDIA_CHECKING, MEDIA_NOFS, MEDIA_MOUNTED, MEDIA_MOUNTED_READ_ONLY, MEDIA_SHARED, MEDIA_BAD_REMOVAL, or MEDIA_UNMOUNTABLE.
http://developer.android.com/reference/android/os/Environment.html#getExternalStorageState%28%29
I am working on a project that needs to store some .txt to android, and get it from the computer for other use. From what I read from the documentation, I know that there are two types of storage: 1 Internal, which is somewhere deep in the phone that is private to the app. 2 External, which includes the SD card and the Internal Storage of the phone. I want to store it to External->Internal, and I am using this line of code to do that:
public String WalkDir = android.os.Environment.getExternalStorageDirectory().getAbsolutePath() + "/Walks/";
When I logged WalkDir, LogCat says "/storage/emulated/0", I stopped the app, checked with the adb shell, and there is no folder "0" but "legacy". I unplugged the phone and plugged it back in, the "Walks" folder is now in the root directory, and I don't need adb shell to access it.
So my question is, can you help explain how this system works? Why did "0" disappear? What is "legacy"? Why is the file in Internal Storage when I unplug&plug it?
Thank you very much!
Those are what in Linux are called symlinks (like shortcuts in Windows) that various system apps in Android are using..
/storage, /sdcard are sym linked folders,that means when you open one of those, it redirects to the original(/data/media/0), as for the 0 is just a multi user feature implemented in android 4.2, but only enabled on tablet androids.
Why do this Sym-Link?: simple so it dosent break apps(not only file explorer type of app, but all apps).
Still dont get, why it would break?.Simple. android api have lots of ways to write/read files from folders, u can do manually,u can get the data path, u can get the sdcard path, etc,etc. so to not break that they just does these sym links, thats why in one app the storage contentents are listed on /sdcard but on others, is /storage, etc,etc. one example of an app that broke because of these changes to android is titanium backup, u need to change the internal storage on it, so it work.
2 mount points pointing to the same storage device and partition.
If you create something in one folder, it will show up in the other. Same applies for deleting stuff.
They do not take away more storage space, as it is only available once but shown twice.
You also don't need to worry about it in any way because file browsers normally set their default directory to one of these locations.
As far as i know, Google changed the mount points in Android 4.2 to /storage/emulated/0/ due to them switching to MTP and EXT4(?) for the sdcard. The other mount points are still there for compatibility.
I’m trying to create an app that is able to access and modify a protected database within /data/data/. This process obviously requires root privileges and I am testing this on a rooted device. The general code to access the SQLite database is complete and works against a test database that is located elsewhere (on /sdcard/).
However when I want the application to access the database within /data/data/, it obviously fails as I am trying to access it as a normal user. I have read on the topic of using the su binary on Android for a bit now, and as far as I understand it usually used to execute shell commands only.
So my initial idea of making this work was to simply change the permissions of the file when the application starts, and change it back when it quits. So before actually bothering with implementing that in the application itself, I used my file explorer to change the permission to rw-rw-rw-. However my application was still not able to open the database.
My next idea was to use the sqlite3 program directly from the shell, but I found out, that my ROM does not come with it, so I would have to distribute it myself (Titanium Backup seems to do that).
However there is something that makes me wonder if there might not be a better way: I am using Root Explorer as my file explorer and it has a built-in way to browse any SQLite database. Given that it does not seem to ship with a custom sqlite3 binary, and that my phone does not have one itself, the access seems to happen using the normal Java tools. But how does the app get root rights then?
Is there a way to make an Android application run as root? Or did I forget setting something for the permissions earlier which prevented me from accessing it? Or does anyone know how Root Explorer does it?
You cannot raise the permissions of an already running process as far as I know. The simplest answer would be to copy it somewhere using the root shell / command line edit it, then copy it back as root again. And yes, I did read your question, just didn't explain the answer fully. Hopefully it's clear now. Not sure if root explorer does that or something else, but it would work.