I've got an Android app written in Kivy (Python), which stores local files that should survive an app update (adb install -r).
If the files are stored in a subdirectory of the current directory ("data/data/app_name/files"), I see that they are deleted after update.
However after some experiments I could "solve" this by storing the files in the "data/data/app_name/shared_prefs" directory, which seems to be persistent after updates. By the way, I didn't check but maybe the "data/data/app_name/databases" also is.
Is there a cleaner way of doing things ?
I need to test if I can create a new folder not called shared_prefs nor databases under "data/data/app_name", and if it is persistent.
(this seems kind of a hack because those directories have another dedicated purpose, even though my app is not using them for this dedicated purpose right now)
(NB: I don't want to keep the files outside the app private directory)
There is not a simple way (as in a build hook or similar) right now, but it's something we've specifically discussed in the last few days as the current situation has become a direct problem. I'm not sure what the resolution was, but there will probably be a change in python-for-android to fix it fairly soon.
If you want to keep up to date with this, ask on the kivy mailing list or irc. In particular, knapper_tech was making these changes.
Related
We have a suite of applications that depend on the sharing of a directory/files on external storage.
I've currently opted out of the Android 10 OS changes to scoping (requestLegacyExternalStorage), but this is going away and I've spent many hours trying to find a solution for simply sharing files between applications.
The only solutions that I see offered are:
SAF - which appears to make the user choose through UI. This is completely undesirable.
Use a File Content Provider - the way I understand this, I would have to make the user install an apk with my provider in it before installing any of my applications. Forcing the user to install two apks to run one application is very undesirable. (Yes, they could both be in one apk manifest but who knows which of my suite they will want to install)
Media Store - My understanding is that this also forces the user to pick something he should have no knowledge of - and is really intended for audio, video, image and downloaded directory.
Am I missing a solution for these simple requirements?
Am I missing a solution for these simple requirements?
There is no simple solution. You would basically need to have each app have its own copy of the shared data (to deal with potential uninstalls) and have some sort of synchronization protocol so each app in the suite can inform others about changes to their copy of the data.
Using SAF is the simplest approach for your scenario. Or, move the data off the device into "the cloud".
My understanding is that this also forces the user to pick something he should have no knowledge of
It is the user's device. It is the user's storage. If you put files in a user-visible location on the user's storage, they are the user's files. Your apps are merely one set of tools for working with those files, nothing more.
For a mistake i've overwritten my two project that has same names from android studio and i've dismissed that action today i've tryed to open the main project and i've found no Java classes in it and just the layout's files.
While in the second project to which i was overwritting there is a huge confusion of files and trying to recover the project version by using history of Android Studio even those files has disappeared.
Is it possible in anyway to recover the whole project?
Ps: all that remain from that project is a generated apk.
I have some solutions that may work.
Candidates are:
Search for $AppData$ folders
Search for registries
(Hardest) you may have to preserve the disk state and carve the files yourself..
Cheers, and hope it helped..!
To use the third method(file carving), you may not cause many file operations occur!!(The system may overwrite the previous data)
Hopefully you used source control such as git or svn and it is a simple matter of reverting to the last commit you made, however that is done in your chosen source control. If you don't use source control, perhaps this will serve as a lesson to do so in the future.
I've not used Android Studio, but as a JetBrains product like IntelliJ, it will have a local history record of changes. But that would only record very recent changes.
If that doesn't work, you may have to find out if your chosen operating system backed up the files in a restore point etc.
If you have turned on the file history, you can use that to go to a previous version of the folder. Can also use system restore to go back to a previous date. Can also use third party softwares such as Recuva to get deleted files back.
Make sure to keep a copy of current state somewhere before trying these out.
I am very new to Android development.
Suppose my application has a few static HTML files that I expect will need frequent updates. Suppose I do not want to publish a new version of my application every time a file changes, but I do want to keep these files up-to-date.
What I imagine I could do, is to write a piece of code within the app to go to a known URL and check for updates every few days. If the updated resources bundle is available, the code will download and unpack it, replacing old files, so that the user will see the most resent content.
Questions I have:
- is such approach a good/bad idea? In other words, are their specific disadvantages to doing update in such manner or is it a commoin practice?
- how can I implement something like that? Service? Is there an existing sample piece of code that I could reuse?
Thanks!
If the updated resources bundle is available, the code will download and unpack it, replacing old files, so that the user will see the most resent content.
This is fine, except for the "replacing old files" part. Resources are read-only and cannot be modified at runtime. However, you can adjust your code that uses these files to look for your downloaded-and-cached updated files first and use those, falling back to the resources if updates are not available.
how can I implement something like that?
If your app involves other data synchronization, and you are using something like SyncManager for that, just include these files as part of the synchronization work.
Otherwise, use AlarmManager to arrange to get control every so often to check for updates. You will probably need to use WakefulBroadcastReceiver or my WakefulIntentService to do the actual downloading, as the device will want to fall asleep right away otherwise, if the user is not using the device right then. Use HttpUrlConnection or your favorite HTTP wrapper library to download the files to getFilesDir() or getCacheDir().
Is there a way to save projects on Google Drive when using Android Studio?
I want to access the project from two different locations, but the path to my account under "users" is different, as I use two different usernames on each of the machines.
Since Google Drive folder is under my user folder, the config is wrong if the project is opened from the other machine.
Any advise how I can use the cloud to work on my project?
Thanks!
Trying to use a networked folder to access from two different machines is problematic -- At a minimum, you'll be trying to share local.properties files between the instances, which it's specifically intended to not do. The .idea and .iml files, if you're using Gradle-based projects, aren't intended to be shared among computers. I've seen reports that these can contain absolute paths, which will make sharing them tricky. That's perhaps a bug that could be fixed, but we treat those files as local in Gradle-based projects and not intended to be checked into source control, for example.
I think that's your answer -- set up your project in source control and use that to use it from multiple places. You'll lose the ability to be able to access the project in the exact same in-progress state from multiple places and will need to commit your changes first, but that can sometimes be an advantage, too. The saving of commit history may also be a big benefit -- it's one of those things that sometimes comes in really, really handy when you get your project in a bad state and just want to hit the reset button. Granted, Android Studio has local file history (which is a great feature, but is machine-local), but source control is more resilient.
I'm porting a rather large game engine written in C++ from Windows/Mac to Android. There is a lot of pre-existing code to read assets for games. In addition, there is quite a bit of code doing file system calls (stat'ing the files to make sure they exist, looking up all of the files and directories inside of a directory, etc.)
Right now, I'm focusing on just getting something up and running as quickly as possible, so I'd prefer not to have to rewrite a lot of this. What would be a good way of getting our game assets onto the device and accessing them with minimal changes to our existing standard C++ file system API usage?
I've got some basic support implemented already using the Asset Manager API, but that doesn't support the file system calls and I'm concerned that the 1 MB asset size limit is going to bite me at some point.
I've also looked at OBB, but the tools for creating an OBB file don't look like they are part of the current SDK/NDK. Otherwise, that looks like it would be perfect.
Is it a horrible idea to package up all of the files and just extract them on the SD Card the first time the app is run? Or is there some better way of dealing with this?
Update: I'm also not very concerned on being able to run on a broad range of devices, I am specifically looking at newish tablets, probably the 10.1" Samsung Galaxy tab.
We ran into a similar problem in developing our (data-file-heavy) app, and we ended up deciding to keep the APK tiny and simply download our data files on first run; they're going to have to be downloaded either way, but a small APK works much better on older devices without a lot of internal storage. Plus, you can potentially rig up a way for people to copy over the files directly from their computer if they have a limited data plan or a slow internet connection on their phone.
The "Downloader" sample app in apps-for-android (confusingly buried under "Samples") is almost a fully-implemented solution for this - you can pretty much just plug in the particulars of your data files and let it do the rest.
I wrote an app that relies on putting a good amount of native code into the Android filesystem. I did this by packaging the files into the APK as 'resources'. Instead of pushing them to the SD card, you can put then into the application's private namespace, I.E. /data/data/com.yourdomain.yourapp/nativeFolder.
For details on how to accomplish this, you can see my answer to this question.
It's fairly simple to package to just unpack them on the first run and never worry about them again. Also, since they're under the application's namespace, they should be deleted if/when someone were to decide to delete your app.
EDIT:
This method can be used to put anything into the app's private area; /data/data/com.yourdomain.yourapp/
However, as far as I know, your application has to be the one to create all the folders and sub-folders in this area. Luckily this is fairly easy to do. For example to have your app make a folder:
Process mkdir = Runtime.getRuntime().exec("mkdir " +localPath);
That works as it would in most linux shells. I walked through the assets folder I packaged into my APK, made the corresponding directories and copied all the native files to those directories.
What you might be more concerned with is the limited Android shell. There are many commands that you might want that aren't present. stat for example isn't available, so all of this may be moot if your native code can't make it's system calls.