I have made my first application for android. It does nothing much just stores some user specified data in SQLiteDatabase and manages it. Now, the app requires no special permission. And while reading the guidelines for publishing it, I came across Pro-Guard. On researching it and reading the developer page on it, I am not able to understand that do I also for a basic app need to set up this pro guard file. I already have a proguard-project.txt in my application folder. It does not have a code, but normal English sentences. What should I do ?
In the project.properties file you can enable Proguard by uncommenting the line that says proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt.
Note:
When you build your application in release mode, either by running ant release or by using the Export Wizard in Eclipse, the build system automatically checks to see if the proguard.config property is set. If it is, ProGuard automatically processes the application's bytecode before packaging everything into an .apk file. Building in debug mode does not invoke ProGuard, because it makes debugging more cumbersome.
This is the documentation.
Related
I am new to android as well as android studio.
From my experience in visual studio, when we test the .exe in another machine we copy the release folder and .exe.
But in android studio I am seeing my colleagues test the debug apk by copying and deploying in other systems using USB drive. seems working also.
May I know what is the consequence of deploying that version? Is the release version relevant only for a play store purpose?
What is the technical difference/consequence other than that debug version contains debug information which may makes it slow or bulky?
Major differences are the debug flag and the signing keys:
For debug builds the apk will be signed with the default debug signing keys with debug flag enabled.
For release keys you will have to explicitly specify the keys to sign with and the debug flag will be turned off so that it cannot be debugged.
Proguard can be turned on for release builds. (also for debug builds but not advised). This step needs to be done explicitly and is false by default.
Note: these things can be altered in your build.config and you can choose what ever permutation and combination you wish.
One important difference is that release APKs typically have had ProGuard (code shrinking) run on them, which detects and removes unused code to reduce the APK size.
From Shrink Your Code and Resources:
Be aware that code shrinking slows down the build time, so you should avoid using it on your debug build if possible. However, it's important that you do enable code shrinking on your final APK used for testing, because it might introduce bugs if you do not sufficiently customize which code to keep.
Your colleagues are probably testing on the debug build type to save time, because it can take significantly longer to build the release APK as opposed to the debug APK.
The all above answers are correct BUT the major difference is that if we use the debug.apk to install the app on the device/emulator we can
*Debug it with debuuger
*Profile the cpu, memory, network with android studio profiler
*See the logs in the logcat
*Debug the layout with layout inspector
if use release.apk we can't use the above features, and we configure some features/libraries to work in specific out put type (Like we can use leakCanary only in debug apk)
The primary difference (if specified otherwise in the build.gradle) between a debug build and a release build is the key with which they are signed. Most app distribution channels would [only] want an app signed with a release key to authenticate the developer. Otherwise, there are no differences.
A release build may also trigger other options like code obfuscation and splits so, look out for these.
However, there are many changes that can be brought about in between these two versions. These should be specified in your build.gradle, if any. So, you should keep an eye there.
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.
When I install my application on device using Eclipse, my app works as expected.
Then in Eclipse I export signed app using platform tools. However, when I install this signed apk file using adb in shell or by opening link to apk in internet it does not work as expected. It launches and runs, but some functionality does not work. The app just crushes.
What am I missing?
A signed build usually goes through a Proguard step. In your app's project.properties file, there's probably an entry that looks like:
proguard.config=proguard.cfg
or
proguard.config=proguard-project.txt
The file after the equals sign contains the Proguard configuration, which, amongst other things, defines rules for what parts of your Java code may be optimized, obfuscated and stripped. You can customize the configuration to make it keep certain elements for which Proguard couldn't automatically determine the correct dependencies. Quite commonly this involves code that is dynamically loaded at runtime, e.g. through reflection. Alternatively, you could disable the Proguard step by putting a dash (#) in front of the relevant line above.
Suppose I have the code and the mapping of the obfuscated app. Can I somehow debug this app within Eclipse?
In Eclipse, Proguard obfuscation is activated only when the app is exported, aka Release Mode.
Debug information are not added in this configuration, as far as I know.
When you build your application in release mode, either by running ant
release or by using the Export Wizard in Eclipse, the build system
automatically checks to see if the proguard.config property is set. If
it is, ProGuard automatically processes the application's bytecode
before packaging everything into an .apk file. Building in debug mode
does not invoke ProGuard, because it makes debugging more cumbersome.
Source
Edit:
It looks some like hackish solutions exist.
Here are two discussions that may help you:
Issue 14469: Optional ability to run proguard on debug builds when using Eclipse ADT
Issue 34019: Allow proguard stripping in debug builds from ADT
Yes you can. Proguard simply makes it difficult to make sense of it by obfuscating the code.
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