After I open the "Profile / debug APK" at the Android Studio for my apps, I found out there is a list of the properties. When I check other's apk, there is none like my apps. Should I care about it or not?
these libraries are from third parties, therefore should be considered as "outside of your responsibility" and most likely, their Manifest.xml does not even have attribute android:debuggable="true".
since you demand "official sources", have a look here, which only confirms what I've wrote:
However, you need to make sure you’re using an APK with debugging enabled.
Related
I am maintaining one existing (very-huge, very-sensitive) Android Application.
The other day, I have received an email from my client that, the Application might be declaring the Permissions that are not actively being used.
For example, they wants me to remove "WRITE_EXTERNAL_STORAGE" permission.
I have removed it and compiled it and run the App. There is NO error at all.
But, just because of that, I don't think I can assume that permission is not actively being used at all.
My question is "Is there anyway I can easily and simply check the permission if it is actively being used ?"
Frankly, I don't want to go through every little detail aspect of that application just to fine out the permission is required or not.
I just don't have time.
My goal is check if the permission is actively being used. If not, remove the permission.
Hope there is an less-time consuming way for that.
Regards
In Android Studio 1.3 & Android Support Library v7:22.2.0, you have solution for it.
Steps:
Update Android Studio to V1.3
Update your Android Support Library to v7:22.2.0
Run Android Lint (Analyse -> Inspect Code), In Lint Error see for Type "Android -> Constant & Resource Type MisMatch", Which shows all methods which requires permission.
Explanation
Android has introduced new annotation #requirespermission.
All SDK methods which requires permission are annotated with #requirespermission.
When we call any sdk method which requires permission without properly checking whether we have permission or not, Android studio will through lint error.
There is a group at Berkeley that wrote a paper about Android permissions. They talk about over-permissions and developed a tool called Stowaway that would analyze your APK for unused permissions. The analysis was based on the app's API calls and their own mapping of the permissions needed for each API call (see the paper for details). The tool throws a flag if there is a permission in the manifest that is not mapped to any of the API calls found in the APK.
For a while, a web-based version of the tool was available at http://www.android-permissions.org/, but it is from the Gingerbread era and was never updated. The page now suggests using PScout.
PScout does a better job than Stowaway at generating the permission maps. However, PScout does not include an APK analyzer, so you will have to manually compare the mappings they provide with API calls made by your app. Unfortunately, if you're interested in maps for versions beyond 5.1.1, you'll have to generate them yourself using the provided PScout code and your own Framework source.
You might also check out the various APK analyzers here to see if they include the functionality you are looking for.
I tried the method suggested by Vasanth but it doesn't work for me. In fact, because my project has flavors and Code Inspection doesn't work for the project with flavors. See https://code.google.com/p/android/issues/detail?id=210073.
But Running Lint from console works. So steps are simple:
Remove permissions from your manifest.
Run Lint for flavor as described here https://stackoverflow.com/a/32708435/1170154.
Open Lint result and find section Correctness > Error MissingPermission: Missing Permissions. It will contain all calls that require permissions.
As of Android Studio 3.3, running Analyze → Inspect Code will inform you of missing permissions under Android → Lint → Correctness → Missing Permissions
Now that my android app is released on the google app store, I would like to continue developing and debugging on the device.
I have a few options:
Delete the app from the device and install a new version during development.
This has disadvantages. I lose the local files saved with the released app, and, when the time comes for the next release, I do not share the same experience as my users while upgrading.
Introduce a minimal change by, say, renaming the package. The two apps are now distinct and can co-exist on the device.
This introduces a superfluous change in the souce tree, with all the headaches that that entails.
If you have avoided these difficulties, what approach have you taken when you continued to develop after release?
I recommend switching to Android Studio and Gradle. Using build types (which I can't link to because I am a n00b and have no reputation), you can easily switch between debug and release builds, and set up your build file to have both on your device at the same time without changing anything in your source or manifest.
The one big gotcha that I failed to understand and bit me in the butt several times until I got it is that in the Build Variants tool window, the selected build variant controls everything. If you choose the release variant:
when you build, it will build an APK with your release keys (if you've set them up in the build files)
when you run the app, it will put the release version on your device
if you try to debug the app, the debugger will not attach because the app is not debuggable
And of course all the reverse if you select the debug build variant.
You have to give up Eclipse, which if you're like me is a sad thing, but I've heard they're planning to add Gradle support to Eclipse at some point.
Just curious if anyone has a step by step tutorial on how to set up Eclipse (or a batch file) for "One Click" deployment of an Android app. Automating such tasks like removing the debuggable setting from the project manifest, exporting the unsigned APK and signing it.
You can use Ant to build, sign, etc. If ant release is not enough, just customize the script to do what you need. There is also some (unofficial) support for Maven.
http://developer.android.com/guide/developing/building/building-cmdline.html
The easiest way (according to me) is to use the Android export-wizard.
Right click on your project->Android tools->Export Signed Application
Package.
(You'll still have to fix your settings -like removing debuggable- manually though).
I created a .apk outside of eclipse using tiggr mobile (http://gotiggr.com)
i have the downloaded .apk and need to sign it - so i thought about running it through eclipse then signing it that way
im having the worse trouble importing it into eclipse.
does anyone have any other suggestions on signing this? i keep getting this message when uploading:
Market does not accept apks signed with the debug certificate. Create a new certificate that is valid for at least 50 years.
Market requires that the certificate used to sign the apk be valid until at least October 22, 2033. Create a new certificate.
Market requires the minSdkVersion to be set to a positive 32-bit integer in AndroidManifest.xml.
thanks for your help!
It would be faster to get the source code into eclipse via retyping it than to try and unsign and explode the apk, edit the manifest, fool the tools and sign the package. The tools can be run at the command line anyways and eclipse would just make it harder.
One problem you have is that there are problems in your manifest. The market requires some attributes set in it that you did not need while doing developer builds. You can open up the apk with anything that will open a zip file. You can edit text files with notepad. You package them up with ant by recreating the build.xml by hand. The instructions for signing things is here:
Android Dev-Guide: Signing your Applications
But what a LOT of work... and I am guessing you will need to do this multiple times just for one release to get the manifest right. Then what do you do when you need to update your program?
Will the service not let you export the code in an easy to use way (because... wow... talk about evil)? Failing that cut and paste will save you time but you will almost certainly want to have it in eclipse or some IDE ready to make changes for your market release and build, package and to sign it.
That's not your issue. I suppose you compiled your app and now you're trying to publish it in the market. To do that, you need a private key whick in turn requires you to have a android market developer account.
Normally you can develop your app and install it into most devices but you can't submit apps to android market without a developer account.
If what you really want is only to import your app to eclipse, I suggest you to create a brand new android project and copy everything into it. It's easier and faster than adjusting everything!
The golden rule is to set debuggable option to off prior to releasing your Android application to the public.
What would happen if I leave (forget to turn off) this option on? I mean, how would it manifest to a user?
I tested and saw no difference.
how would it manifest to a user?
A normal user won't notice the difference.
By the way:
Support for a true debug build. Developers no longer need to add the android:debuggable attribute to the tag in the manifest — the build tools add the attribute automatically. In Eclipse/ADT, all incremental builds are assumed to be debug builds, so the tools insert android:debuggable="true". When exporting a signed release build, the tools do not add the attribute. In Ant, a ant debug command automatically inserts the android:debuggable="true" attribute, while ant release does not. If android:debuggable="true" is manually set, then ant release will actually do a debug build, rather than a release build.
On a standard phone with USB debugging disabled, it will allow any application to debug the App. This will effectively allow any malicious application to gain full access to the App.
See https://labs.mwrinfosecurity.com/blog/2011/07/07/debuggable-apps-in-android-market/ for a detailed description of this problem.
It's possible that it could slow down their mobile device, especially if you have a lot of debug statements in your application. It's also possible that a malicious user could learn more about the inner-workings of your app then you'd like them to.
Regarding the golden rule, you're absolutely right. It's a good idea to turn that off, just to be safe.
It's also possible that a malicious user could learn more about the inner-workings of your app then you'd like them to.
One good practice is to link debugging mode specifically to your unique device id.
#askmo: you can use some tools in the SDK to check if an APK has the debug value. Check the following link:
http://lulachronicles.blogspot.com/2011/04/how-to-check-if-apk-has-flag.html
BR,
Ignacio