Our development team just (mostly) finished an Android app using MonoDroid in Visual Studio. Because it has to do with banking, we wanted to try to obfuscate it in order to add some security against anyone trying to decompile it. Initially, I figured I could just use ProGuard, but there doesn't seem to be a project.properties file that I can edit in Visual Studio. Can anyone shine some glorious helping light on this subject and tell me if it is possible to use ProGuard with Mono and my newbishness is just clouding my vision?
(Another developer tried to use Dotfuscator -since we couldn't immediately find a way to use ProGuard- but it failed with numerous errors; the Mono runtime seems to give it issues.)
The Mono for Android toolchain doesn't have any support for running proguard at the moment.
However, with one broad exception, the lack of proguard support is largely moot. Proguard only runs on Java bytecode. The Mono for Android architecture has the Mono runtime running in the process; .NET CIL is not "compiled" into Java bytecode, the CIL is JITed by Mono. The only Java code running around is for Android Callable Wrappers, which allow Java/Android to call into managed code.
Thus the only thing proguard will protect in a Mono for Android app is the generated Android Callable Wrappers, which largely consists of a bunch of native method declarations. There won't be any business logic to decompile in the Android Callable Wrappers.
Instead, the CIL assemblies are stored uncompressed in the .apk file. The assemblies in turn can be decompiled to obtain all your business logic. The solution here is to obfuscate the assemblies before embedding them into the .apk. There are reports that Xenocode's Postbuild 2010 can be used, though I don't know any of the details on how to hook this up.
The exception mentioned above relates to any custom Java code included in the build proces via the AndroidJavaSource and AndroidJavaLibrary Build actions, which would be used to include such things as the AdMob library. For this scenario we should add proguard support to the build process, though I have no ETA on when proguard support will be added.
Related
I want to make an interface for a C++ complicated algorithm on a tablet environment, the idea of a server running the C++ code isn't applicable.
Can I embed my C++ algorithm in NDK application (for android, can I do the same for iOS?) and make the interface with Android SDK, and then use the NDK app (maybe as a function) in my SDK android app?? is this scenario possible and how hard it's?
I'd prefer the most a solution involving cordova and hybrid approaches.
If there is a simpler approach I'd appreciate any idea.
You probably want to port some code to Android. I do not know if you code has been ever built under Android.
Anyway, first of all you have to locate and manage to build the hello-jni example in the Android NDK. I have it in android-ndk-r9d/samples/hello-jni. After that, you may start to add functions to that project. Forwarding data between Java and C++ is... well... error-prone.
Android comes with two build systems, the old one is ant-based, the new one is gradle. In addition, some guys manage to use 3rd-party build systems for Android.
If your project has never been built under Android, you will have to port it. If it has Windows/Linux/Mac builds, start from a Linux or a Mac one (in the latter case please note that "darwin" contains "win", this may cause bugs in your build script.) You will likely have to borrow some standard functions from where you can find them. In addition, a while ago Android did not support std::string at all...
If your project has been built under Android, you will have to manage to build it yourself and then use the binaries. Alternatively, you might prefer to just use the existing binaries (this will require less effort) and just not care about bugs.
One more possible approach is to find the project that both uses your preferred build system and has an Android build, build that project for Android and remove the contents, thus obtaining an empty project that is built with your build system of choice. I did no do this and I suppose it will not be as easy as it sounds now. (But you will have a chance to become an expert in that build system.) UPD This section applies mostly to projects that come with a 3rd-party build system. Usually such exotic build systems have some specific features, and one needs these features to build successfully. The general rule is that beyond some level of complexity all working systems are modifications of other working systems (and are never created from scratch). (Example: programmers add functionality gradually and testing is done after each addition; they just cannot write all and then test all.) So in the case of a 3rd-party build system it may be reasonable to take some working project using that 3rd-party build system, get the build system working and replace the project source.
In general what you want is possible for both Android and iOS, but there is no general-case solution.
As everybody knows, piracy becomes a very serious issue on Android.
Does Mono for Android provide code obfuscation when compiling to native code?
Mono for Android does not provide this functionality, however you can still use a third-party tool for obfuscation. As Mono for Android produces CIL assemblies that are JITed by the Mono runtime on the Android device you need to obfuscate these .NET assemblies. Therefore tools like the Android obfuscator Proguard will not help you. The below .NET obfuscators have been reported to work with Mono for Android.
Xenocode Postbuild
CryptoObfuscator
If you use Xenocode Postbuild then make sure you disable "metadata reduction" so that Class names remain valid in Java.
Update
Xamarin.Android allows you to package APK files without the need for the compiled .NET DLLs. This means you do not need to apply obfuscation from a .NET point of view. I can extract my release APK file and find that only the classes.dex file and the .so library files are included. To enable this tick the box "Embed assemblies in native code" (this may only be available for Enterprise subscribers).
Is there some sort of alternative toolchain or language for Android, which can generate standalone APK files?
Ideally it should not depend on the huge and ever-changing, ever-upgraded official Android SDK.
As a parable, I am looking for a rough equivalent to how PowerBASIC and Mingw targets plain Windows just fine, despite Microsoft releasing new Visual Studios all the time.
Bonus points if this language or toolchain itself is an Android program...
As you may or may not be aware, the Android toolchain is based on a few simple ideas:
Your code is compiled using the plain old java compiler, and linked against the Android stubs (android.jar) for linkage against the system library.
After being compiled, the code is converted to dex format. You can actually run this yourself, just do a dx --help. The job of the dx tool is to take Java class files and convert them to dex code, a pretty straightforward compilation which involves going from a stack based to register based vm, and a few other changes.
After having this in place, an apk is built using a set of apk tools. It used to be apkbuilder, but this has since been deprecated. You can actually run this yourself as well. All an APK is is simply a collection of the manifest, resources, and a single file for all the code in dex form. (I.e., many .class files compile to a single .dex which is quite a bit smaller because of a wrapped web of pointers).
So the Android toolchain isn't really all that complex. The custom build process is handled by ant build rules, which are defined in an SDK wide build.xml, which you can find in the platform-tools/ directory (iirc). However, to generate new baseline projects using this custom build environment you simply use the android update project command.
While I'm not sure if this is the response you'd hoped for, I hope it will disambiguate the build process. It's not really all that complex of a toolchain, the majority of it is off the shelf Java, and not Android specific (all that makes it Android specific is library specific stubs for dynamically linked system code). Beyond this, once you have a set of classes, you need only run a few commands to make an executable APK which Android unpacks. I would suspect that any tool targeting the JVM (and capable of linking with the Android specific dynamically linked API) could perform a similar process of producing class files and using this toolchain to compile the rest of the way, though obviously the automated ant build process makes it much simpler.
EDIT:
After some more digging, I found this relevant android-developers thread. An unsettling quote:
At this time we simply don't have the resources to support people who
want to use their own build system, but we really wish we could. In
many ways we try to make it easy on other tools vendor by clearly
separating logic to eclipse or ant specific code (hence the multitude
of jar files everywhere in the tools and in ADT), but this is not one
of them.
However, you may also find this link helpful.
Terminal-IDE and AIDE are pretty much what I was looking for. Both runs on Android.
Im pretty sure the answer is no, but im using the new IntelliJ EAP version and have a project i worked on a while back which was just written against JDK 1.6 for an applet based application.
However now i could see how it could be useful in an android app that im interested in creating.
Do i now have to re-write all the code/tests again targeting the android sdk or can i just drop in my existing JAR file and only use android for the UI layer.
Its just android seems to make testing WAY harder than it needs to be, and i have alot of existing tests written and working, if it wasnt so hard to just write a quick unit test (standard Junit #Test style) i wouldnt mind porting, however i just dont get the whole instrumentation thing, as i dont need a UI at the moment...
Anyway so back to the point, can i use my existing JDK built code in an android app?
No!
Android uses the "Dalvik" VM from project harmony which uses a different set of bytecodes which are incompatable with the standard Java JVM bytecodes.
This was done both to optimise the VM for opreration on mobile platforms, and, probably more importantly to try and avoid Copyright and patent disputes with Sun and now Oracle.
More info here
However there is a tool called "dx" which can perform the conversion in the dev environment.
Okay, let me clear up your confusion.
Jars are converted to dex Dalvik bytecode during the compiling process thus you can use 3rd party jar libs.
However, in your case because its applet which has a different application lifecycle yes you might have to re-do it to get it to work in android.
As far as testing instrumentation is used on all java mobile development even JavaMe. It basically means that the Junit tests are run in the emulator or device but in android's case you are using android mock objects to test android specific things.
We want to migrate a huge complex native program to Android system ,running it as a background service accepting command sent from Java Program using JNI along with IPC. However, the Android NDK state following words:
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Does that mean we have no way to run an standalone native-only application on Android as a background service? The native code can only exist in the form of library that will be loaded to the virtual machine through JNI?
The NDK itself is only for creating libraries, though if you do some web searching you will find that there are at least two sets of wrapper scripts or instructions for (ab)using its toolchain to make standalone executables linked against android's bionic libc (something you would not get from a non-android arm toolchain).
The google folks do not encourage people to do this. Unfortunately, their vision of android only includes java applications, with optional native libraries in support - it does not include any "stable" means of installing or launching a native executable, in the sense that they warn the methods you might be able to use today may not continue to work in new versions. This is really too bad, as it means giving up a lot of the general-purpose-computer potential of the device.
Well, it can be done. But to be honest i've never tried it using the NDK, but i've managed to create native applications using the toolchains provided with the android source code.
Your phone (incase your talking about phones) should be rooted.