While the compilation of Android source we can see an image file named persist.img being created. What is it and for what is it used?
persist.img is "persist" which contains data which shouldn't be changed after the device shipped, for example: calibration data of chips(wifi, bt, camera, etc.), certificates and other security related files. For sure even it's "persist" you still can replace it via fastboot, or change things if the devices is rooted, take it for your own risks
It's part of the Android build along with system.img, userdata.img, tombstones.img, recovery.img, etc.
You would alter it if you wanted to modify the build.
Related
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.
I have a small Android application that uses different sets of files (a couple of images, a small SQLite DB and a couple of XML files) depending on the specific task at hand.
I know I can include my files into the main application APK using resources or assets but I would be happy to distribute them in a separated APK.
How can I create a data-only APK file?
How can I distribute it? In particular, do I have to do anything special for a data-only package (for example for associating it to the main application package in some way)?
(I'm intentioned to give the user a link to the data package and ask him to install it. No automatic installation required.)
How can I install my files into the internal or into the external storage area of my application? Is it possible at all to install files into the internal storage area created by the main application installer? Do I have to set any particular permission for this?
My approach to this would be to create a wrapper app that's nothing but a content-provider and serves up the files per request by your main app. This would allow you to supply different data packages for the user -- you could even have your main app select between those relatively easily.
It looks like that the commonly accepted way to have the same application with different contents (or styles, or configurations) is to use an Android Library Project for the common code (that is: the whole application, the "engine", the "app framework") and a standard Android Application Project for the contents (that is: an application that actually contains just data). A little bit confusing, just because the "library" here is actually the whole "app", but this seems to be the way to go.
More in detail:
Create an Android Library Application and put into it as much code as you can (all of the non-changing stuff). Please note that this library cannot be launched and cannot be distributed alone. It must be included in a hosting application.
Create a standard Android Application. Include your library into this project. Put in /res and in /asset all of your data (files, XML, etc.).
Compile everything and distribute.
Repeat this cycle every time you need a different version. Different because of data, style, configuration or anything else. Publish the resulting app with a new name.
For what regards me, I'm not completely satisfied by this approach.
A possible alternative is preprocessing the source code with Ruby, Python, Perl, GIT, bash, Ant, Maven, Rake or any other tool that is able to read a file from here, make some change here and there, and write the file there.
The general outline is something like this:
Make a "template" application. Leave your /res and /assset empty.
Run a custom-made script. The script reads a configuration file, copy the /res and /asset files from your repository into the project /res and /asset directories, changes some Java source file and creates/changes some XML file.
Compile and distribute (with a new name, of course).
Using GIT or other SCMs, you just make a new branch for every new version and compile it. Not very elegant (because it can strongly interfere with the normal use of the SCM) but...
There are a few example of these approaches on the web. I'm not completely satisfied by them, either.
Frankly, what the Android ecosystem should offer to solve this problem is some kind of "in-app package manager". Something like the Eclipse Update Manager. This would allow us to use the same application framework to handle different scenarios.
As an alternative, a solid, officially-supported, template-based code-generation mechanism would be nice. Something in the spirit of "Software Production Line": https://en.wikipedia.org/wiki/Software_production_line . Have a look at fw4spl, for example: http://code.google.com/p/fw4spl/ .
I have some configuration I want to save it in my Android application and read it whenever I need , for instance, the server URL that it should try to access like that.
Is there any similar mechanism like web.config in ASP.NET available in Android?
A central configuration file that can be set up manually and then read by the application? Any help would be appreciated!
We use a .properties file in assets folder. It works out very well for us as we support multiple carriers with this, write to it (in case some values, sent from server, need to change. This is done at app start time, thus making our code configurable from server).
You can throw things like that into your strings.xml file. But, since you can't actually modify these values in real-time (since it's a distributed application rather than running on a server), throwing it into a constants class is quite acceptable.
Use Shared Preferences.
Here's a link Shared Preferences
You can use sq lite database files for it. You have a native API to read and write those and on top of that a command line tool.
If you want to create an XML file instead, then it's no different than any other xml file (unless you are thinking about the Shared Preferences, which use an xml format to save the data, but I believe it's not the best API for your application).
I was stumped on this too, but came across Managed Configurations in the Android documentation.
Managed configurations, previously known as application restrictions, allow the enterprise administrator to remotely specify settings for apps. This capability is particularly useful for enterprise-approved apps deployed to a managed profile.
It allows you to set a default value in case you rather not getting into the enterprise admistration business but leaves that option open for the future.
There is a caveat. This only works if your app is registered for EMM. Otherwise you will retrieve an empty map of restrictions.
The use case here is deploying the Nexus S as part of an enterprise platform. Users of the phones should not be able to enable USB debugging -- but administrators should be, with a password or something similar.
It seems like this should be possible by deploying custom versions of Settings.apk=com.android.settings and/or SettingsProvider.apk=com.android.providers.settings? Are there any lighter-weight options?
Not sure if this is a development-related question. Anyway, here is how I would do it:
Get Settings.apk from /system/app
Rename Settings.apk to Settings.zip
Now get ./res/xml/development_prefs.xml (an example of this xml is here)
You need to convert this development_prefs.xml from binary to text (you'll need to figure that out yourself, I've never tried it myself).
Remove preference item with key "enable_adb".
Convert development_prefs.xml back to binary format.
Copy it into Settings.zip archive
Rename Settings.zip to Settings.apk
Copy this modified Settings.zip to your phone
One additional note: there are number of folder of format "xml-[locale]", like "xml-ru", "xml-zh-TW" and so on. You should modify all development_prefs.xml from those folder too. Or as another option, you can remove all thos folders altogether, provided you don't need multilingual support.
And if your admins would need to enable adb, they could copy original Settings.apk over to the phone. Or you can write small .apk yourself with this feature alone and just install it side-by-side with modified Settings.apk.
It's good to have consistency in file names.
MyActivity.java contains the public class MyActivity
I would like the xml file with its layout to be called res/layout/MyActivity.xml
But I get an error message saying "Invalid file name: must contain only [a-z0-9_.]"
So two questions:
Why is the character set so limited (not even upper case? Come on!) - Ah - this restriction is probably in place so you will never be screwed by filesystems that don't make a distinction between upper and lower case, like Apple's HFS+ (although see Wikipedia for the gory story http://en.wikipedia.org/wiki/Comparison_of_file_systems#cite_note-note-35-77 )
Which filenames are restricted - all of res? just res/layout? res/layout plus some other folders?
Can anyone confirm 1, and give details on 2?
Thanks,
Peter
Why is the character set so limited
Because the name has to be a valid Java identifier, so you can use constants like R.layout.foo to identify the layout at runtime.
Which filenames are restricted - all
of res? just res/layout? res/layout
plus some other folders?
Anything in res/
Not sure of the reason for #1. Never seen an explanation in any readings about Resources. For #2 from my experience anything that will be used as a id in java e.g., R.drawable.marker, R.string.default_message has to follow those rules of [a-z0-9_].
When using MacOS X as a development platform, almost any developer dealing with cross platform code will sooner or later run into the issue that source code from a Linux/UNIX project cannot be built after download/checkout/clone because the project has two identically named files in a single directory that only vary in case; and on OS X that means you end up with just one file as the second one will overwrite the first one.
Of course HFS+ can be case-sensitive, but this can only be configured when you format a partition and by default all Macs come with preinstalled OS X on a preformatted partition with a case-insensitive HFS+ (as that is the default mode for HFS+). So you would first have to reformat your newly bought Mac and reinstall OS X to achieve that goal. And then be prepared for trouble as many apps rely on case-insensitivity on the Mac; a very famous example is Steam (you cannot run Steam from a case-sensitive HFS+).
And it's not just MacOS. FAT is case-insensitive and while NTFS can be case-sensitive (just like HFS+), it isn't by default. Also I think SMB isn't as per protocol spec (at least older versions). The filesystem used on CDs isn't, and so on.
So I guess to avoid any troubles straight from the beginning, Google thought it's a good idea to force files to be all lower case, in which case it doesn't matter what filesystem you are using or how it is configured. Of course, that's a bit stupid if you can still run into that issue with your source code files, however that these may be mixed case is a decision that predates Android and that has been made by Sun many years before Google even dreamed of that system.