Hi guys, i am learning how to build xposed modules, actually i already built a small module for a few personal things, but now i want to fix a bug i have on my cyanogen. I know cyanogen is open , and i could just download it and compile it , but i want to learn xposed, so it will be a challenge.
Well, i need to replace a method , but looking at the original method there is a line i will need to keep:
Final Set<String> ret = Sets.newHashSet()
where Sets is from 'import com.google.android.collect.Sets;'
Since i do not have this class, how can i make that line to compile ? I think com.google.android.collect.Sets is inside framework.jar, but it appears to be odexed, so eclipse does not recognize if i try to put on build path.
Sorry it the question is too simple, i am still learning =)
There are more alternatives:
1) check source code of Sets.newHashSet(). It most likely returns new HashSet<String>() in which case you simply use that instead. So:
final Set<String> ret = new HashSet<String>()
2) use xposed:
final Set<String> ret = XposedHelpers.callStaticMethod(XposedHelpers.findClass("com.google.android.collect.Sets", classLoader), "newHashSet"));
Related
e way we got a little help from Broadcom.
David has given us all we need to build CM7 ..
Thanks for the information whitexp.
Based on your feedback, we've noted the following issues with the current BCM21553 CM7 port, and will investigate to see if we can help resolve them:
1) Colors are swapped when using software rendering. There are fixes for this, which involve copying libraries from the stock firmware, but they introduce stability issues.
2) libGLES_hgl.so has many shared library dependencies and does not work with the stock surfaceflinger/libui.
I was able to build CM7, with a couple modifications to your device tree, and replicate the color swap issue seen with software rendering.
We're working on a solution to formally release our software, but in the meantime, we have a test patch to fix the color swap issue without using any additional prebuilt libraries.
To try this, please copy the gralloc folder from hardware/libhardware/modules/gralloc (http://madteam.co/forum/go.php?url=aHR0cHM6Ly9naXRodWIuY29tL0N5YW5vZ2VuTW9kL2FuZHJvaWRfaGFyZHdhcmVfbGliaGFyZHdhcmUvdHJlZS9nYi1yZWxlYXNlLTcuMi9tb2R1bGVzL2dyYWxsb2M) to your device tree and apply the attached patch to use the correct fbFormat for the hardware.
You will also need to modify the LOCAL_MODULE in Android.mk with the correct board name.
Thanks,
David
Patch inline:
diff --git a/modules/gralloc/framebuffer.cpp b/modules/gralloc/framebuffer.cpp
index fe57a8a..a46d46e 100644
--- a/modules/gralloc/framebuffer.cpp
+++ b/modules/gralloc/framebuffer.cpp
@@ -355,7 +355,7 @@ int fb_device_open(hw_module_t const* module, const char* name,
if (status >= 0) {
int stride = m->finfo.line_length / (m->info.bits_per_pixel >> 3);
int format = (m->info.bits_per_pixel == 32)
- ? HAL_PIXEL_FORMAT_RGBX_8888
+ ? HAL_PIXEL_FORMAT_BGRA_8888
: HAL_PIXEL_FORMAT_RGB_565;
#ifdef NO_32BPP
format = HAL_PIXEL_FORMAT_RGB_565;
Of course these are only temporary drivers ..
Click to expand...
Click to collapse
LINK FOR ORIGINAL POST: http://madteam.co/forum/general-77/%28dev%27s%29%28broadcom%29-open-dialogue-with-broadcom/60/
This is just a hacked up solution to the blue-red color switch problem that was haunting devs for a very long time...
I'm not sure if we even have a cm7 build that can even boot to that point!
What you highlighted in red is the difference between the 'before' and 'after' code. Basically the only thing changed is the order in which colors are read by the GPU. Before it was reading red-green-blue-(ignores alpha), now it's reading blue-green-red-alpha.
Now that it's reading alpha too I think it might fix some crashes with some games but i'm not sure
Ooops!!! Wrong section i guess
ZakooZ said:
This is just a hacked up solution to the blue-red color switch problem that was haunting devs for a very long time...
I'm not sure if we even have a cm7 build that can even boot to that point!
What you highlighted in red is the difference between the 'before' and 'after' code. Basically the only thing changed is the order in which colors are read by the GPU. Before it was reading red-green-blue-(ignores alpha), now it's reading blue-green-red-alpha.
Now that it's reading alpha too I think it might fix some crashes with some games but i'm not sure
Click to expand...
Click to collapse
Can't find the sense about change the RGBA order :silly:
Now colors not are swapped! Yeeeeaaaahh
Thats one small step for Cm7, One giant leap for Broadcomm.. (yes i am taking the ****)
My Question to the Dev's is is there a Guide on How to Build Single APP Packages eg Calculator from Source Without building the entire android from Source is possible to build eg libjpeg from source as a single module.
i have tried the mmm command all it did was spit out errors you fix one get ten more and so on
I also tried using NDK by inserting the open source libs into a jni folder and modifying Android.mk to look similar to the sample jni resulted in errors this is the only Guide i can't find as there many on building entire android but sometime one only needs specific modules and not entire build.
If above not possible is there a bare minimum version where it only builds android core frameworks and like one lib /app ?
i did not try this .
u can download the package like if u want trebucket launcher then download full android_packages_apps_trebuckhet.
recompile it to get the trebucket apk
once againg i did not try this out
defcomg said:
My Question to the Dev's is is there a Guide on How to Build Single APP Packages eg Calculator from Source Without building the entire android from Source is possible to build eg libjpeg from source as a single module.
i have tried the mmm command all it did was spit out errors you fix one get ten more and so on
I also tried using NDK by inserting the open source libs into a jni folder and modifying Android.mk to look similar to the sample jni resulted in errors this is the only Guide i can't find as there many on building entire android but sometime one only needs specific modules and not entire build.
If above not possible is there a bare minimum version where it only builds android core frameworks and like one lib /app ?
Click to expand...
Click to collapse
Mmm won't help as it needs to link against other parts of the system. That's why you need to do a full build before you can mmm
In theory you can take the app and try to import it into eclipse, and regard it just as an app project.
Hi all,
My Xposed module deals with different versions of an app. Different versions means different hooks, so my question is: how can I get the application version during the handleLoadPackage execution? I mean... getPackageManager requires a context which I do not have *or* I don't know how to find out...
Any clues, guys?
Thanks.
From memory, I believe you can use the appInfo field in LoadPackageParam: lpparam.appInfo.
Otherwise you can get a context with AndroidAppHelper.currentApplication()
GermainZ said:
From memory, I believe you can use the appInfo field in LoadPackageParam: lpparam.appInfo.
Otherwise you can get a context with AndroidAppHelper.currentApplication()
Click to expand...
Click to collapse
No luck!
AndroidAppHelper.currentApplication() returns null and lpparam.appInfo does not appear to be a Context object...
Any other idea?
slvrbllt said:
No luck!
AndroidAppHelper.currentApplication() returns null and lpparam.appInfo does not appear to be a Context object...
Any other idea?
Click to expand...
Click to collapse
lpparam.appInfo = ApplicationInfo, not Context. It might have the version, but I can't recall if it does or check it right now.
GermainZ said:
lpparam.appInfo = ApplicationInfo, not Context. It might have the version...
Click to expand...
Click to collapse
I couldn't see anything in the ApplicationInfo object that could be related to the version number of the package...
I assume you're placing your hooks in handleLoadPackage(). The Context/Application isn't created yet at that time. I think some modules managed to get a system context via reflection, but I don't know which ones. Maybe you can find something via the search function.
Just another idea: Instead of comparing versions, you might be able to achieve the same by checking whether certain classes/methods exist.
rovo89 said:
I assume you're placing your hooks in handleLoadPackage(). The Context/Application isn't created yet at that time. I think some modules managed to get a system context via reflection, but I don't know which ones. Maybe you can find something via the search function.
Just another idea: Instead of comparing versions, you might be able to achieve the same by checking whether certain classes/methods exist.
Click to expand...
Click to collapse
Thanks for your reply, mate.
You are correct! handleLoadPackage is where I placed my hooks.
As per your suggestion, I will try to find any other existing module that does what I'm looking for.
Unfortunately I need to identify the package version in any reliable way but classes/methods existence check.
The app is obfuscated... method a.a.b could be a.b.c in another version while method a.a.b could still exist but with different implementation.
Is there any other way to retrieve the installed version of a package, given it's package name?
Thanks.
slvrbllt said:
Is there any other way to retrieve the installed version of a package, given it's package name?
Click to expand...
Click to collapse
Apart from using the system context to access the package manager, you could try to parse the package yourself. There is a PackageParser class which is hidden from the SDK, but if you manage to call parsePackage() via reflection (or by referencing a JAR which includes the hidden APIs as well, like XposedBridge does), then you can use it with ApplicationInfo.sourceDir and get the version numbers from the result. Not sure how expensive that operation is, but if you execute it just once, it should be ok.
rovo89 said:
[...] if you manage to call parsePackage() via reflection (or by referencing a JAR which includes the hidden APIs as well, like XposedBridge does), then you can use it with ApplicationInfo.sourceDir and get the version numbers from the result.[...]
Click to expand...
Click to collapse
I will definitely give it a try.
Thanks!
For anyone wondering the snippet we used up until now is "deprecated" in Android 11 and totally gone in 12 (S). You can use the code below to get the version code for your app:
Java:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
Class<?> pkgParserClass = XposedHelpers.findClass("android.content.pm.PackageParser", lpparam.classLoader);
Object packageLite = XposedHelpers.callStaticMethod(pkgParserClass, "parsePackageLite", apkPath, 0);
versionCode = XposedHelpers.getIntField(packageLite, "versionCode");
} else {
Class<?> parserCls = XposedHelpers.findClass("android.content.pm.PackageParser", lpparam.classLoader);
Object pkg = XposedHelpers.callMethod(parserCls.newInstance(), "parsePackage", apkPath, 0);
versionCode = XposedHelpers.getIntField(pkg, "mVersionCode");
}
Massi-X said:
For anyone wondering the snippet we used up until now is "deprecated" in Android 11 and totally gone in 12 (S). You can use the code below to get the version code for your app:
Java:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
Class<?> pkgParserClass = XposedHelpers.findClass("android.content.pm.PackageParser", lpparam.classLoader);
Object packageLite = XposedHelpers.callStaticMethod(pkgParserClass, "parsePackageLite", apkPath, 0);
versionCode = XposedHelpers.getIntField(packageLite, "versionCode");
} else {
Class<?> parserCls = XposedHelpers.findClass("android.content.pm.PackageParser", lpparam.classLoader);
Object pkg = XposedHelpers.callMethod(parserCls.newInstance(), "parsePackage", apkPath, 0);
versionCode = XposedHelpers.getIntField(pkg, "mVersionCode");
}
Click to expand...
Click to collapse
Thank you so much broo
ok, i'm trying to port and boot the AOSP source from google for 4.1.2 JB x86, first of all, i follow the next guide to build my own compiling machine http://forum.xda-developers.com/showthread.php?t=2762390 but i download in the step 12 the repo of google AOSP (repo init -u https://android.googlesource.com/platform/manifest -b android-4.1.2_r2.1 & repo sync)
Start the enviroment with: . build/envsetup.sh
and download download the source from motorola to get some propertary files http://sourceforge.net/projects/razr-i.motorola/files/LATAM/9.8.2I-50_SML-29/
now, the git have some instructions like you see in the README file inside the source, this say:
1. Create a workspace containing "vanilla" JB release from Google.
Done
Click to expand...
Click to collapse
ou may need to apply the following change in build repo to prevent the build from aborting when unexpected user tag is found on some modules:
[SOURCE] diff --git a/core/base_rules.mk b/core/base_rules.mk
index 3c11673..ecf611d 100644
--- a/core/base_rules.mk
+++ b/core/base_rules.mk
@@ -99,7 +99,7 @@ ifneq ($(filter $(LOCAL_MODULE_TAGS),user),)
$(warning * PRODUCT_PACKAGES section of)
$(warning * build/target/product/core.mk)
$(warning * )
- $(error user tag detected on new module - user tags are only supported on legacy modules)
+ $(warning user tag detected on new module - user tags are only supported on legacy modules)
endif
endif [/SOURCE]
i'm trying to do this step, but nothings seems happen...
The second step says that all we need is overlaying the Motorola repos on top of the AOSP repos, but in the Terminal i don't know some commands ('cause always i work on Windows ).
i need just a little help in here, i'm tryin to compare both sources, but in windows i've a tool called WINMERGE, in linux i don't know if we have something like that. I don't wanna overlay the repos, i want to compare the files and re-write the AOSP source with some parts of the motosource and get AOSP software with motorola hardware working.
thks to all, sorry for my bad english, i don't use translator
I always used meld. Meld is an 2to3 way comparing tool, that compares folders (date), files (versions) and text. It is almost like winmerge, just a little bit different. U can look it up in the app store of whatever ubuntu/linux version you have.
As for the defferences between aosp and moto. There are a number of differences. The most can be located in the system/core where moto has changed the behavior of how init works and some x86 implementations (especially pixelflinger). The next BIG thing is the bionic (libc). It has many x86 implementations and i am not sure if u can overlay them without trouble into aosp source.
Good luck!
Hazou said:
I always used meld. Meld is an 2to3 way comparing tool, that compares folders (date), files (versions) and text. It is almost like winmerge, just a little bit different. U can look it up in the app store of whatever ubuntu/linux version you have.
Click to expand...
Click to collapse
yeah, i'm using meld, it's amazig 'cause i can copy the files from one to another place, by the way, i'm using Ubuntu 14.04, with JVM 1.70 but 've some errors in the moment to build ...
As for the defferences between aosp and moto. There are a number of differences. The most can be located in the system/core where moto has changed the behavior of how init works and some x86 implementations (especially pixelflinger). The next BIG thing is the bionic (libc). It has many x86 implementations and i am not sure if u can overlay them without trouble into aosp source.
Good luck!
Click to expand...
Click to collapse
yeah, i see the both codes and check the changes, in some lines the works of moto it's amazing, but whe need more dev's to check all the changes to implement for porting ROMS
Lenovo has recently provided a software update which upgrades Android to version 4.3 for the k900, so i'm going to download the repo AOSP from google and later try to port 4.3
Hi,
I just started using Xposed Framework and I think it is really cool tool! For now I am just trying to learn the API and how to do the things. I am trying to change some values returned by functions by an app, but the decompiled code is obfuscated and all class names and methods are with one or two letters. For example :
Code:
if(!p.a().h() && ae1.c() > 500F){
com.bones.modes.cn.a(com.bones.modes.cl.a(b)).b().a("New message");
}
So what I need is a way to change return value of
Code:
p.a().h()
and
Code:
ae1.c()
which are located in different package than
Code:
com.bones.modes
.
Any idea how to achieve this?
Why decompile when you can compile from source or directly edit source
check repositories under this user : https://github.com/rovo89
if you find your changes could benifit others submit a change request.
anantshri said:
Why decompile when you can compile from source or directly edit source
check repositories under this user : rovo89
if you find your changes could benifit others submit a change request.
Click to expand...
Click to collapse
I decompiled application just to find class names and methods so I can inject code and make some changes, but don't know how to deal with obfuscated code and Xposed. I've tried to hook method found using dex2jar, but it's throwing an exception
Code:
NoSuchMethodError
.
hardartcore said:
Hi,
I just started using Xposed Framework and I think it is really cool tool! For now I am just trying to learn the API and how to do the things. I am trying to change some values returned by functions by an app, but the decompiled code is obfuscated and all class names and methods are with one or two letters. For example :
Code:
if(!p.a().h() && ae1.c() > 500F){
com.bones.modes.cn.a(com.bones.modes.cl.a(b)).b().a("New message");
}
So what I need is a way to change return value of
Code:
p.a().h()
and
Code:
ae1.c()
which are located in different package than
Code:
com.bones.modes
.
Any idea how to achieve this?
Click to expand...
Click to collapse
Hook the application's package (application package != Java package), then hook the class name you want using its full name (e.g. com.bones.modes.ClassName, or com.otherpackage.something.ClassName).
If that doesn't help, post the code you're trying with (and more information about the "different package").
anantshri said:
Why decompile when you can compile from source or directly edit source
check repositories under this user : https://github.com/rovo89
if you find your changes could benifit others submit a change request.
Click to expand...
Click to collapse
He's talking about something entirely different.
GermainZ said:
Hook the application's package (application package != Java package), then hook the class name you want using its full name (e.g. com.bones.modes.ClassName, or com.otherpackage.something.ClassName).
If that doesn't help, post the code you're trying with (and more information about the "different package").
He's talking about something entirely different.
Click to expand...
Click to collapse
I've already fixed it. I realise that the method which I was trying to override takes params and I wasn't pointing them in declaration of hook method.