04-18-2013 04:19 PM
Not a bad move on your part.
It's hard to tell from the stacktrace on which side the error may be coming from.
Could you check in your AndroidManifest and ensure that the WRITE_EXTERNAL_STORAGE permission is there?
04-18-2013 11:52 PM
I have the following in the manifest file.
But I believe the above permission is related to writing to external storage, am I mistaken?
If you look at the stacktrace, there is no doubt that file download succeeds only the first time (if at all) and otherwise, fails at all times. That makes me thing our Android code is probably not the issue.
Can we chat over Skype to review our relevant Android code to confirm that there is no bug
from our app side? My skype id: sunil137.
04-19-2013 10:35 AM
Okay, that's great.
I had just come across some extra information that READ_EXTERNAL_STORAGE was introduced in API level 16, so it won't be recognized in a Gingerbread app. Looks like you're fine in this regard.
You say that everything works error free in 10.0.10.648? It may have been something that was already resolved and will be included in the next public release, but we shall wait for development to confirm.
04-19-2013 11:36 AM
I never said it worked all right in 10.0.10.648. Infact, my z10 does not have that OS release or version number. I updated my Z10 to latest public OS version 10.0.10.99 from the previous 10.0.10.261 version and the problem persists in both.
What is weird is that it is such a basic file writing operation into private internal storage directory for the app tons of Android apps must be doing this, then why is it just us facing these failures?
04-20-2013 05:05 AM
I was wrong when I said “All users reports are coming from 10.0.0.x“. When my app shows an error message to the user it allows them to send the error to me along with some device info which include the Build.DISPLAY value. This value is not the same as the actual device OS version, for example for my dev alpha which is running OS 10.0.10.648 the Build.DISPLAY value is 10.0.0.336
Quickly looking at the emails I received, I see 10.0.0.279, 10.0.0.299, 10.0.0.336, 10.0.0.343 for the Build.DISPLAY value
One more thing, my app has the following permissions:
The app writes to a user selected folder with no errors, the error happens randomly when the app, in some scenarios, tries to write to the cache folder.
Thanks for your help
04-20-2013 05:16 AM
Forgot to mention one more thing, my app is one bar file running on both BB10 and PlayBook. So far there is no reports coming at all from any PlayBook user.
04-22-2013 10:47 AM
Thanks for the extra information.
As you know, random or inconsistent behaviour is always the toughest case extract a root cause.
We'll let internal development have a look and see if they can find anything.
04-24-2013 11:23 AM
Just to remove any conflict if our directory name was causing, we released an updated build for SignEasy-Free App where the internal directory for storing the files was set to orig_docs from the earlier Original_documents.
But the error still occurs while saving to that directory. The other directory signed_docs works fine.
I feel that a 1:1 call with someone from your Android Run Time might help resolve this matter sooner. At least,
reviewing our Android code will ensure that we are not doing anything wrong in our side.
04-24-2013 02:26 PM
getExternalCacheDir() is supposed to map to something that's accessible when you have WRITE_EXTERNAL_STORAGE (i.e. WRITE_EXTERNAL_STORAGE ensures you have the correct gid to access it).
That doesn't appear to be happening here. /data is not accessible to apps, even with this permission.
So to me that looks like the bug. In our case I would expect the root directory to be /sdcard.
04-24-2013 02:35 PM
I just whipped up a quick test app and gave it a shot (on 10.1 though)
The app is basically
04-24 14:30:26.946: D/TestGetExternalCacheDir(96731235): /sdcard/Android/data/tests.getexternalcachedir/cac
It's possible this bug was then fixed for 10.1, or (hopefully not) the runtime gets into a bad state and the return value of this method changes over subsequent calls.