Every time when I use Cocoonjs Cloud services to convert a HTML5 app to Android app, it automatically adds all the unnecessary android permissions. It makes users confused when downloading app. In fact, all unnecessary permissions such as access to phone book, access the internet, wifi access, location, etc. will be added to the manifest file.
Is there any way I can remove those permissions. Actually, I am using Construct 2 to build the application, then wrap it using ludei cloud services. After that, I received an unsigned apk file.
Thanks in advance.
This may not be a proper answer but the official doc recommends crosswalk instead of Cocoonjs and it seems that crosswalk will let you choose which permissions to use.
Related
I want to build an Android Application in which the user gives permission to my server-side script to read their files.
Seems pretty straight-forward, I've made an app where the application can access the user's files.
However, giving access to the server is a lot harder, thanks to OAuth2.0 which has me confused as hell.
Is it even possible to build what I want, and if so, how can I achieve this? Links to tutorials are also accepted.
This is the library I used at a previous job and it saved me a lot of the hassle in dealing with the Google API directly. Just be sure to follow the authentication part carefully as you need the .ovpn file in order to access your drive.
I just read these topics:
Is there a way to get the source code from an APK file?
How to avoid reverse engineering of an APK file?
...and realized that you can't develop an android program without being possible for its .apk file to be reverse engineed.
You can use Proguard and tricks but still your code will not be completely hideable.
So if you want to make an app completely close-source what you have to do?
For example, what Facebook and Snapchat and Messenger (e.g) did so their source codes are not accessible?
Also, another question: if you upload your app on google play, then a user can get your .apk?
Thanks in advance!
Every app may be reverse engineered.
The difference is only time needed to do it.
Proguard is a minimal solution whish requires minimal efforts and provides a level of protection that is enough in most cases.
You may also use other obfuscation tools (for example, DexGuard).
Another way is making shared libraries with Android NDK and using it. Reverse engineering of native binaries is usually more difficult than Java classes.
Probably the only way to completely protect your algorithms is to remove them from user's device - move to a server. In that way application will do a requests, but computation will be performed on your server.
As for extracting APK - it is possible, as Giorgos Pippos wrote.
From what I know, there are programs you can use to extract an apk from your phone. For example APK Extractor is listed in the Play Store.
You can use this kind of apps to get the apks you want.
I have a netscape-based(NPAPI) plugin packed in a .so file inside an apk. Various WebViews may invoke this plugin, if their webpage has the required MIME type.
But, I also want to restrict the plugin's usage to only those who have the permissions to do so.How can I check this at the plugin side?
I've tried implementing the AndroidManifest.xml <permissions> and <uses-permissions> and it does not seem to enforce a check at all.
<uses-permissions> in AndroidManifest.xml is for your app to be able to access system or other apps' APIs.
<permissions> is for your app to limit the target apps to access APIs (receiver action...) by your own app.
If you are asking about how not to let other apps to use your .so file. Then I would tell you that it is not necessary. In Android, every application is sandboxed. Other apps are not able to use your library .so file.
If you are asking about how to let some WebView in your app use the library while not to let others do, then I would say that permission is not what you are looking for. Why don't you just have an attribute to indicate whether the webview needs the plugin or not.
I need ur help..!
I m creating an app in android. The apps use the functions in the other apps which are already present. I want my app to be standalone. I can't use the functions in those app.
To be more clear, If i create an app for making video calls. The app needs to use the functions in the phone apps. can i just create an instance and use the functions or should i redo all the functions which are required?
It will be helpful if i get to know what will happen wen the app is inserted in the code base and compiled.? where ll the R.java file get created?
Could u suggest me some links to get a detail info about it?
developer.android.com is really useful when it comes to explaining the various features of android development, as well as some great code samples.
When you say you are using the functions of other apps, are you using intents or checking if the app is installed?
If there is an app that has the functionality you need, you can always set a home page that tells the user that these apps will be needed or change your application so it uses the features in android and not the third party apps.
Hope that helps!
If the apps don't provide an API or intent-filter for what you want to do, you cannot include/integrate them easily.
Unless you have a license to use components from the other apps and have access to their source code, you are going to have to re-implement the functionality you need from scratch or from a combination of available platform capabilities, libraries, and appropriately licensed example code.
(If you were content to leverage exported capabilities of other apps that had actually been installed on the device, you could do some things via intents. But you seemed to say this was not acceptable, that you needed to take capability from apps that would not be installed.)
I am writing an Android application that uses some functionality that has been published under the Apache 2.0 license. The functionality is available in 2 ways:
As java code
As an intent in an Android application.
Being the typical developer that I am, I don't want to make the user install a separate application so that they can use my own application - because it would definitely put me off using the application if I had to.
On the other hand, doing the work to get the application up and running using the Java code will take much longer.
My questions are thus:
What are most developers doing now? Are they using intents from other apps?
Does it matter to the average consumer that they need to download a separate application to make it work?
In my application EmailAlbum, I first depended on the presence of OpenIntents OIFileManager on the user phone to pick a file on SDCard or chose a destination folder for exporting a generated file.
Later, I integrated my own version of the code of OIFileManager in my app's source code for several reasons:
Depending on another app for basic (but essential) application features is like a suicide. If your app can't really live without the other app and this app is not installed on most devices, your app won't get used. Most people want apps that work on first start.
Another app was on the market which was providing it's own (bad) implementation of the same intent and was making my app crash... users having it installed on their phone thought that was my app's fault.
Providing a consistent UI was not possible.
I think using public Intents is great to allow people to chose from various applications to extend your applications features or to reuse the content generated by your application. BUT your application has to be able to live on its own, depending only on standard apps provided with ALL android devices (ie. not even depending on Google proprietary apps if you want your app to be able to be used on devices which have not been approved by Google, those which come without the Android Market or GMail).
Most developers are going to use a common intent (phone call, web browser, camera, etc.) to call an activity. If your app replaces one of these common intents, then you shouldn't have anything to worry about.
Developers do sometimes include intents to use other (non-common apps). One example that comes to my mind is OpenWatch that provides an API for other developers to build on. Of course, in this case, if you are using a bluetooth watch like this, then you most likely already have OpenWatch installed, therefore it isn't much of a bother to get another app that builds on top of it.
If you think people are going to use it, I'd say provide an API.
Might also want to take a look at here: http://www.openintents.org/en/
I think even google had an app at one time that depended on a third party package. At application startup the user was greeted with a dialogue that asked him to download said package. If he declined, the respective functionality was disabled.
But I'd only use that approach for tech savvy users, the regular joe will much likely be put off by it. If the functionality isn't crucial, just use it as an added bonus and leave it out otherwise.