Let's say I have an app which does something (exactly what is irrelevant, as this is a very generic question), and I want other third-party developers to be able to expand the functionality of my application through an add-on like system. Just to give you an example of what I mean, I might develop an SMS app for which someone else could add support for Facebook chat, AIM etc. Is this possible, and if so, how would you go about doing this?
I'm pretty sure this isn't allowed due to it would allow a 3rd party to circumvent the permission system in Android. If could get an App to load code not shipped with it then they could get elevated permissions without the user knowing. Even if you had to request permissions when installing the 3rd party plugin those permissions don't have to include the permissions of the App you are augmenting. Therefore, if that code got loaded into the same process as the App it would be allowed to execute at the level of permissions the orignal App had instead of the ones it presented to the user.
Therefore, your only option is to leverage intents, but intents don't have to invoke Activites. You could build a service, or broadcast method to do some processing and give back the results to the original activity. Read up on them and see if you can leverage them. Android's system is a system of collaborating applications not plugins.
http://developer.android.com/guide/topics/intents/intents-filters.html
I should probably add that what I would want is not to call an activity from another application to do its stuff, but rather to integrate the functionality of another application into my own activities somehow.
If "functionality" is "UI", that is generally not possible, outside of RemoteViews (the same tech used for app widgets).
If "functionality" is anything else, follow chubbard's answer -- the plugin can expose an API to you and/or you can expose an API to it.
Integrating the functionality may look a bit different than what you expect. You can leverage the functionality of another application into your own by using an intent to start an activity in the other application. Let's say that your app is app A and all the others on the device
are the set of apps : you have to hope that some app in can accept an intent and do what you want. If you want data back, then in addition you have to hope for that functionality as well. If permissions are involved, you have to hope that the application is set up for that as well.
This is always the challenge with cooperation between apps: they all have to have the API for cooperation.
So, the best approach is to use an intent.
Related
I found this from other answer
Runtime.getRuntime().exec("pm clear PACKAGE_NAME");
but this is working for own app only, i can not clear data of other app using this.
Will this work after converting my app as system app?
Do we have any official link on how to create system app and test it?
It cannot be done without Root Permissions for oblivious security reasons.
System Apps can execute few actions more than User Apps however they don't have access to other folders.
Imagine an App that could clear all 3rd App's data...it could be very dangerous.
I have a use case that requires the user to confirm device credential, and the createConfirmDeviceCredentialIntent method in KeyguardManager perfectly meets my need. However, this method was added since API 21.(reference link) So how can I achieve the same functionality before Android 5.0? I also want to support versions like Android 4.X.
Thanks!
Before 21 level this is certainly not possible on non-rooted device and there is no alternative with regular permissions.
If it is ok to require extra admin permissions, it is probably possible to emulate credential confirmation very loosely, with much more effort, by implementing DeviceAdminReceiver.onPasswordSucceeded. Lock the screen, when password succeeded perform the required action. This may turn out to be relatively complex because the action is not always received (only if status has changed), need to keep last success, communicate with receiver, etc.
As a side note, double check the use case and your design, in most cases when createConfirmDeviceCredentialIntent is used it is actually not required and other design choices may eliminate the need for it.
It was better to provide details of what exactly you are trying to protect. If it is a scenario for accidental access to the device by an unauthorized person and a permanent token is generated, say, from some oauth service, it may be reasonable either to reauthorize through the same service login flow or to store some hmac of original credentials along with token then prompt and re-validate credentials instead of prompting for device credentials. Alternatively, if that is enough for use case, you can use google login to authorize access to your app/token and verify google user is the same for the stored token.
The best answer I have seen for this situation is described in a blog post:
Android Secrets
However, it recreates system classes that are private and calls AOSP code that is not public. My bounty is for a better answer that would not require explicit Class naming inside the project. Perhaps Smart Lock or another awesome security library can be used for the backward compatibility I require.
Here's my scenario:
Currently, my app does NOT require the INTERNET permission and I would love to keep it that way. My app is a financial app where a lot of users don't want to take a chance on an app that can send their data out.
Now, I would like to have some kind of add-on that enables some on-line features, such as DropBox sync and some others which will require the INTERNET permission.
Can an app's add-on request additional permissions, and if not, can anybody suggest a reasonable way to accomplish this?
Thank you!
The suggested answer is to use a sharedUserId in the AndroidManifest and then create a new app with the added permission and this same user ID. This works great for apps where the developer had foreseen this need, but for other apps, adding or changing the sharedUserId causes it to misbehave.
Here's the corresponding Google bug, please star it if you feel this should be addressed:
http://code.google.com/p/android/issues/detail?id=14074
I had a different problem I was trying to solve and decided on add-ons also. The solution I used was to implement the Shared User Id paradigm. My add-on has the same signature, no launcher intent (which means there will be no separate icon on the users device) and a signature based security on the activity calls. This will allow you to implement the above functionality.
The issue you may have is I doubt you can get another application installed using in app purchases. You may need to sell the add-on as a separate app.
Hope this helps...
I have a paid android application which uses the google LVL code to authenticate users.
A company would like to pay me so that their application can include a free version of my application. However, I'm not sure how to accomplish this in a way that won't result in an easily pirated version of my app. Below are some implementation options I am considering, but none of them seem like particularly good ideas. Any suggestions?
I deliver them an apk which does not use the LVL code. They could then package my apk with their app, and install it using the ACTION_VIEW intent. This seems like a bad idea because I think it wouldn't be particularly hard for some rouge user to extract my unsecured apk and distribute it.
Maybe I could build a version that checks to see if their app is installed, and if it is it queries their app for some sort of unlock code. And app will only run if this unlock code succeeds. My main concern about this is that I have no idea if "querying another app" for an unlock code is accomplishable.
This is definitely accomplishable. As already said one way to query the app is by using a content provider. If you are concerned about security you can introduce additional permission that both apps must hold to access the provider. Although since it doubtfull that both apps have the same signature it won't be as effective.
Another way would be if they had a service that you could bind to and request a code or any other authentication. In this case their service can as well validate your apps validity by querying your apps userId and checking a signature via PackageManager.
Sad news is it's alomost impossible to prevent pirating your app anyway. Even with LVL... Since all this can be decompiled and eventually broken. But at least you can make attackers life harder.
For what you are looking to do I would create a jar out of your project and mark it as a library project. That way you can give your application out to your client but they wont be able to see the actual code you have written. Using this method they will be able to call any method directly which would be easier than having to interact with an apk.
I'm sure this is fairly basic, but I don't know quite what to search on to get a concise tutorial. I want to create an app and make it downloadable on the Android Market for free. Then, I want to create one or more apps which are just license keys which open up certain functionality on the free app. What's the best way for the free app to check if the paid apps are present on the device? Is there an easy way to check by package name or do I need to create a content provider in the paid apps which the free app can call to check validity?
Or maybe there's some global memory space (like preferences within an app) which all apps can read/write.
I know one solution that would work, and that I could implement easily - have each paid app call a web service when it first starts and register that phone's IMEI. This would work, but requires internet access, which may or may not be convenient for my app.
As with most Android problems - more than one way to skin a cat. I'm looking for what you guys think is the best (and most secure) approach.
One solution would basically to test if your "license" app is still installed on the phone. Then even if the user change phone, he'll still be able to install the license app using his google account.
You can get the list of installed applications using the following code :
List<ApplicationInfo> list = context.getPackageManager().getInstalledApplications(PackageManager.GET_META_DATA);
Then just find an ApplicationInfo where the packageName member corresponds to the one of your license app.