Develop Reference

how to add and manage a JSON file in android OS that is only available to custom system service?

I am developing a new system service in an android project. Can anyone tell me what is the best way to manage create and manage a JSON file that is only accessible to the operating system and not the apps?
Which folder should the JSON file be placed?
How can I read and write this JSON file in my system service?

You could call getFilesDir() from a Context to get a File instance that points to the private application directory. No application (besides yours) will be able to access this directory (access control is granted by Unix file system permissions). This is not valid for rooted devices, though.

Application A accessing a textfile stored in Application B's Internal Memory

My app (App A) need to write a textfile which will be stored under another app's(App B) internal memory. Any idea how to implement this?
I have tried the following:
Under both the AndroidManifest.xml file, I have specified the same android:sharedUserId.
From App A, I used:
filePath = getPackageManager().getPackageInfo("packagename of App B", 0).applicationInfo.dataDir;
to get the path and I have confirmed that the path is correct for App B's internal memory.
But I am getting "java.io.IOException: Permission Denied".
Any idea where I have made mistake?

According to official documentation here,
Technically, another app can read your internal files if you set the file mode to be readable. However, the other app would also need to know your app package name and file names.
It's a do-able thing.
So, create a File object with your filepath and call setReadable on it.
Also, check you're not creating the file with MODE_PRIVATE.

Storing Files on Android that don't get deleted on update or uninstall

I want to store some data to a File (not database) on the Android device. Currently I'm using Context.getFileDir() as the parent directory. However, when you update the app that directory gets deleted. Is there a directory I can use from Context that won't get wacked when the user goes to update the application? Does it have to be the SD Card since that's not always generally available on all phones?

However, when you update the app that directly gets deleted.
No, it doesn't.
Is there a directory I can use from Context that won't get wacked when the user goes to update the application?
No files ever "get wacked when the user goes to update the application".
All files in the on-board flash will "get wacked when the user" uninstalls the app.
Does it have to be the SD Card since that's not always generally available on all phones?
External storage is "generally available" on all Android devices that have the Android Market. It might not be available in specific circumstances (e.g., it is mounted on a host PC, external storage was removable and was actually removed).

If you want to file not to be deleted on uninstall is not possible as you might know that uninstall will delete all the data.
While if you want to save the file on update of code you can use that same method as you are using by creating file on getFileDir(); just you have to check out each time before creating file that if file already exists or not.
If file exists there is no need to create again and if it is not there then create it.
I am assuming that you have done all stuff of file creating properly. Just add below code before creating it.
if(f.exists()) //Where f is your file
{
//Don't create the file, it already exists
}
else
{
//Create the file, since it didn't exist
}

Android: How to copy a SQLite database from one application to another

I have a lite version of an application that uses a SQLite database. I want to copy that database over to the full version of the application when the user installs the full version.
I have written some code to perform the file copy, but the lite database file always comes up as unreadable. The file is there and I can point to it, but I can't read it to perform the copy.
In the Android documentation, we read:
You can save files directly on the
device's internal storage. By default,
files saved to the internal storage
are private to your application and
other applications cannot access them
(nor can the user).
Note the words, "by default".
Is there a way that I can override that default and make the SQLite file readable by my other application?
Thank you.

I believe you have 2 options.
Set the sql database to be world readable on creation. You can do this by setting the appropriate mode parameter in the call to openFileOutput() or openOrCreateDatabase().
Set the sharedUserId attribute in the manifest of both of your applications so that they have the same user ID. This treats both applications as the same user, giving both applications access to the same private set of files.

Write a private access file to another app's files directory

The two apps have the same sharedUserId. When I use this code in app1
context.openFileOutput("/data/data/org.me.app2/files/shared-data.dat", MODE_PRIVATE)
I get an exception telling me that the file contains a path separator.
I am trying to write a file from app1 into app2's storage. (I do of course need to make sure that app2's files directory exists first)
Ideally, I would write to a user specific directory instead of an app specific directory, but I do not know if that can be done

First of all, NEVER use a full path to internal storage like /data/data. Let the operating system give you the path (for example, via Context.getFilesDir() or Environment.getExternalStorageState()). Don't make assumption on where the data is.
Secondly - you already are doing that! Unlike File, Context.openFileOutput already prepends /data/data/[package] to your path, so you don't need to specify that. Just specify the file name.
If you really feel that it's safe and necessary, and if both apps share the same user ID using android:sharedUserId in the manifest, you can get a context of the other app by using Context.createPackageContext() and use CONTEXT_RESTRICTED, then use openFileOutput with only the file name.

Open a FileOutputStream of the needed file, relative to this path:
String filePath = getPackageManager().
getPackageInfo("com.your2ndApp.package", 0).
applicationInfo.dataDir;

Since this is months old I assume you've already solved your problem, but I'll contribute anyway.
Sharing data between apps is what ContentProviders are for. Assuming that you know how to write a ContentProvider and access it, you can access files via ParcelFileDescriptor, which includes constants for the mode in which you create the files.
What you need now is to limit access so that not everybody can read the files through the content provider, and you do that via android permissions. In the manifest of one your apps, the one that will host the files and the content provider, write something like this:
<permission android:name="com.example.android.provider.ACCESS" android:protectionLevel="signature"/>
and in both apps add this:
<uses-permission android:name="com.example.android.provider.ACCESS" />
by using protectionLevel="signature", only apps signed by you can access your content provider, and thus your files.

You should not be overwriting other applications files. That said you have two solutions
Use public external storage (like the SD card) to share the file between the apps.
If the other app is not yours then you can't write to its /data directory, without root that is. Anything is possible with root, just don't expect your users to all have root access.
Edit: Developer owns both applications
Thanks for Roman Kurik for pointing this out. A link to his post on SO
From the android docs
android:sharedUserId
The name of a Linux user ID that will
be shared with other applications. By
default, Android assigns each
application its own unique user ID.
However, if this attribute is set to
the same value for two or more
applications, they will all share the
same ID — provided that they are also
signed by the same certificate.
Application with the same user ID can
access each other's data and, if
desired, run in the same process.
So this is exactly the way user id's work in linux, essentially you are the owner of both and have read/write access to both.