IssueTracker

ApplicationContext.java:
@Override
 412     public File getFilesDir() {
 413         synchronized (mSync) {
 414             if (mFilesDir == null) {
 415                 mFilesDir = new File(getDataDirFile(), "files");
 416             }
 417             if (!mFilesDir.exists()) {
 418                 if(!mFilesDir.mkdirs()) {
 419                     Log.w(TAG, "Unable to create files directory");
 420                     return null;
 421                 }
 422                 FileUtils.setPermissions(
 423                         mFilesDir.getPath(),
 424                         FileUtils.S_IRWXU|FileUtils.S_IRWXG|FileUtils.S_IXOTH,
 425                         -1, -1);
 426             }
 427             return mFilesDir;
 428         }
 429     }

Looks like theres an error on creating the directories:
if(!mFilesDir.mkdirs()) {
 419                     Log.w(TAG, "Unable to create files directory");
 420                     return null;
 421                 }

mFilesDir should be the datadir from the current application context
the value of this variable would be interesting.
unfortunately theres no exception on mkdirs, only a false return.

Maybe this commit helps on finding the reason (if it gets merged):
https://review.source.android.com//#change,15143

1) Thank you.
2) I saw src code. But I still have no idea how to fix. Any other test app successfully gets tempFileDir on the same device/emulator.

Jeah but you will see the dirname with the next Version that gets that fix. So you can try it manually and see what happens. The Problem is the mkdirs() method.

It only returns true or false and throws no Exception, so there will be no detail.

Thanks.
* In most cases I get INSTALL_FAILED_DEXOPT during apk installation before this issue becomes reproducible. Is it significant detail?)

if you get this INSTALL_FAILED, there must be an Warning just right before this message:

            } catch (FileNotFoundException e) {
                Log.w(TAG, "Apk not found for dexopt: " + path);
                ret = -1;
            } catch (IOException e) {
                Log.w(TAG, "Exception reading apk: " + path, e);
                ret = -1;

So this Warning will give you the required Information why dexopt is failing. I think thats the reason of returning null, cause there seems to be an error on Installing / starting the App. In Example if a IOException occurs, the datafile dir will return null cause it can not be read.

I'm finding that this happens more often on the MyTouch 4g.

This is our most common crash (as reported by the market) as well, but we've never been able to reproduce it on any of our test devices.  Any app source level workaround for this issue would be welcome.

Auto install,  uninstall apk and start activity with "am start -n ..." can reproduce that.

We've got many reports about this problem - the top crash for us.

After investigation I have noticed that /data/data/<pkg> directory has wrong Linux permissions.
The ApplicationInfo.uid and dir permissions do not match.
I got uid = 10071 and dir with owner set to app_78.
Usually there is no application installed corresponding to  app_78, but
I have found cases when my /data/data/<pkg> directory has permission corresponding to other installed application.
Can not reproduce myself.

We're getting same reports from market as well...weird!

[Comment deleted]

Is it possible this is caused the app being opened in a certain way inside another activity?  Like from a "download finished" or play store or settings dialog?

We are also seeing this problem frequently in the wild. It also seems to affect context.getCacheDir() and context.getExternalCacheDir(). The SDK documentation suggests that getFilesDir() and getCacheDir() should never return null, but evidently they do.

Some of our users also report this error.

java.lang.RuntimeException: Unable to create application com.solidapps.ferienkalender.App: java.lang.NullPointerException
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4247)
at android.app.ActivityThread.access$3000(ActivityThread.java:125)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2071)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4627)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:858)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at com.solidapps.ferienkalender.AppCore.load(AppCore.java:28)
at com.solidapps.ferienkalender.App.onCreate(App.java:29)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:971)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4244)
... 10 more

We are calling this method on the application context though.

A question for #15 and #16 -- are your apps using multiple processes at all?

Hi Chris,
Former droid from the KIR office here. I've just gotten a report of this issue from a user with a GS4, running Android 4.3. My app does not have multiple processes. I call getFilesDir in the onCreate of a Service (calling getFilesDir on the Service object). Let me know if you need more info, I'd be happy to help (although I can't repro the bug myself).

There were some longstanding subtle races in the way that the files / cache / etc directories were being created; fixed in Android 4.4.

Any work around for apps running on older phones?

By way of a workaround, you can catch the exception and try once more.  Once the directory has actually been created (which is the crux of the race condition), subsequent lookups will work fine.

That's roughly the approach of the fix that was applied: in case of error, recheck the precondition to see whether you're the victim of a race.  <https://android.googlesource.com/platform/frameworks/base/+/cc866da37db53df67e9b324815d6377bbd47d71b>

Workaround not working around for me :( I retry after getFilesDir returns null and (at least sometimes) it still returns null. I've seen this on API 10 and 15.

In such a case, is it worth doing:

File filesDir = new File("/data/data/com.mypackage/files");
filesDir.mkDirs();

?

[Comment deleted]

One of my app has this problem on some random Android 2.3 devices (while other apps don't).

On a Galaxy Y, run Android 2.3, it is because the system set wrong owner for the /data/data/<my package> folder. My application is "app_71" but the owner is "app_68".

I tried chmod 777 the folder and the bug is gone.

Reinstall the application can also fix the problem.

Pega por favor

Kkkkkkkk