I get tons of error regarding SpongyCastle's auto-generated .cs files after importing them, even though Xamarin generated them.
The Java library that I created needs the dependency, and I imported it into the Jars folder together with my Java library.
How to fix this?
If it is a Java library that is referenced by your Java library and you do not need to access it via C# user code, then you do not need to create a C# bindings for it.
Flag that .jar/.aar with a build type of:
EmbeddedReferenceJar : Use this to compile against and include it in your binding library.
or
ReferenceJar : Use this to compile against but not include it in your binding library. You will need to supply it in your final APK in another way.
Re: Build Actions
Related
Requirement: I now have a CrackMe.apk without project file and code, I want to modify its code in java language without using smali and to dynamically debug the modified java file. I looked up many ways to dynamically debug the apk on the internet, and the internet is full of debugging using smali language, there is no case of debugging the apk using java language. Now, I am able to modify and run CrackMe.apk, but I don't know how to debug my code dynamically, I would like to ask how to implement dynamic debugging feature?
Steps: I extract the dex file from CrackMe.apk, convert it to classes.jar file, remove the android and androidx packages from the jar file (not removing it will prompt the existence of the same package name after Add As Library).
Then create a new blank project test in AS software, add classes.jar As Library. then create a new class MainActivity.java with the same name in the file path src/main/com.XXX.XXX, modify the code if (this$0. check() == 999) to if (this$0.check() == 3) and compile it. After compiling, overwrite the new MainActivity.class in the path build\intermediates\javac\debug\classes\com.XXX.XXX with the MainActivity.class file of the same name in the old classes.jar, and then convert the classes.jar to classes.dex and replace the old classes.dex, then after signing it, it can be installed and run.
During this process, can I debug the new MainActivity.java file at the AS software breakpoint in the test project path src/main/com.XXX.XXX. The class file generated by the test project is in the test project file path build\ intermediates\javac\debug\classes\com.XXX.XXX in the test project. I want to dynamically debug CrackMe.apk, not test-debug.apk, MainActivity.java has nothing to do with the test project.
ApkLink: CrackMe.apk
Well, there is no direct way to modify an apk dynamically using java. All you can do is instrument the apk using any of instrumentation library which are written in multiple languages like tyscript or JavaScript.
Among these libraries, Frida & Objection are the most famous ones. Frida allows you to change any value, methods, return types of values, any thing loaded in memory.
Good thing is that you dont need to learn smali, you can still use Java libraries to call any function on it.
Sample code in your case will look like
Java.perform(function() {
var object = Java.use('packageName.ActivityName');
object.check.implementation = function() {
return 3;
}
});
I've got a project and want to share an API that can be used for building a plugin for my application.
Now I don't want to share the full source code but only class definitions and member declarations without their body.
I've seen dependencies before that without downloading the sources the IDE I'm using already knows the structure. That is what I'm going for.
A jar file already does most of what you want, as it does, if not obfuscated, contain all the class and method names in a format that will be understood by any Java IDE.
The rest can be done by preparing and delivering a javadoc jar.
I'm using an native lib for android via Java Bindings Library Project. All goes fine,except one method(and i don't understand why,maybe he's incorrect ported from java to C#).
So the main idea,to make an workaround via Callable Wrapper.
I have implemented Android project in native mode. In this project i also implemented java class(where i'm using this unlucky method) and what i need,just to know how to generate automatically Wrapper and how to add/use into my Mono project?
Or can i make an .jar lib on this native Android project and via bindings library add to my Xamarin.Android project?
PS Sorry for my eng.
Possible solution is to add new java class to OpenCV project. That class should contain methods you want to use ( e.g. to wrap FindContours()). Rebuild project and resulting JAR use in binding project in MonoDevelop/VS solution.
That way you'll call wrapped FindContours() method and it will return expected results :) .
I had to include some bittorrent java library to my Android project. My workspace: Android Studio 1.0.2 (osx) and jdk8. I've connected its maven-repository (ttorrent:1.4) with Gradle and after starting using main classes and features i've got an error:
java.lang.NoSuchMethodError: No static method encodeHex([BZ)[C in class Lorg/apache/commons/codec/binary/Hex; or its super classes (declaration of 'org.apache.commons.codec.binary.Hex' appears in /system/framework/ext.jar).
I went to library's code and find out that it's using org.apache.commons.codec from where ttorrent is importing encodeHex and calling it. Looks like binaryHex method is gone! Or it never been. But I went to commons.codec's code and found binaryHex in its place and with arguments that I was looking for. How come? Why? My Android Studio found it. But java runtime not.
In fact, the decision was more difficult than I thought. Let's start with the fact that I came across an article by Dieser Beitrag'a, from which it is clear that not one I had similar problems. The whole thing turned out that within the Android operating system already has some libraries that have a higher priority use, rather than loaded with dependencies along with the application. Among them there and my org.apache.commons.codec.
Yes, such things.
To solve the problem in two ways, either you need to pump source code library and using some tool to rename the project (i.e. org.apache.commons.codec to org.apache.commons.codec.android), collected it to a .jar file, include .jar in a project and at code use imports of the necessary classes only "our" library, or just get the required class to your project and do not pull a megabytes of unneeded code. However, I did just that.
Thanks for help!
Has someone tried to use MessagePack with an Android app?
Is it possible? I have tried to use the Jar from msgpack-java and received the following Exception:
Caused by: java.lang.ExceptionInInitializerError
at org.msgpack.Packer.pack(Packer.java:532)
at org.msgpack.MessagePack.pack(MessagePack.java:31)
... 15 more
Caused by: java.lang.ExceptionInInitializerError
at org.msgpack.template.TemplateRegistry.<clinit>(TemplateRegistry.java:38)
... 17 more
Caused by: java.lang.VerifyError: org.msgpack.template.BeansFieldEntryReader
at org.msgpack.template.builder.BeansTemplateBuilder.<init (BeansTemplateBuilder.java:42)
at org.msgpack.template.builder.BuilderSelectorRegistry.initForJava(BuilderSelectorRegistry.java:73)
at org.msgpack.template.builder.BuilderSelectorRegistry.<clinit>(BuilderSelectorRegistry.java:38)
... 18 more
The code that I use is very simple
PrintWriter out = new PrintWriter(socket.getOutputStream());
Message msg = new Message();
msg.body = "asdasdasd";
msg.from = "qwe";
msg.to = "ttt";
byte[] bytes = MessagePack.pack(msg);
out.print(bytes);
out.flush();
I have javassist.jar, msgpack-0.5.2.jar, slf4j-api-1.6.2.jar and slf4j-jdk14-1.6.2.jar in my lib directory.
In my server application this code works fine with the same libraries.
(Hopefully) FINAL UPDATE
msgpack : 0.6.8 works on Android without any problems
msgpack-rpc : 0.7.0 works on Android with one caveat.
Specifically, you need to add the following to onCreate for API Level 8 (Android 2.2.1), and possibly lower:
java.lang.System.setProperty("java.net.preferIPv4Stack", "true");
java.lang.System.setProperty("java.net.preferIPv6Addresses", "false");
due to this bug.
If you want to see a simple example, here's a pair of projects set up for this purpose:
https://github.com/mikkoz/msgpack-android-test-server/tree/master/msgpack-android-test-server
https://github.com/mikkoz/msgpack-android-test-client/tree/master/msgpack-android-test-client
Previous Versions
UPDATE: as of 0.6.7 msgpack should be compatible with Android (there is a small dependency exclusion issue). Check the text below for msgpack-rpc (which also might be adapted in the future).
NOTE: If you're also using msgpack-rpc, you need to do the following steps:
Download the msgpack-rpc source from git://github.com/msgpack/msgpack-rpc.git (specifically, the "java" folder).
Change the main msgpack artifact version to the one you've built.
In org.msgpack.rpc.loop.netty.NettyEventLoop, change the NioClientSocketChannelFactory to OioClientSocketChannelFactory(getWorkerExecutor()).
Build the MessagePack-RPC in the same way as in the case of the main MessagePack JAR (see Step 11 above).
The NettyEventLoop replacement is due to this issue:
http://markmail.org/message/ypa3nrr64kzsyfsa .
Important: I've only tested synchronous communication. Asynchronous might not work.
And here's the reason for msgpack not working with Android prior to 0.6.7:
The reason for the error is that MessagePack uses several java.beans classes that are not included in the Android SDK. You're probably using the MessagePackBeans annotation.
This is a similar problem to the one described here, for which the general solution is outlined here. Unfortunately, in our case it requires a rebuild of msgpack. Here's what I did (you can almost certainly skip Steps 5 and 8, but I haven't tried it that way) :
Download the MessagePack source from https://github.com/msgpack/msgpack-java.git.
Import the MessagePack source as a project in your IDE.
Download the Apache Harmony source for the relevant packages from http://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/beans/src/main/java .
Copy these packages into your MessagePack project's src/main/java folder:
java.beans
java.beans.beancontext
org.apache.harmony.beans
org.apache.harmony.beans.internal.nls
In your MessagePack project, remove the following classes:
PropertyChangeListener
IndexedPropertyChangeEvent
PropertyChangeEvent
PropertyChangeListenerProxy
PropertyChangeSupport
Rename the java.beans packages to something different, e.g. custom.beans .
Change all java.beans references to the renamed ID, so again e.g. custom.beans. This applies especially to BeansFieldEntryReader (this class is the reason for the original error).
Change the custom.beans references for the five classes you removed in Step 5 back to java.beans.
In the org.apache.harmony.beans.internal.nls.Messages class, comment out the method setLocale, and remove the imports associated with it.
Remove all classes that still have errors, except Encoder. In that class, comment out all references to the classes you've removed. You should now have an error-free project.
Build the MessagePack JAR:
If you're using Maven, change the version in the pom.xml to something unique, run Maven build with the install goal, then add the dependency in your Android project with that version.
If you're not using Maven, you have to run the jar goal for Ant with the included build.xml. Replace the msgpack JAR in your Android project with this one.
If you're publishing your app, remember to include the relevant legal notice for Apache Harmony. It's an Apache License, just like MessagePack.
That should do it. Using your example code, and my own data class, I was successfully able to pack and unpack data.
The entire renaming ritual is due to the fact that the DEX compiler complains about java.* package naming.
There is a critical msgpack bug saying data packed with msgpack will get corrupted on the Dalvik VM. http://jira.msgpack.org/browse/MSGPACK-51
There is an ongoing effort by #TheTerribleSwiftTomato and the MessagePack core team to get MessagePack working on Android, please see the related GitHub issue. The fix mentioned in #TheTerribleSwiftTomato's answer is to be found here.
Update
I've managed to get it at least running on Android by (painstakingly) adding all the necessary javassist Classes which are currently required for the build to succeed. An extra 600KB gain in size, yet at least it seems to work. All in all, it appears to be working to some extent on Android, eventually check out the lesser-known resources about Message Pack such as its User Group and its Wiki for more information.
On a side-note, be sure to use a HTTP Request Library (such as LoopJ's Android Async HTTP or Apache's HttpClient) which can handle binary data.
Last but not least you can ping me if there is interest in this jar which makes MessagePack seemingly work on Android – credits go out of course to #TheTerribleSwiftTomato who supplied the fix above!
I suggest you write this in the main proguard-rules file-
-dontwarn org.msgpack.**
-keep class org.msgpack.** { *; }