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.
Related
I fully read the documentation of Cordova plugin filesystem. Furthermoe I've been googling without though conclusive explanations.
Particularly, how do the paths stored in the variables in cordova.file.* map the real folders in Android filesystem that you can see on any File Explorer? For example, I cannot save a file into the Downloads folder. I tried file:///android_asset/Download without success.
What exactly is the protocol file:/// and the path file:///android_asset/? What is the "application's sandbox"?
For example, I save a file into cordova.file.cacheDirectory because I need to deal with a temporary file, but I tried to find such file within a file explorer, and I can't find such file. Is it hidden somehow? I can't find it neither in /data/data/<app-id>/cache nor in "file:///data/user/0/com.form.parking.violation/cache/" (real value of that string).
I know, it's too many questions, but I will plan to make this a canonical question, since clear and pedagogical information is very scarce.
Using a 'File Manager' app on device won't give you access to items listed as 'Private' in the documentation you've listed. 'Private' means no other app should be able to see the contents which is sort-of described by "application sandbox". Normally a sandbox is for describing an environment which something can't get out of. If you aren't familiar with multi-user environments it can also mean that others without the right level of permission can't see in.
And unless the device you are testing on is rooted, you won't be able to see those 'private' files like the SQLite database and other files you are interested in unless you use adb from the Android SDK with the adb shell command run-as as described here:
Android ADB access to application databases without root
Note that to grab the files you need to have your Cordova app debuggable by Android Studio (debug mode).
For what is file:///android_asset/ I'll refer to this SO question:
What does file:///android_asset/www/index.html mean?
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 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.
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?
My android application needs another NATIVE application executable to run before the android one, so that they can communicate through sockets. Android application has a JNI layer for handling the client-side communication.
Now i need to bundle up the native executable along with the apk file, so that when it is installed on a device it gets unzipped into either the phone memory or the memory card.
How do i do this?
I tried keeping the native executable in res/asset and in res/raw folders, but they still don't get unzipped in /data/data/ folder.
One way I could find is to use AssetManager and then with help of InputStream and OutputStream, i can write this file onto the device the first time it is run and then use it. But there is no point to write it manually on phone memory as it might eat up the memory. ( the case where if memory card is not present. )
Can anyone help me on how can i achieve this? It would be great if there is an option to unzip the necessary files automatically at the time of installation.
How do i do this?
You don't. You unpack it yourself on first run of your application.
One way I could find is to use AssetManager and then with help of InputStream and OutputStream, i can write this file onto the device the first time it is run and then use it.
Correct.
But there is no point to write it manually on phone memory as it might eat up the memory.
Then why did you want it automatically unpacked there in the first place?
It would be great if there is an option to unzip the necessary files automatically at the time of installation.
No, sorry, this is not possible.
We have the same issue ... the direction we are exploring is to have two separate installs - the first one is the app and the second one is the data-app. When the data-app installs it copies the binary files to the SD card. When we uninstall the data-app it frees up the internal storage.
We don't have this one completely licked yet, and would love to hear other input and maybe find someone to help us by writing a couple of skeletal sample applications for us.
There are so many people who are in this boat (based on my googling) that if this approach doesn't work I suggest we (or someone) set up a generic file delivery web server and generic file delivery Android service and make it available to developers for a very low cost.
This isn't a typical use of OBBs but why not use one? It would then be a file separate to your apk installed in a pre-determined location. It doesn't have to be compressed.