I wanted to explore the generated AndroidManifest.xml of my .apk and I realised that the format was not readable.
Both debug and release apks contain the encoded manifest file. How is that possible when progaurd is disabled?
Does Gradle modify the encoding during assemble process?
Is there anyway to disable that feature?
How is that possible when progaurd is disabled?
ProGuard has nothing to do with it. XML (manifest and resources) is converted into a "binary XML" format as part of the build process.
Does Gradle modify the encoding during assemble process?
Not specifically. Creating this binary XML is part of the build tools in general, whether invoked from Gradle, Ant, Eclipse, or whatever.
Is there anyway to disable that feature?
No. There are tools available that can decompile an APK, and some of those will convert the binary XML back into a text representation. Or use aapt dump badging. Or, use an on-device inspector, like App Browser.
The App Browser on-device inspector mentioned by Mark doesn't display the Android manifest very well (since it doesn't resolve resource references). There's a much better view given by App Detective
Related
Taking inspiration from The Twelve-Factor App: V. Build, release, run, I'm working on updating our CI/CD pipeline with these three distinct steps in mind for an app being built with react-native-web.
Specifically, I want to:
Build: generate an environment agnostic artifact of the code for each platform (web, android, ios)
Release: take an artifact and a config file (API URLs, API keys, debug settings, etc), and release to each platform
This is trivial for web, which is what The Twelve-Factor App had in mind. My question is how do I read a config file on mobile platforms and how can I incorporate this with react-native-web build artifacts? Does my artifact need to contain all of the source code and dependencies so I can pull in the config at release time and build then?
Ideally, each artifact would contain code compiled for each platform that somehow knows how to pull in a config file and do something with it. Next best would be to have the source code for each platform that I can compile with a config file at release time. Third best is have a way to give each distribution enough information at release time so it can request the config at runtime.
Full disclosure, I know nothing about building and deploying mobile apps so I apologize if there is an obvious solution for this!
It's similar for Android. Once the build binary is created it's immutable.
So unfortunately that negates option #1. We can't do anything else with the binary once we build it.
I think for react-native option two is the best approach.
Essentially you'll need to build the apps at release time once you have resolved what your configs need to be. That avoids any overhead of loading stuff at runtime in option #3 and still matches nicely to Twelve Factor. You'll still have a mobile binary that matches the same configuration as your release type.
For actually reading those values, you can just drop the config file into the project's root and we can help with the setup to pull them in.
I'll be glad to discuss those details if you'd like.
UPDATE:
Anything iOS does we can do (almost as well)
Current build tools compile all code into bytecode classes.dex and compress all resrouces into resrouces.arc but res/raw is left untouched.
This gives us a place to inject our files.
From there, the app will be able to read and parse at runtime.
For iOS, the build and (non-App Store) release process works like this at a high level:
Archive your project in Xcode, which results in an .xcarchive artifact.
Export your archive which signs and generates an .ipa file.
Either host this .ipa file yourself (with some additional metadata files) or upload it to a service like HockeyApp for distribution.
There are a few ways that you can manage config inside an Xcode project. One fairly common and straightforward way is to use the info.plist file to store custom keys and values. The app can then look up and use these values at runtime.
In the scenario you describe, it sounds like you want to be able to inject specific config values after step 2 but before step 3. Fortunately, the .ipa file generated during step 2 can be extracted, which will reveal a Payload folder containing an .app file. This file can be inspected, and inside you will see, amongst other things, the app's Info.plist. Modifying this file will allow for injection of whatever config values you want to set.
This will save needing to manage configs inside the Xcode project, and creating a separate archive for each configuration of the app. However what this doesn't solve is step 3. You are still going to need to distribute each configured .ipa file separately.
In android studio's build.gradle file,we can use shrinkresources set to true to shrinkify our app.Also can use minifyenabled and proguard options as well.
But in xamarin, How can I use these options?
I use proguard in my app as it referred in xamarin doc.but didn't find any use of it (I mean my app size didn't get reduced).My simple app is having around 18Mb in size.If anyone have experience using proguard in xamarin,please paste a sample file here also explain how you accomplished this.So others can also benefited.
I know you're asking specifically about the proguard and minifyenabled features of Android Studio but if the intent is specifically to reduce the size of your application, you should configure a more aggressive linking strategy.
Right click android project
Under "Build" select "Android Build" (or "iOS Build")
Select "Link All" for "Linker behavior" dropdown
Make sure this is only for Release or Ad-Hoc configurations, depending on your distribution strategy.
Linker Configuration Workflow:
Run app on a physical device for desired configuration (Release/Ad-Hoc)
Test functionality until "TypeInitializationException" or similar exception occurs
Add the type/field/method to the configuration file
Rinse and repeat until the application is stable
If you don't like the configuration file, you can also use the PreserveAttribute. If the linker is stripping out classes in one of your PCLs that don't have access to this attribute, you can define your own attribute in that PCL called PreserverAttribute because the linker is just looking for an attribute with that name, not necessary of a specific type.
The linker works by analyzing code paths and removing what it believes to be unused references. If you use dependency injection, the linker won't understand which references it needs to keep around so this can take some time but it can drastically reduce the size of your application and you only need to do it once. You can follow the same steps above for iOS as well.
Bonus Make sure "Strip native debugging symbols" is checked in the build options. Its set by default but some disgruntled coworker could have unchecked it.
Additional Resources:
Linking on iOS
Linking on Android
Proguard only can reduce an APK size if it contains a large number of unused classes (e.g. included because of libraries). Therefore it can only reduce the size of the classes.dex file in your APK.
However an APK usually contains a large number of other files - they will not be touched by Proguard.
You should open the generated APK file in a ZIP viewer and see what elements take the space. If it is the classes.dex file it is only a matter of Proguard configuration.
I'm adding a job in Jenkins to analyze an android project, but I can't get it to take into account the xml files (in res/ and subdirectories).
My sonar.properties:
# required metadata
sonar.projectKey=AndroidProj
sonar.projectName=AndroidProj
sonar.projectVersion=1.0
# path to source directories (required)
sonar.sources=src
sonar.binaries=bin/classes
# The value of the property must be the key of the language.
sonar.language=java
sonar.sourceEncoding=UTF-8
sonar.profile=Android Lint
What this gives me in the SonarQube web UI is only the java files (and indeed sonar.language=java should be an indication of this), so how could I go to get a Lint check on the xml files?
Setting sonar.language=xml doesn't go well with sonar.profile=Android Lint.
As SonarQueb does not correctly support multi-language projects, the Android plugin indeed only reports issues on Java files.
Our goal is obviously to report also issues on XML files as soon as the multi-language support is ready. You can vote for the following ticket and watch it to know the progress: http://jira.codehaus.org/browse/SONAR-926
For anyone who stumbled upon this issue with later versions of SonarQube (I am using 5.3), you need the following things:
Android Plugin installed
XML Plugin installed
remove the "sonar.language" property so that sonar can detect the languages used there by default
add your res folder to your "sonar.sources" property. Mine looks like this:
property "sonar.sources", "src/main/java,src/main/res"
(defined in a sonarqube properties block in gradle).
I am developing an android email client application and Calling webservices using ksoap2 library and also writing some encryption algorithm to encrypt data in my client.
In some websites I have read "It is possible to decompile the apk using some decompilers". (i.e.) get the source code from apk file.
But I want to secure my code. Don't show the encryption algorithm code after decompilation or don't want to decomplile my apk file. Is it possible to do that? please can you give some suggestions?
Edit the file (in the project root) project.propierties and add the line
proguard.config=proguard.cfg
And its done. When you try to generate the signed apk of your app it will take a little longer and it will be obfuscated.
If you receive the "Conversion to dalvik error" when generating the apk you need to update the proguard of your sdk. For doing it you need to go to the ProGuard page to the download section. Download the last stable version and put it content in
SDK_ROOT/tools/proguard
Deleting the existing content before of course.
You can check the Proguard manual at their page (link is above) and the Android's Proguard page for more info about ProGuard
This process is known as Obfuscating the code.
EDIT:
Steps to get obfusticated apk:
1) Download latest proguard from "http://sourceforge.net/projects/proguard/files/". Current latest version is proguard4.7
2) Replace "bin" and "lib" folder of "C:\Program Files (x86)\Android\android-sdk\tools\proguard" with latest downloaded proguard folders.
3) Check SDK location in eclipse for blank spaces in it and for that go to window > Preferences > Android. If there is blank space then replace it with:
c:\Progra~2\android\android-sdk (for windows 64-bit)
c:\Progra~1\android\android-sdk (for windows 32-bit)
4) Check that proguard.cfg file is in your project's root folder and add "proguard.config=proguard.cfg" in project.properties file of android project.
5) Now export your project to get obfusticated apk.
I hope that it will help.
You must not rely on security through obsurity.
If you feel that the encrypted data would be compromised by the knowledge of the encryption algorithm, then you're NOT doing security.
It will always be possible to decompile any file, if the "hacker" knows how to do so. That's why there are still cracks for paid applications, because people take their spare time to decompile/crack applications. All you can do is to make them have a hard time by using as many tools as you can. The first choice (and that comes disabled by default) is ProGuard
I'd like to be able to use TIME and DATE macros in Java, just as I would in C. However, I'm aware they don't exist. I've looked at various sites, and seen suggestions such as http://www.rgagnon.com/javadetails/java-0532.html. I understand that this could be implemented by creating a custom build.xml, but I'm reluctant to break that far from the Android tool chain.
An Eclipse Builder might have been a viable solution, but modifying files outside Eclipse seems like an unwise thing to do.
Has anyone a suggestion for accessing build date/time from within their Android application without a custom build.xml? Is it possible to use the build.properties file, an Eclipse Builder, or something else?
I would recommend using a build.properties file written by ant script registered as a project builder. As part of ant builder configuration you can specify which resources to refresh post-build, so the fact that you are writing this file external to Eclipse isn't going to be much of an issue. Make sure to configure your source control system to ignore this build.properties file.