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...
Related
I seem to have reached dead-end as to how may i create a proper model which plays well under a scenario that i have in mind.
The scenario is as follows; User purchases an application from Google play. At run-time i request user credentials (Google account associated with current device) which i then transfer to a web-service. At that point the back-end service tries to Auth user and identify if they have actually purchased the application in question and only then return any data relative to the request. (keep in mind that any request in general, as we are talking about a content based application, to the web-service at any point of the run-time life-cycle must always pass through the above pipe).
Now the reason for the above scenario being so specific is for the following reason;
-I would like everything to be managed by the end service rather than having any Auth process running natively as it may easily get bypassed. What i mean is that as long as anyone can decompile the application on their device, inspect the code, recompile it to their needs, have full access to any file if the device is rooted or even be allowed to clear any data related to the application by simply pressing the "clear data" option from android's application settings..... i do not see any other viable scenario other than the one i described above.
Now having said all of the above my problem is that it seems that Google does not like this specific scenario with both Google play developer api and Google+ api.
So i would really appreciate your comments, thoughts and any related materials you may have to offer in regards to the scenario i mentioned and ways to tackle down this problem.
I don't know of any such API that you can use. Why not try LVL, which would make sure that it's actually downloaded from the Android market? And if it's a paid app, the user must have definitely paid for it.
As far as decompiling is concerned, try Proguard. It's not 100% perfect solution, but it's pretty hard to break it.
Now, coming to the content. If you don't want anyone else to steal your content, then encrypt and save it. You can have a pretty good encryption mechanism that works with your web services, which would ensure that it's very very difficult to break.
What's wrong with using LVL and ProGuard? These tools were designed specifically to address your concerns with license verification and reverse engineering, respectively.
And, really don't worry too much about the one in a thousand people who might try to get your paid app for free. If your app is any good, then you'll be making plenty of sales anyway.
If I've read your proposal correctly, that sounds like a gross violation of your users' privacy and would definitely be a violation of Google's ToS. Why would your users give you their private credentials? They aren't supposed to be given to anyone, so why should they trust you or your systems with them? You would also be liable if you got hacked and credentials were stolen.
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.
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.
I would like to make my application free to install and upgrade for some users only (for example translators, developers and friends, to which else I would have to send the package at every release).
I thought the new licensing would allow that, but it seems not. Since I can't find the answer to whether it is even possible, I am asking right away:
Is it possible to put a paid application on the market and have it either freely istallable or paid, let's say based on the user id (account)?
The easiest thing to do would be to just send them an apk that they can install. They won't get auto updates, but should be able to use it.
I think I saw somewhere in the documentation for in-app billing that it is possible to have "unmanaged" purchases, where it is up to you to manage which user purchased what, either on the device or on a separate server. Maybe it's possible to implement your own purchase server to run in the "Google cloud" using AppEngine?
Anyway, in-app billing is, AFAIK, not available yet, and it seems a tad complicated just to let your friends try your application for free. I've been considering an alternative approach to implementing a try-before you buy scheme:
a) Implement a free App with basic functionality
b) Implement a paid but otherwise empty "unlock" App
c) When users activate "paid" functionality, use the PackageManager to look for the "unlock" app. If it is installed then activate the requested feature, otherwise show a dialog asking the user to go to the market and buy the unlock app.
If you did something similar, you could tell your friends and your testers to download and/or upgrade the unlocked version, and just send them the .apk for the "unlock" app. Furthermore, you would only need to send them the unlock app once.
I think I've seen such "unlock" apps on the market, but I haven't actually tried the approach myself (yet), so I can't guarantee that it will work. Can't see why it shouldn't, though.
For this, if it's possible, you need to have a database for the userId (if you want to manage that)
Or if you want a freely application.. it will need to be a Freeware (a beta version) from the complete application
Else, i don't think it's possible
I was working on understanding what the implications of granting a package a particular permission are. To my utter disbelief I could not find any material which would answer the questions satisfactorily.
1.) What permissions are reserved to be used by whom?
2.) What level of effect does granting a permission to an application have, in security aspects.
3.) What kind of permission does a user need to beware of and understand completely what the repercussion might be (at install time.)
4.) How to identify when an application is misusing a permission granted to it?
I hope with a series of example programs and bits and pieces of documentation we can organize a clear working model for permission on android. I hope people would paste code for relevant examples in an attempt to understand this and help us develop better applications as well as develop user understanding on how secure they are.
thanks
Shouvik
EDITED:What I eventually intend to achieve out of this discussion is that when I cluster a group of permissions, I should be able to get a concise picture of what my application will be capable of doing to my data. I then should be able to weigh those risks with the application installed and determine if its worth the risk. Please note, I am not here to suggest that all apps request perms for malicious use! I am here for that 0.1% of apps which might do it with that intent! =)
Don't take my word for it. Here is a link I came across in the discussion group which puts my idea into a clear perspective. http://groups.google.com/group/android-developers/browse_thread/thread/88b69b590c4d1482/d4bfb0e544d8a3a9?lnk=gst&q=permissions#d4bfb0e544d8a3a9
1) There is a list of permissions (List) a developer can request for his application. Also look at: Security and Permissions
2) If a user installs the application and allows the permissions the application asks for, the application is allowed to do access certain parts of the android system. (for instance, if a application asks the READ_CONTACTS-permission and you grant it, the application can read the contacts from your phonebook, ...)
3) It depends on you feeling concerning security and the trustworthiness of the application you install. If you don't trust the developer of an application, you shouldn't install it.
If an application asks for rights you don't think it really needs, don't install it. (If a simple "ToDo List" app asks permission to make outgoing calls ...)
Which one you should be aware of is a BIG topic - the link under 1) describes the permissions and what an application can do with it - should be a start ...
4) If you grant a permission the application can use it and you can't control in which way it's used. (if you grant GPS, you can't know whether it's updating the status only if you want to or if it's updating every second ...
I don't have enough time at the moment, but maybe I write a little article about this topic on the weekend.
Here is a link I found something that offers a little more than the documentation. Its not much but its a start. Please feel free to pour in your inputs too!
Edit1: So I carried out this little experiment to find out which permissions are not accessible to me as a third party developer. (Pretty dumb of me not to try this earlier, but here is the list FWIW.)