I want to know if there is a way to include your Android bootanimation.zip inside frameworks.apk(or another place not easily accessible) when building from source so that it gets loaded instead of the one in /system/media/bootanimation.zip
So when a user replaces the bootanimation in /system/media it still loads the default one built into frameworks.apk or some other place that Android can access to stop a user from modifying the bootanimation easily.
Or another scenario, a user replaces the bootanimation but then on the next boot Android checks if there is a size, file difference on the bootanimation.zip with a predetermined value(or original file) and if it differs, then it copies a spare bootanimation.zip located somewhere(if possible in frameworks.apk, so users can't get it easily, without decompiling it) and then copies the original bootanimation over the one in /system/media.
Then on the next boot, the bootanimation will be the original one and users will be baffled why it changed again. Is there a way to write such a script to run on boot or include it in some runtime file in /system/bin perhaps?
You can change the default location of the bootanimation.zip, but where would be a good place to hide it and what to rename it too, will also need to keep it small under 5MB and without .zip extension? But this method might be easily discovered.
It is for protecting my work, so others can't take credit for it.
So I just want to make it a little harder for someone that tries to do such a thing.
You can store the boot animation somewhere with a different name. And then implement a service in init.rc for copying your boot animation to /system/media after checking the current bootanimation.zip file's checksum. If the user had replaced the bootanimation.zip then the checksum will be different compared to your bootanimation.zip.
Related
I have an android app that is able to open a certain file type via a VIEW intent.
After a file is opened using my app for the first time, I would like the app to "remember" the file so that the user can choose to open it again from a list of "recent" files inside the app...
My question is: what is the best way to implement this kind of "remembering" - should I:
Automatically copy any files passed to my app into my app's own storage area, and then list "recent/old" files there?
Or, should I record a list of files that my app has been passed previously, and access them via the same path later if necessary? If that is recommended, is there any guarantee that I will be able to access them again later? (I guess not!)
Option 1. seems like more work and doubles the storage space needed for all files passed to my app, but will guarantee the files will be accessible in future. Option 2. is easy if the files are always readable by my app in future, and are not renamed/deleted for some reason - it seems there's no guarantee of that though...
If it helps, I expect most files passed to my app to come from "Downloads" via the user's browser, but some might come from email/other apps etc.
Thanks
I would go with Option #3: drop the proposed feature.
As DeeV pointed out in a now-deleted answer, Option #1 is not a great solution for a "recent files" list. It would be the right option for other verbs than "remember", such as "import".
Option #2 will not work much of the time. Your app needs to support the content scheme, in addition to (or even instead of) the file scheme. By default, you will only have rights to access the content at a content Uri until your process terminates (at best). You may be able to takePersistableUriPermission() to get durable access, but that will not work much of the time — it depends upon whether the other app is granting you such access. Hence, you might have a Uri that you can remember, but remembering will do you little good.
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.
I'm just wondering how the following scenario can be solved:
I want to write a very simple app for my daughter. The app displays 4 colored fields on the activity and through speech output says something like "tap green". She should then tap the green field to get positive feedback. So far, so easy.
I then thought it might be nice if the app would also "grow" as she grows older. Maybe later I want to have a game mode where I display animals, numbers, vehicles, etc., so it would be nice if I could have something like "Shape sets" - basically a set of images along with a description of what the app should say for each image. Also easy enough - all you need is a set of images and an XML file describing the images.
BUT
I'd like to be able to install these "Shape sets" as additional APKs later on, so that I don't have to modify the app every time. I'd like to install the APKs, so that the contents are added to a specific sub folder on the SD card, into which my app looks to enumerate available "Shape sets".
If I ever published the app to the Play Store, other people should also be able to download the "Shape sets" I create (no need for user contributions, though).
Is that possible? If so, what would I have to do to have the Android OS "copy" the contents of an APK to a specific folder (lets say "/TapGame/Shape Sets/Animals") on the SD card? Or is there even another way of achieving what I want that I didn't think of?
The term "plugin architecture" just came to my mind as I wrote the question. Searching using that term I found this question: Extend my android app in different APK
It seems to provide a solution to my problem - I'll investigate this further, but please feel free to suggest other possible solutions!
Is that possible?
Um, sure.
If so, what would I have to do to have the Android OS "copy" the contents of an APK to a specific folder (lets say "/TapGame/Shape Sets/Animals") on the SD card?
Android won't do any of that. You have to do that. You would have to detect that a "shape set" APK was installed (either watching for package-installed broadcasts, scanning all installed apps for ones that seem to be a "shape set", etc.). Then you would have to arrange to copy whatever you wanted to wherever you wanted it, either by:
Asking the "shape set" app to do it (e.g., send a command to some IntentService), or
Using createPackageContext() and trying to do the copying from your main app
Or is there even another way of achieving what I want that I didn't think of?
Um, just use ZIP files that your app downloads itself from a well-known location. That corresponds to Dave Smith's final paragraph of his answer on the question you just linked to in your edit.
Or, just update the main app. I'm not quite certain what effort you think that you are saving otherwise.
Or, just keep the content online, using a Web service to indicate the available "shape sets" and downloading them as needed (with optional caching).
Fascinating question. If you really want to go for plug-ins then OSGi would probably be the way to go, but it's a lot of work to get to know and to use and seems like overkill in this case.
I don't know how your shapes are defined, but they are probably each defined in a separate file-set, providing the shape (maybe a png or jpg?) as well as the audio-file that will be used as a command for this shape. If the folder in which these file-sets are stored is fixed (TapGame/Shape Sets/...) the app could scan the folder each startup and the views could be generated accordingly (in this case, the activity cannot be build entirely in the XML-File, but must be partially done programmatically).
The Plugin-Aps would be rather easy. They are an apk which includes the file sets (jpg and mp3 or whatever). Started once they deposit all these files into the specified folder (they probably check before if these files exist) and then the apk can shut down again and be uninstalled.
on the next startup the Tap Game App would find the new symbols and include them into the game.
This seems rather straight forward to me. Another way would be to actually store the shapes and audio files on the internet and with each start of the App check if the number of shapes and audio-files has changed and create local copies of new ones. This would mean no downloads of apks... probably a more usual approach to the issue.
I am very interested to hear what you make of it, seems like a different approach then the norm, which is always cool to see.
Do you know any way for safe copy cut operation in Android?
I want to make a file manager. I can do them with FileReader/Writer, but as is not safe (if app crashes), I want another safe way to do this.
You should probably design a fail-safe order of operations. For example (just making this up, haven't validated it thoroughly):
Record in a persistent worklist file (/shared preference, etc) what you intend to do
Copy the file
Verify the copy is complete
Only then remove the original
Cleanup the record in the worklist
You should not do the work on the UI thread. You may want to consider doing it in a service to handle the case of huge files (or large numbers of files) which may take a while.
You may also want to consider if you can in some cases use the File.renameTo() method - this would require that the source and destination be on the same partition (ie, both on external storage). Also you would have to make sure that the destination directory exists.
Also put some thought into what you are going to do if the selected object is a directory rather than a file...
For my app I want to keep track of which files have been accessed most recently (for cache management: files used least are first to go out).
Now Android doesn't appear to have a last accessed date function for files, so I'm looking at the next best thing: file.lastModifiedDate(). That gives me the last modified date, which is effectively the creation date.
But when accessing the file I'd like to set this value to the current time. Like Linux's touch command. How can I do this, without actually modifying the file?
This should work:
http://www.java-examples.com/set-last-modified-time-file-or-directory