I'm looking for someone who might be able to suggest ANYTHING that might explain this problem I've been having. I've been having this problem for almost three years, with the same app, and nothing I have tried fixes it, or even explains what's going on. The app is a little game, and it saves its state in three files inside one level of folder, like so:
USERNAME
gamestate1.dat
gameinfo.dat
gamestuff.cfg
So what happens is, people will play the game, then suddenly the next day they'll play it again and data will be wiped. Sometimes all files (and the folder) are gone. Sometimes one or two files are missing. It's not common,but it's happening enough that it's occupying too much support time.
The game itself has nothing in it that deletes files at all. The game doesn't delete. But the files are vanishing somehow anyway. The game is not a hardcore game for hardcore players, so most of my users are tech-ignorant, so I know they're not going in an deleting the files.
The rate of customers complaining that they've lost everything increases exponentially right after I push an update.
Can anyone tell me if there's ANY kind of special situation on android that could cause this, and how I could prevent it? Is some antivirus on some phones? Could it be sectors on the card going bad? I've tried turning Google sync on and off and every which way, and turning sync off seems to reduce the problem without eliminating it.
I'm using JNI and accessing my files with normal C++ file functions-- fopen, fwrite, fread, fclose. I am saving them in the folder returned via getExternalFilesDir(null).getAbsolutePath().
Related
I'm creating an Android app that needs to download a set of images and audio files in order to work properly. Those files will be updated on the server from time to time. On startup, the app will check for updated files and download them.
My concern: The updates/downloads of those files must be completed in an atomic fashion, meaning that the update is successful only if all files have been downloaded. If one file failed to download (reason being poor internet connection, insufficient storage space on the phone, etc), the update should be rolled back.
I feel that implementing something like that from scratch could be a pretty big task, so I first wanted to ask if there's already a library/module, or at least a best practice for implementing something like this.
I feel that implementing something like that from scratch could be a pretty big task.
I disagree:
Your app can creat a temporary private folder (i.e. -tmp-update-20190321_122800) and download all files into this folder.
After all downlads finished without error the app can replace the original files.
So instead of searching for a transaction-multi-filie-download-lib you can use any android-download-lib and you must know how to copy/move/delete files.
I'm running into a problem where files stored in internal memory via context.openFileOutput() are disappearing after I force stop the app. I'll create 2 files, force stop the app, and when I open the app again they're gone. I'm verifying the file's existence by using context.fileList(). My understanding is that this storage is persistent, but I'm not seeing that. Is there something I'm missing?
Your help is greatly appreciated.
I think my question could have been phrased more pointedly. I didn't post code because I was hoping to hear if anyone had similar experiences or knew of any circumstances that would lead to this sort of behavior.
I did some further testing and found that the storage is very persistent; the behavior I was seeing was a compounded blend of inappropriate and inconsistent methods of interacting with the storage, as well as a broken serializer.
Folks,
The project that I am working on requires that a certain video can be played on an android device for x number of times. After that, it must stop playing. When a client gets the video file, he or she also gets another file that contains the Android device ID and the number of times the video can be played. The original file and the metadata file are both encrypted.
My first thought is just to write a video decoder for the video file. Each time the file is played, the decoder first checks if Android device and the count are valid, decrements the count, starts decrypting the data and streaming it to the mpeg-4 decoder shipped with the OS.
I would appreciate your feedback on this idea. Please share your thoughts if you feel there is a better way to do it.
One problem I see is where to store the actual count. Storing it in the file itself won't work as the user can simply backup the original file and replace it after the count exceeds. It has to be stored in some other part of the system that cannot be tampered by the end-user.
Thank you in advance for your help.
Regards,
Peter
Useless to store it anywhere on the actual device, because anywhere an app can touch a user can as well. Best bet is to use a remote server for authorization, but then you get spoofing problems. But your real goal is to make it a nuisance, not worth going around, instead of making it impossible to crack, because you can't.
Okay, the simplest way would be similar to something you first suggested, and needs no further infrastructure: store the information in a file. This is defeated by reloading the file, as you suggested, but even that is a high enough barrier for some.
Defeat reloading the file via obsfucating where you're storing the information. Possibilities include text files (easy to spot), or perhaps image files (like images that are supposedly button images).
Remember, it only takes 1 guy 1 time to point the playback into a recorder, and you have a perfect, DRM-free copy running around in the wild. Remember that you're simply trying to make it easy enough to view legitimately and difficult enough to crack (take the difference of those) that people won't bother cracking it.
I am building the application that will load list of news from the website. Each news/headline has an image. I want to save/cash the images so user does not has to download them again.
Q: In your opinion, what would be a better/more sufficient way: Loading images and saving them on the device or use the CacheManager? At the moment I am using the first solution and everything works fine. However, the website has many categories and even more news per category therefore there are lot of images saved on the device. Is it normal in this type of applications to save the images on the device?
Thanks for your help,
marqs
I don't think you should save the images on the device, because of many reasons:
Why wasting the device space on news images? All the user wants is to read the news and thats it. (In your case maybe open it later, but still - not forever)
You can save it on the device and make the app. delete those files after lets say 24 hours..
The main issue is the privacy issue, when the user is deleting the cache files he thinks all the webs he visited has wiped from the device, but in this case they aren't..
Maybe you can just add a "Clean Cache" button in the app. but after all I wrote I think using the Cache-manager is the best way - just because it was meant for those things exactly..
:)
Rotem
I didn't find a reason to use CacheManager. I used getCacheDir and stored everything on file. I have two levels of cache. First when I fetch it, I store in memory and disk. When in memory gets bigger than 30 objects, I started clearing the memory to make some room for the new images coming. However, I still keep the images around on disk and bring in to memory as needed. I found this to give me the smoothest scrolling. After about an hour, I start expiring the image on disk too.
I've got an app that is heavily based on remote images. They are usually displayed alongside some data in a ListView. A lot of these images are new, and a lot of the old ones will never be seen again.
I'm currently storing all of these images on the SD card in a custom cache directory (ala evancharlton's magnatune app).
I noticed that after about 10 days, the directory totals ~30MB. This is quite a bit more than I expected, and it leads me to believe that I need to come up with a good solution for cleaning out old files... and I just can't think of a great one. Maybe you can help. These are the ideas that I've had:
Delete old files. When the app starts, start a background thread, and delete all files older than X days. This seems to pose a problem, though, in that, if the user actively uses the app, this could make the device sluggish if there are hundreds of files to delete.
After creating the files on the SD card, call new
File("/path/to/file").deleteOnExit(); This will cause all files to be deleted when the VM exits (I don't even know if this method works on Android). This is acceptable, because, even though the files need to be cached for the session, they don't need to be cached for the next session. It seems like this will also slow the device down if there are a lot of files to be deleted when the VM exits.
Delete old files, up to a max number of files. Same as #1, but only delete N number of files at a time. I don't really like this idea, and if the user was very active, it may never be able to catch up and keep the cache directory clean.
That's about all I've got. Any suggestions would be appreciated.
Don't delete them all at once. Delete one every few seconds or something, and the user may not notice.
The VM does not exit normally on Android, so deleteOnExit() will not be reliable.
See #1 above.
You might also consider using AlarmManager to schedule deletion work for the wee hours of the morning. This has a side benefit of a capped CPU hit -- anything that runs truly in the background is capped to ~10% of CPU, so this work will not impact the user even if the user is actually using the device at that hour. You will need to use a WakeLock to keep the device awake while you are deleting things. One possibility is to use my WakefulIntentService for this, as it solves the problem of keeping the device awake and having it do the deletion work off the main application thread.