Develop Reference

Understanding the Apache Cordova Filesystem for Android

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?

Is there a way to add such folder in Android project that do no get compiled up to **apk**

I was looking for a way to add some such folder in my Android Project that do no get compiled up to my apk file.
Why I need it :-
We need to maintain proper documentation for project (that actually
everybody needs to ;) nothing new),
but I find it very irritating to look out for that documentation
folder again and again.
.
I am open for any way i can make dcocumentain folder easily one
click accessible (I am already doing it thru taskbar sortcut. ) But
I want it to get the ease of version control thru Eclipse likewise we
do it for our project
IDE :- Eclipse

I got a way myself :-
I had an idea that if I create a folder in my application project with
some anonymous name that actually android has not listed in its
directories ("I am talking about the default one like "res", "src",
"anim"......)
Then either it should "raise an error" or should "ignore" it while compiling to form apk file
luckily it ignores any such folder. now i can put all the documentation in my project.
NOTE:-
My answer empirically driven
I had tested it by creating a "Docs" folder and then copied 1 GB of
random data (includes almost all type of files we came across from
multimedia to zipped ones).
Then I build the apk and the size of the apk was in-effective of all
this..
but when i copied the same data to assets it was showing a huge change
in size of my apk file..

Consider using Javadoc in addition or, if possible, instead of any other documentation.

Android jni lib not found when moving app to system app

I've been not able to solve my problem, I look around and I couldn't find a good solution.
The things is that I have an Android app that must be system app. I have my own devices so I'm able to install them on system app.
I'm doing this using a pre-installed app on system app. This app takes the .apk file from assets save it on the data/data and the move it to system/app/ folder.
Everything goes good, except when I launch it, it gets an exception java.lang.ExceptionInInitializerError, this means that the jni lib is not found. Probably because it has not been installed in the /system/lib directory.
Anyone know how can I solve this?
I know one solution is to look for the jni lib in the system and move it to system/lib but I would like to avoid this.
thank you.

Packaging Flash Builder Apps for Android/IOS - assets directory Q

First timer here.
I've been writing an app that's intended to be deployed onto mobile platforms (iOS and Android ). This uses Flash Builder 4.6's android build target - it uses a subdirectory in the /assets/ directory, that contains an arbitrary number of .png files.
I code a directory loader as such:
public function LoadFromDirectory(directoryName:String, store:Vector.<BitmapData>):Boolean
{
//Changed here: this should work on both the development environment, AND the device.
//Guess what...
imageDirectory = File.applicationDirectory.resolvePath("assets/" +directoryString);
//This is triggering on Android. Doesn't do so in ADL. Not tested on iOS yet,
//but come on, if it doesn't work here, it won't work on iOS...
if (!imageDirectory.isDirectory)
{
trace("Directory not found:" +imageDirectory.url);
return false;
}
/*Snip loop through the contents of this directory, loading anything that is
a PNG and storing the bitmapData of all loaded PNGs into the vector, one by one*/
/*This of course, ALL works in ADL*/
}
This works in the air virtual devices, but isn't working on the mobile devices or on deployment. This is where I'm stuck.
Edit: Ok, I've gone and reduced the File code to just one line. I should be using resolvePath for cross-platform compatibility; also, the packager from Flash Builder doesn't see the "assets\" subdirectory unless I put it inside "bin-debug\", because that's where the compiled SWF went.
Still doesn't solve the problem tho - at least for the Android build, I can see the assets folder in the apk (by renaming it to a .zip and extracting it all), and it's the correct one (alongside the app's XML files and the SWF).
The apk installs and runs, but isDirectory still returns false when I debug on the device itself (once again, not on ADL - on the device only). Commenting that entire if...segment will crash the app instead because well, it can't find the assets\ directory.
I'm this close to solving the problem; would appreciate if someone helped me with the final step, because it's taking bloody ages to figure out.
PS: I would love to simply just embed the images in a FLA or SWC which I've done before and it works. Unfortunately, the number and name of images in that particular directory is arbitrary; the only thing that I'm certain of is the supported extensions.
PPS: Usage of this function: LoadImagesFromDirectory("imagesdirectory"), which should look under app:/assets/imagesdirectory in any platform. The Boolean return is for debugging (returns false if a directory with that name doesn't exist.)

...alright, I don't know if this is documented, but apparently I was calling LoadImagesFromDirectory to a directory name that is all caps, because on the PC, the target directory was also in all caps.
So in the test platform, the directory resolved to "app:/assets/IMAGESDIRECTORY".
But upon export, the device showed the directory instead resolved to "app:/assets/Imagesdirectory", therefore making the call to IMAGESDIRECTORY invalid.
Oddly, looking for "Imagesdirectory" works for both the PC and the device without changing folder layout and names.
Looks like I've been Gotcha'd - remember never to give directories names in all caps...

Open and extract .sbf files

I have backed up my messages from my Sony Xperia, and now I want to open the file and export them to excel or something more easy to read, but I can't find a program or tool to do that
I just have the file and i want to open it and extract especific information.
I need some help, thanks!

There's a utility called MotoAndroidDepacker (Google it) - I used it to unpack sbf files for Motorola phones. I'm not sure if it will work in your case, but it's worth giving a try.