I’ve been building some android apps using the website ibuildapp.com
But the thing is that each app requires so many permissions despite the app does not use these features. My question is, can the app send personal information to their servers?
Are you asking if the app can send information to ibuildapp.com servers, or servers in general?
Apps should request permissions only when they need them to provide major functionality. I don't know anything about ibuildapp.com, but if it's requesting a lot of permissions it goes high on my "suspect" list.
permission.READ_CONTACTS, permission.READ_CALENDAR, permission.READ_PROFILE, among others, are not to be handed out lightly! The full list of permissions is listed at
Android.Manifest.Permission javadoc, along with documentation.
I'm an iBuildApp team developer, so I can answer your question. :)
The only reason why we ask all these permissions in every app is that this is how our service works at the current moment.
It has great number of widgets (i.e. page types / functions), every widget has it's own permissions needed. One of our features is that you can manage your app on the fly (modify content, change pages' types etc.), while in most cases there is no necessity to rebuild native app: all the changes will be visible in already built ones. This means that all the modules are built in inside an app (while, as mentioned before, every widget needs it's own permissions).
So in the main: yes, if an app (I assume not specifically our app, but any app) asks for some permissions then it can potentially use them in "bad" way.
But as for us: no. We're not interested in your personal data. We're only interested in providing an excellent service.
Hi i'm ibuildapp android developer.
You can unzip recieved apk file and edit manifest file. As soon as you've done zip it.
Related
I need to increase the security of my android app. Actually my android app. will not be for Google play Store (which provides some licensing options to protect your app.) it will be used for some local companies that used the same app (Desktop app). However, I want to support two versions for my app. which are:
Demo version: for testing aims (after the given period end, the app will stopped!)
Actual version: this if the user want to pay for the app.
What I need:
To increase the security of my app. from installing it another time or on another device for the same user!
For my code I used ProGuard which is a tool provided by Android that lets you obfuscate (make harder to read) your code during packaging. cause there are many reverse-engineering application that used for unpacking the compiled code and viewing the source code (actually I tried some of them and its really amazing to restore the sourse code from .apk!) ..
I think to use the MAC address of each device the app. installed on and then store it into internal database and generate a number form it (in somehow), then ask user enters it (which I the one who knows this number and provider for it) if it is true, the app run else not. But, it's just idea I do not know how this can happen or even from where I can start or even also if that will help!
I tried also SharedPreferences But this does not help!
Actually I do not need for external database on server to read the username or the password for eligible users for app. I need to do that by my app. itself!
In sum please,
How can I protect my app from installing many times for same user or continuing using after testing period ends, etc. (I mean make it more secure)!
any ideas, any suggestions, any useful examples or sites are also desirable.
Sorry for this long question,
Use case:
We have a container App which comes without the needed content preinstalled.
Only after installing the App, users choose which items they want to install. The items here are "city packs", that is data for rendering maps, routing offline etc.
It would be very attractive for several reasons to be able to create Appstore entries for specific cities. However we don't want to get into a mess by really duplicating the App (maintenance overhead, fragmentation, potentiall confusing for users).
That's why I was thinking about something like this:
The additional Appstore entries install a minimal App (I'll name it client App) which essentially just launches the main App with some parameters. On Android that should be possible with Intents, on iOS with custom URL schemes.
Since I don't know of any App using that approach, I wonder if they exist and if it's possible.
There are however 2 potential issues I see with that approach:
If the main App isn't installed when one of the client Apps wants to launch it, the client App can still open the App page in the Appstore. At that point however the client App will lose control and I guess will not be able to have the main App launched with a parameter set. Is that correct?
Would Apple accept such an App?
I'm not sure if what you want to do is possible, but with my experience with Apple it is unlikely that they'd be happy with many different parts of the app being separate... I may be wrong, but that's how I think it'll go...
Have you thought about using in-app purchases? Even if the packs are free i'm sure you can set the cost to 0 and have the data download then?
Why exactly uses-permission
Ex :
<uses-permission>android:name="android.permission.ACCESS_NETWORK_STATE"/>
is needed to access various modules of Android. How is it that just adding one single line that too by the same programmer who is coding it, is actually providing security? I am new to Android programming and this is looking funny. Kindly explain what is the exact use of quoting the <uses-permission>
Google made a whole page to describe the concept. Go through it and you will know the reason.
http://developer.android.com/guide/topics/security/permissions.html
EDIT: In addition to above information. These required permissions are shown to the user at the time of installing the application. They are even visible at the google play store for each app. While most users don't see reqd permissions before installing, some might check them out and if its interfering with their privacy more than required they may not install it or even give bad reviews on play store. These are mentioned in AndroidManifest so Google doesn't have to go through all the scenarios to check what all services the application might request in future.
Whatever permissions you have added in <uses-permission> are actually used later at installation time of your application. User will be asked that this applications require following permissions: Access network states. And if user accepts, the application can be installed. Else application won't be installed.
Refer to this for ore clarification.
I've been training myself up in Android development. I have an idea for a series of apps that all relate to the same basic data store which stores similar/related hobby data. I suppose in my mind access to this data should be similar to how many apps make use contacts. So I started reading up on content providers but from what I can see they don't actually provide the flexibility I require.
What I want is to create say 4 or 5 hobby related apps that record similar and related data however a customer might decide they only need a specific one to start with. Later they might decide that one or more of the other apps might also be useful.
The data the apps store is very similar, the core data is the same. So the obvious choice is a content provider. However I can't see the providers offer the flexibility I require. Firstly how does the 2nd app purchased figure out that a content provider is already available and if so not install its own (this seems to be hardwired in the manifest and there is no programatic control). Secondly how would an app realise there is no content provider and install one (related to point one). Thirdly a new app installed might have a more up to date provider or an older provider!
So I don't think the providers offer what I need. I also notice that the databases are sandboxed and providers seem to be the only method for apps to share persisted data, or is there something I'm missing. It actually makes me wonder how for none default installed content providers how useful providers are!
I suppose an alternative method would be for a customer to purchase and app and then later ad on extra functionality but I'm not sure if this is possible and if so where the information is.
Any help would be appreciated.
Steve
Note to moderators: at first I thought I'd consider this an argumentative question, but now that I think again I think it's a design problem. A good one that shall stay here.
The data the apps store is very similar, the core data is the same. So the obvious choice is a content provider.
Yes.
Firstly how does the 2nd app purchased figure out that a content provider is already available and if so not install its own (this seems to be hardwired in the manifest and there is no programatic control). Secondly how would an app realise there is no content provider and install one (related to point one). Thirdly a new app installed might have a more up to date provider or an older provider!
Many apps do this by having a "library app" available in the Market that provides the common functionality that other apps from you may need. You should ask the user, in any of those apps, to download that library app to enable the underlying functionality of the "UI apps". I don't know, maybe I would take that route... after all, you need to consider the namespace conflict of your content provider(s), hence the "library app".
I suppose an alternative method would be for a customer to purchase and app and then later ad on extra functionality but I'm not sure if this is possible and if so where the information is.
Yes, that's what the in-app billing is for. However, that assumes you'd have one app with different features.
Truth is, it's a good question. It certainly caught me thinking. I believe it's up to you to provide one app featuring a suite of features added by in-app billing, or many apps that share a common functionality provided by one central app also available in the market.
About this last problem, I would do what feels more natural do the user. If the apps are really unrelated, subject-wise, I'd provide different apps. If it's a suite-like product (think Office suites, for example), I'd implement in-app purchases. There is also a small security issue regarding the code visibility (enabling by software versus per-download).
Anyway, in-app purchases are definitely simpler and easier to maintain, in my opinion. But if your apps are that big, it could be a waste of space... not efficient.
My 2 cents.
I have a project for Android. In this project my client asked me following scenario but I'm not sure that it is possible.
They want to create an app-store for android. In this store after developer uploads his application we should wrap this APK file with our APK file (therefore we will have one APK file). This wrapper adds some activities to developer's application in order to able users to check their credits and add credits if they have not enough credit to their account (we don't want to manipulate the developer's code, we just want to add our code into their code). Therefore, when user download and install this application, each time he/she launches the application, our wrapper should be run first and check his/her financial account through Internet, if s/he has enough credit in his account, therefore s/he is free to use the application. If s/he didn't have enough credit we should guide him/her to buy more credit.
The things that I did, I created two sample project to see if I add APK of one to second, may I run that application from second application.
In the first application I just show some text in its activity and in second project (wrapper) I created a button that when I click on it, first project should be run. The result was not satisfactory and I couldn't run it.
I think if I export JAR file from first project and repeat above procedure I'll have better results but because in future we can't ask developers to put JAR file of your application instead of APK, it is not a good idea.
Now, for around a week I was thinking about this story and I couldn't find a way to know how can I consolidate and merge developer's application with our wrapper application.
If you have any suggestion please guide me.
The best way to get something along those lines is going to be as follows.
Setup a few permissions for accessing data from your "store" application. using these same permissions you can detect if any of these apps are installed on their phone.
Your going to want to make a ContentProvider that access the users account info and retrieves that information in your "store" application. Using this content provider you setup an api for accessing user information in the third party apps.
At this point you should have access to all users info (also use credit) and know if they have those applications installed.
Now for the third party apps
My suggestion make a jar file that uses the content provider. Also activities that do some basic stuff like making sure your store is installed and stuff. Bundle that app and have your 3rd party developers use it when making apps.
setup a sample application for using your jar and proper documentation. Very important always so hard when there isn't proper documentation on a jar file. But basically you should have static and helper classes for every aspect of interacting with the users account. And the application should only be asking for permission on using this information.
Here's a few content provider tutorials also a link for manifest settings to get the provider to work with permissions.
http://developer.android.com/guide/topics/providers/content-providers.html
http://thinkandroid.wordpress.com/2010/01/13/writing-your-own-contentprovider/
http://www.devx.com/wireless/Article/41133/1763/page/2
http://about-android.blogspot.com/2010/04/content-provider-example-1.html
http://developer.android.com/guide/topics/manifest/provider-element.html#prmsn
One last thing if you don't want third party application appearing on a user normal launcher for some reason you can request that developers also not add CATEGORY_LAUNCHER to their main activity. In which case you will have to query for the main activity in your store application.