2

I'm having a very hard time debugging an Android ANR problem. This ANR is coming on play store and I am not able to reproduce the problem. In our app, we are listening to android.intent.action.MY_PACKAGE_REPLACED broadcast and on some devices we are getting ANR while parsing of File provider.

"main" prio=5 tid=1 Native
 at java.io.UnixFileSystem.checkAccess0 (UnixFileSystem.java)
  at java.io.UnixFileSystem.checkAccess (UnixFileSystem.java:252)
  at java.io.File.exists (File.java:807)
  at android.app.ContextImpl.ensureExternalDirsExistOrFilter (ContextImpl.java:2478)
  at android.app.ContextImpl.getExternalFilesDirs (ContextImpl.java:639)
  at android.content.ContextWrapper.getExternalFilesDirs (ContextWrapper.java:247)
  at androidx.core.content.ContextCompat.getExternalFilesDirs (ContextCompat.java:381)
  at androidx.core.content.FileProvider.parsePathStrategy (FileProvider.java:635)
  at androidx.core.content.FileProvider.getPathStrategy (FileProvider.java:579)

Does anyone know what can usually cause these sorts of ANRs? I could think of app getting updated in Direct Boot mode and not able to access these locations on main thread and causing ANRs but that is based on hunch and could not support it with any strong argument.

1 Answers1

0

The androidx FileProvider has both a PackageManager call and a disk read in it. Androidx should not be be doing these sorts of accesses on the startup path.

In any case, it seems you have a little control over it based on what tags are in your FILE_PROVIDER_PATHS xml. Your trace looks like there is a <external-files-path> tag somewhere, possibly in a third party library.

anrx
  • 1