I want to be able to package data in a apk, which is read by my main app.
Is there a way that I can put the data in apk, and then upon install automatically hook that data into the ContentProvider in my main app?
The other possibility is to have each add-on be a content-provider, and have the app look for it, but then I fragment the authorities and I don't have a pre-built list, although I suppose I could "reserve" authorities for expansions if this is the best option.
The other option I understand I might be able to use for data sharing is to run the separate apk's with the same user_id? Any thoughts how I could get this to work would be great too, I tried this but reflection didn't show my addons classes, and it brings up all kinds of dynamic loading questions.
Edit: If it helps, I already have it working using zip files in a folder in the SD, but I want to be able to put that zip into a apk, and write a simple wrapper so that it can be read by my other app.
I plan to do something similar with each add-on being a content provider. My plan is to have each add-on/content-provider have a common meta-data tag that the main app can look for when iterating through the list of all content providers.
I actually achieved this, by using a set authority and then iterating over all the content providers.
So every addon is in addons.myapp.blah1... and then if it matches the beginning addons.myapp I do the load.
Related
Not sure if people notice, but if you create a Xamarin.Forms project, just the simple helloworld created by VisualStudio. It will have a fileprovider added to it when you build. You'll have to go look in the compiled manifest to see it, but it's there. Why is this there?
According to FileProvider doc, reason is "To support URIs", as per Android spec.
FileProvider Class:
Android FileProvider implementation for creating Content URIs to share files with other applications.
This is part of Xamarin's library implementation, that makes it convenient for an app coder to use URIs.
Why is it there?
tl;dr This was the easiest way to make URI communication convenient for all app coders.
For that library code to work, there must be a FileProvider to call.
[SPECULATION FOLLOWS]
Could they have written it in a way that required app coder to:
Add their own FileProvider declaration to AppManifest.
Construct an instance of a FileProvider.
Pass that instance in to the Xamarin URI calls.
Sure. But that would be more work for any Xamarin app coder that uses URIs. So they chose to do it once, for everyone.
Could they have written logic that only added that XML to AppManifest, if app, anywhere in it, made URI calls?
Maybe, but that would take more development time, and be easier to get wrong, because it requires knowledge about whether your app code uses a feature, or doesn't use it.
BACKGROUND INFO
For more info, see official Android doc Sharing files
This is part of newer Androids attempt to maintain user privacy and app security, yet provide mechanisms for apps to share content (without resorting to saving files where ANY app can access them).
This also makes it easier for Android OS to "clean up" when an app is deleted. The old approach of saving shared files in a public place meant that those files did not get deleted when an app was deleted. Sometimes that isn't what you want, so this is a "cleaner" approach to sharing data between apps.
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.
So, I'm trying to use a running application and have it access code of a not yet installed application through its .apk file. I need to access things such as the secondary applications packagename, provider, bundles, data, etc all without installing it onto the phone.
So far from what I understand I can use either one of two things.
1) dexClassLoader. With this option I need to be able to access the .apk file from some sort of storage such as an SD card.
2) pathClassLoader. Seems like the correct option here. Can use JAR/ZIP/APK files with this option.
Essentially I'm trying to load the second application into the first one by binding its code to a running process, I'm just having trouble accessing its code without decompiling it. I guess my question is should I be using/trying the first or second option here, or is a third option available?
While you can dynamically load code from the second application using dexClassLoader, etc., you cannot dynamically add new components to your application. Any component must be statically declared in the AndroidManifest.xml.
So you cannot, for example, "import" an activity from the second apk into your main application. You can access the class for that Activity, but you can't directly start an activity using it.
Depending on your requirements, it might be possible to create a "placeholder" activity in your main application, which creates an instance of the Activity class from the secondary apk and forwards all method calls to that instance. In general, I would not actually suggest this. I suspect it would be very difficult (if not impossible in some cases) to actually do correctly.
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.
I want to create a web page that has two links. One that downloads the agent itself (which is pretty easy, just linking to the APK file with the appropriate MIME types set), and the other to start the install process for the APK downloaded in step one.
I know they can just pull down the bar and click on it, but that can be confusing for users (especially in the overall process we are trying to create). Is there a special URI I can use to start the installation, sort of like the market link of "market://"?
Also, is there a way to get meta-data surrounding where the APK was actually installed from? For example, if the link for the APK is "http://company.com/setting=123", that I can pull in the "setting=123" from the URL? I suspect not, but I figured it couldn't hurt to ask.
You can add url interceptors to your app like it's mentioned here but AFAIK there is no way to do what you are asking.
check open2go.com
it may help you.
example here
http://open2go.com/http://m.getjar.com/mobile/49757/angry-birds-seasons/
open2go.com/ + url
market: schema works to.