How to turn this Hello-JNI project https://codelabs.developers.google.com/codelabs/android-studio-jni/index.html?index=..%2F..%2Findex#0
to an Xposed module and use method "getMsgFromJni" inside hooking methods?
I dont know if Xposed already supports this feature but it should be possible to place the .so in the apps native libraries folder or perhaps hook Android's DexClassLoader to load your library.
I have successfully loaded .so files into other apps using a class loader. My solution can be a nice use case so you can find how to make it do what you want. Basically I placed the libraries in /data/local/tmp/natives and then did something like:
//JNI classes are in data/local/tmp/dexjars/
File[] files = new File("data/local/tmp/dexjars/" + type + "/").listFiles();
//Folder to store optimized dex code
String hash = "dex" + lpparam.packageName.hashCode();
//In case you want to have several packages to load
for (File file : files) {
final File tmpDir = new File("data/local/tmp/optdexjars/" + hash + "/");
tmpDir.mkdirs();
//Create a DexClassLoader that links yo your native libraries
final DexClassLoader classloader = new DexClassLoader(
file.getAbsolutePath(), tmpDir.getAbsolutePath(),
"data/local/tmp/natives/",
ClassLoader.getSystemClassLoader());
//Retrieve your classes performing the JNI
Class c = Class.forName("FULLY_QUALIFIED_JNI_CLASSNAME", true, classloader);
}
If you need some details on how to package your functionality take a look here.
If you find how to do it in a easier way please do post.
Good luck!
Related
I came across custom report feature in Playwright(node js). I would like to use the custom-reporter.ts class from the external node library installed.
Please help me to know, How to map that file in Playwright.config.ts?
(playwright.config.ts)
config = {
reporter: './node_modules/mylibrary/report/lib/my-reporter'
}
It works, but i am not sure whether this approach is adviceable or not.
I have two libraries with same classes defined in each one. However they have some different contents (methods/constants).
For example:
Library 1:
package com.test.package;
Class A {
// only method signatures
public void methodA() {
}
public void methodB() {
}
}
Library 2:
package com.test.package;
Class A {
public void methodA() {
// some logic that MUST be executed to provide backward compatibility
}
}
My application uses Library 1 and Library 2 and run in devices which have com.test.package.ClassA, but com.test.package.ClassA.methodB() will only exist in newer releases in framework. Said that, I need the Library 1 to be used to compile my application and the Library 2 to execute a different implementation of methodA().
I have tried to do this in Android Studio using .jar and .aar libraries format, but none of them worked for me.
Is it possible to set this configuration in an Android Studio project?
I am building both Library 1 and 2, and I cannot add methodB() in Library 2.
For a simple Java application, you can do this by unlinking the compile and runtime configurations. I set up an example repository here.
The idea is shown in this commit, but can be described as manually resetting the runtime configuration so that it doesn't include the contents of the compile configuration. After doing so, you can just include your runtime library variation in the runtime configuration.
The application's build.gradle becomes something like:
apply plugin: 'application'
mainClassName = 'my.package.MyAppClass'
configurations.runtime.extendsFrom = [] // Reset runtime configuration
dependencies {
compile 'my.group:my.artifact:2.0' // Library 1, with the new method
runtime 'my.group:my.artifact:1.0' // Library 2, without the method
}
For Android, this can be a little more complicated. The problem is that there's no runtime configuration for Android (because you don't execute it on your computer, unless you're using Robolectric or something similar).
I think there are a few workarounds you can probably use, but one initial suggestion would be to create a wrapper library that abstracts away the dependency on the other libraries. This wrapper library you can compile with the newest library version (Library 1, with the new method). You could then include the wrapper library in the Android app while setting it as a non-transitive dependency and including the other library version:
dependencies {
compile 'my.group:my.wrapped.artifact:0.1' {
transitive = false // Don't include dependencies of the wrapper
// i.e., don't include version 2.0 of the lib.
}
compile 'my.group:my.artifact:1.0'
}
This should work because by setting the dependency as non-transitive Gradle doesn't recursively include the dependencies of the wrapper library, so the version used to compile the wrapper isn't included (in theory) in the APK. You can therefore add the old version without causing a conflict.
An example is set up in the same repository, under the Android branch. Firstly, two Java libraries are created. Then an Android library is created to wrap around the compile-time library. An example activity is created to show how using the wrapper library uses the compile-time library. Then, the latest commit shows how the app is configured to use the wrapper library (which compiles with the newest library) but forces the old library to be included instead in the runtime.
Hope this helps =)
I'd like a (platform independent) way to list all classes from a package.
A possible way would be get a list of all classes known by Haxe, then filtering through it.
I made a macro to help with just this. It's in the compiletime haxelib.
haxelib install compiletime
And then add it to your build (hxml file):
-lib compiletime
And then use it to import your classes:
// All classes in this package, including sub packages.
var testcases = CompileTime.getAllClasses("my.package");
// All classes in this package, not including sub packages.
var testcases = CompileTime.getAllClasses("my.package",false);
// All classes that extend (or implement) TestCase
var testcases = CompileTime.getAllClasses(TestCase);
// All classes in a package that extend TestCase
var testcases = CompileTime.getAllClasses("my.package",TestCase);
And then you can iterate over them:
for ( testClass in testcases ) {
var test = Type.createInstance( testClass, [] );
}
Please note, if you never have "import some.package.SomeClass" in your code, that class will never be included, because of dead code elimination. So if you want to make sure it gets included, even if you never explicitly call it in your code, you can do something like this:
CompileTime.importPackage( "mygame.levels" );
CompileTime.getAllClasses( "mygame.levels", GameLevel );
How it works
CompileTime.getAllClasses is a macro, and what it does is:
Waits until compilation is finished, and we know all of the types / classes in our app.
Go through each one, and see if it is in the specified package
See also if it extends (or implements) the specified class/interface
If it does, add the class name to some special metadata - #classLists(...) metadata on the CompileTimeClassList file, containing the names of all the matching classes.
At runtime, use the metadata, together with Type.resolveClass(...) to create a list of all matching types.
This is one way to store and retrieve the information: https://gist.github.com/back2dos/c9410ed3ed476ecc1007
Beyond that you could use haxe -xml to get the type information you want, then transform it as needed (use the parser from haxe.rtti to handle the data) and embed the JSON encoded result with -resource theinfo.json (accessed through haxe.Resource).
As a side note: there are chances you'll be better off not having any automation and just add the classes to an array manually. Imagine you have somepackage.ClassA, somepackage.ClassB, ... then you can do
import somepackage.*;
//...
static var CLASSES:Array<Class<Dynamic>> = [ClassA, ClassB, ...];
It gives you more flexibility as whatever you want to do, you can always add 3rd party classes, which may not necessarily be in the same package and you can also choose to not use a class without having to delete it.
I would like to list all of the classes that are in a DLL without having to load the dependencies. I don't want to execute any functionality, I just want to find out (problematically) what classes are inside of a given DLL. Is that possible? I've tried using the assembly.GetTypes() call, but it fails because of dependencies for executing the DLL. Is there any other way to list all the public classes?
I suggest you use the mono Cecil library. This is the basic example:
//Creates an AssemblyDefinition from the "MyLibrary.dll" assembly
AssemblyDefinition myLibrary = AssemblyFactory.GetAssembly ("MyLibrary.dll");
//Gets all types which are declared in the Main Module of "MyLibrary.dll"
foreach (TypeDefinition type in myLibrary.MainModule.Types) {
//Writes the full name of a type
Console.WriteLine (type.FullName);
}
This will not load all the dependencies.
Okay, I found it. This combination works to get a list of all classes without having to deal with the dependencies:
Assembly assembly = Assembly.LoadFrom(filename);
Type[] types = assembly.GetTypes();
You can use Assembly.ReflectionOnlyLoad method to load assembly without executing it.
How to: Load Assemblies into the Reflection-Only Context
Also you need to attach AppDomain.ReflectionOnlyAssemblyResolve as In the reflection-only context, dependencies are not resolved automatically.
I'm porting a Symfony 1.2 project to Symfony 2.x. I'm currently running the latest 2.1.0-dev release.
From my old project I have a class called Tools which has some simple functions for things like munging arrays into strings and generating slugs from strings. I'd like to use this class in my new project but I'm unclear how to use this class outside of a bundle.
I've looked at various answers here which recommend changing app/autoload.php but my autoload.php looks different to the ones in the answers, maybe something has changed here between 2.0 and 2.1.
I'd like to keep my class in my src or app directories as they're under source control. My vendors directory isn't as I'm using composer to take care of that.
Any advice would be appreciated here.
Another way is to use the /app/config/autoload.php:
<?php
use Doctrine\Common\Annotations\AnnotationRegistry;
$loader = require __DIR__.'/../vendor/autoload.php';
$loader->add( 'YOURNAMESPACE', __DIR__.'/../vendor/YOURVENDOR/src' );
// intl
if (!function_exists('intl_get_error_code')) {
require_once _DIR__.'/../vendor/symfony/symfony/src/Symfony/Component/Locale/Resources/stubs/functions.php';
$loader->add('', __DIR__.'/../vendor/symfony/symfony/src/Symfony/Component/Locale/Resources/stubs');
}
AnnotationRegistry::registerLoader(array($loader, 'loadClass'));
return $loader;
Just replace YOURNAMESPACE and YOURVENDOR with your values. Works quite well for me, so far.
You're correct, I stumbled upon the changes in autoload from 2.0 to 2.1. The above code works fine with the latest version, to which I upgraded my project ;-)
For a simple case like this the quickest solution is creating a folder (for example Common) directly under src and put your class in it.
src
-- Common
-- Tools.php
Tools.php contains your class with proper namespace, for example
<?php
namespace Common;
class Tools
{
public static function slugify($string)
{
// ...
}
}
Before calling your function do not forget the use statement
use Common\Tools;
// ...
Tools::slugify('my test string');
If you put your code under src following the proper folder structure and namespace as above, it will work without touching app/autoload.php.