backported to gingerbread

[liudongmiao]

No description provided.

[rovo89]

Wow. Are all features already working (normal hooks, resource replacement)? That looks like a great effort you have done so far.

Still I have mixed feelings about it. If I understand your commits correctly, both the native and the Java part need hacks in the AOSP code. Is this only needed for compiling? If yes, it still makes it even harder to compile Xposed. If the ROM needs to be patched as well, it's hardly possible to distribute it widely. If there is any way to make it work without the hacks, that would be great.

The aspects that I worry about most however are that all those conditions make the code harder to understand and maintain. Any additions or changes need to consider Gingerbread support. I don't have any GB device, the emulator is awfully slow and again this adds a lot of complexity to the code (which of course takes time away from other things). The same things also apply to modules. Not sure if there need to be interface changes, but they would need to use conditions if they want to work across different versions. Finally, I'm currently rewriting many parts of the installer. It would need another big rewrite to use the support library for fragments etc. You see, backwards compatibility can really become a PITA.

So I'm wondering if this should really be merged into the original project at this time or stay as a fork. I'd like to hear what @Tungstwenty thinks about this, but maybe it could start as an experimental version, published and maintained by yourself. If it is adopted well, changes/fixes could either be exchanged between the two repositories/branches, or we can then talk again about merging the code and adding you as additional maintainer for all Gingerbread-related stuff.

[liudongmiao]

Rovo89,

Thanks for your great work on app_process, and all the work on xposed.

Shortly, I have tested for the framework on gingerbread (motorola xprt),
but only for xposed and xposedbridge. actually, im using xprivacy with
modification according the development guide. The xposedinstaller is not
backported yet (i write /data/xposed/module.list directly).

According the author of xprivacy, they said "Because of a bug in the Xposed
framework, XPrivacy currently needs a fixed Xposed binary, which is
provided as download for both Android version 4.0, 4.1, 4.2 and 4.3.". do
you know what is this?

Best regards,
Liu DongMiao

2013/7/28 rovo89 notifications@github.com

Wow. Are all features already working (normal hooks, resource
replacement)? That looks like a great effort you have done so far.

Still I have mixed feelings about it. If I understand your commits
correctly, both the native and the Java part need hacks in the AOSP code.
Is this only needed for compiling? If yes, it still makes it even harder to
compile Xposed. If the ROM needs to be patched as well, it's hardly
possible to distribute it widely. If there is any way to make it work
without the hacks, that would be great.

The aspects that I worry about most however are that all those conditions
make the code harder to understand and maintain. Any additions or changes
need to consider Gingerbread support. I don't have any GB device, the
emulator is awfully slow and again this adds a lot of complexity to the
code (which of course takes time away from other things). The same things
also apply to modules. Not sure if there need to be interface changes, but
they would need to use conditions if they want to work across different
versions. Finally, I'm currently rewriting many parts of the installer. It
would need another big rewrite to use the support library for fragments
etc. You see, backwards compatibility can really become a PITA.

So I'm wondering if this should really be merged into the original project
at this time or stay as a fork. I'd like to hear what @Tungstwentyhttps://github.com/Tungstwentythinks about this, but maybe it could start as an experimental version,
published and maintained by yourself. If it is adopted well, changes/fixes
could either be exchanged between the two repositories/branches, or we can
then talk again about merging the code and adding you as additional
maintainer for all Gingerbread-related stuff.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2#issuecomment-21669855
.

[rovo89]

The fix is pull request #1. I will merge it before the next version.

[Tungstwenty]

I am happy that Liu took the time to investigate and work on this and get the core of the framework working on GB.
But like rovo, I also think that maintenance might be a bit hard, considering both the app_process / xposed.cpp replacement, the installer as well, and even the modules.
I'd guess that many of the developers just place minSdkVersion="15" because they don't have a GB device any more and the emulator is very impractical to ensure compatibility with much older versions.
I'm not sure what the best way to go would be, but perhaps an initial period where the Xposed repo is kept separately, and the XposedInstaller as well - considering the amount of work rovo has been putting on the new version which includes updates support but assumes features not available on GB.
If these 2 are maintained separately but published / advertised as "the GB version of Xposed", and if it's possible to keep having the exact same XposedBrigde, then it could be a good way to check how it goes in terms of adoption and compatibility of mods with GB as well, and later on check if / how to merge into a single codebase. The core of the framework, while complex, is a relatively central and stable piece. It does have its support issues, but at lease apparently, most of the support issues are either related with the installation of the framework or questions for specific mods.
Ideally, if the GB version is published on the same Framework thread as the "regular" version, framework-related issues might be troubleshooted in an easier and more broaden way and about the mods only time will tell how their adoption goes.

[Tungstwenty]

I just checked the pull request for the XposedBridge.
Most of the changes look acceptable to be merged onto a single version, except for the framework patch (the changes from private to public) which I didn't quite understand. Is that really necessary for the Bridge to work? Or could it be compiled against sdk 15 and still be used on e.g. sdk 10 without any compatibility issues, considering for instance that SharedPreferences.getStringSet() doesn't exit?
I'm not entirely sure if having a single bridge, even if requiring sdk15, would allow mod authors to create stuff that runs on sdk10+ but it would be great if so.

[liudongmiao]

for the c++ version xposed, as we actually compile for different platform,
there is no universal solutuon. however, as its written in c++, we can
using the same binary, which is not recommended. just ignore the private or
public, as in c++, all are in a table, which can be visit in runtime. and
xposed.cpp using this magic too.

for the java xposed bridge, we should use modified framework api 10 or api
15. as in the bridge, we can check run version, and choose the right api.
there is little change and little difference. for the compatiabilty, we
should mind the developer, even is api 14+, android api still keep changed.
I just look into the xprivacy, in the latest version, it use a meta.xml for
which sdk can use which method.

For override annotation, this is used for java, not dalvik, i compare the
smali code, they are same. Actually, the dalvik will check the method, if
it cannot be linked (yes, it can be applied to java too, not only c), the
method is disable(from the logcat will see dead code). As for getStringSet,
its override, the super method will not be called, furthermore sdk 10 never
call the function. However, i have no sdk 14+ device, i cannot test.

As sdk 10 is still 30+%, the top sdk
version(less than jb, sum of api 16, 17, 18) in google play store. However,
there is much china guys on gb, and cannot visit play store, so i think the
sdk 10 will take more.
在 2013-7-29 上午7:15，"Tungstwenty" notifications@github.com写道：

I just checked the pull request for the XposedBridge.
Most of the changes look acceptable to be merged onto a single version,
except for the framework patch (the changes from private to public) which I
didn't quite understand. Is that really necessary for the Bridge to work?
Or could it be compiled against sdk 15 and still be used on e.g. sdk 10
without any compatibility issues, considering for instance that
SharedPreferences.getStringSet() doesn't exit?
I'm not entirely sure if having a single bridge, even if requiring sdk15,
would allow mod authors to create stuff that runs on sdk10+ but it would be
great if so.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2#issuecomment-21693308
.

[liudongmiao]

note: the framework patch is to generated full_framework_sdk10.jar, the
user dont need to install them, just as full_framework_sdk15.jar.

for replace private to public, i think rovo89 do so too, just to avoid
using reflect method call them in java. for example, the loadapk is
private, we call it directly in current xposedbridge too. i think that
xposed make all the method accessable? what's the meading of 42 in
xposedtest?

for other added method, just for java compile, as we using @OverRide, this
annotation requires super method. however, as sdk10 never call them, so its
ok.
在 2013-7-29 上午7:15，"Tungstwenty" notifications@github.com写道：

I just checked the pull request for the XposedBridge.
Most of the changes look acceptable to be merged onto a single version,
except for the framework patch (the changes from private to public) which I
didn't quite understand. Is that really necessary for the Bridge to work?
Or could it be compiled against sdk 15 and still be used on e.g. sdk 10
without any compatibility issues, considering for instance that
SharedPreferences.getStringSet() doesn't exit?
I'm not entirely sure if having a single bridge, even if requiring sdk15,
would allow mod authors to create stuff that runs on sdk10+ but it would be
great if so.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2#issuecomment-21693308
.

[liudongmiao]

@Tungstwenty for change private to public, its a bug in gcc, not in vc. just check for following code:
/* private.h */
class Private {
private:
void print();
};

/* private.cpp */
#include <stdio.h>
#include "private.h"
void Private::print() {
printf("im private\n");
}

/* main.cpp */
#define private public
#include "private.h"
#undef private
int main() {
Private p;
p.print();
return 0;
}

yes, you can visit private method in private.cpp or private.o, or some dll/so/dylib.

for the second java private method access, please see @rovo89 's code in xposed.cpp/xposedtest.cpp
replaceAsm((void_) &dvmCheckClassAccess, asmReturnTrue, sizeof(asmReturnTrue));
replaceAsm((void_) &dvmCheckFieldAccess, asmReturnTrue, sizeof(asmReturnTrue));
replaceAsm((void_) &dvmInSamePackage, asmReturnTrue, sizeof(asmReturnTrue));
if (access(XPOSED_DIR "do_not_hook_dvmCheckMethodAccess", F_OK) != 0)
replaceAsm((void_) &dvmCheckMethodAccess, asmReturnTrue, sizeof(asmReturnTrue));
just guest what does this do...haha.

[rovo89]

Of course I know what that code does. I have written it myself.

But what's your point? What do you want do show? The fact is that the current code doesn't require any changes to the AOSP code. The full-framework15.jar file is unmodified code, just with the hidden code (@hide) included.

[liudongmiao]

i modified code, just make XposedBridge to compile. following is added dummy function:
getPackageInfoNoCheck(ApplicationInfo ai, CompatibilityInfo compatInfo)
https://github.com/liudongmiao/XposedBridge/blob/master/src/de/robv/android/xposed/XposedBridge.java#L134
you see, only call by api10+, api 10 will never call it.

getStringSet(String key, Set defValues)
https://github.com/liudongmiao/XposedBridge/blob/master/src/de/robv/android/xposed/XSharedPreferences.java#L151
override here, and api 10 never call it.

updateConfiguration(Configuration config, DisplayMetrics metrics, CompatibilityInfo compat)
https://github.com/liudongmiao/XposedBridge/blob/master/src/android/content/res/XResources.java#L50
you see, only call by api10+, api 10 will never call it.

getDrawableForDensity(int id, int density)
https://github.com/liudongmiao/XposedBridge/blob/master/src/android/content/res/XResources.java#L373
https://github.com/liudongmiao/XposedBridge/blob/master/src/android/content/res/XResources.java#L379
you see, only call by api10+, api 10 will never call it.

all in short, add dummy code for xposedbridge to be compiled for api10 and api15.
as you see, all the added nonexist-in-framework-api10 functions, are never called in xposedbridge.

[rovo89]

It sounds to me like all the Java changes would not be necessary if XposedBridge.jar was compiled with the SDK15 framework where those methods exist. There is no version check for the jar file. The override for missing methods is not very clean, but ok...

I'm more worried about the dalvik.c.patch. Why is this needed? It means that compiling Xposed is not limited to the folder you check out to, but affects also the source tree, making it even more complicated to compile Xposed. There has to be an alternative for this.

Anyway, before digging deeper into technical details, let's talk about some not so technical stuff first. Some things need to be clear:

1. I won't give any support for GB. You (or somebody else who wants to help) have to take care of it. If your numbers are correct and every third phone is still running on GB, that would mean more than 77k Xposed users (more than 154k users with Android 4.0.3+ have downloaded the latest version of Xposed, and that is only from the official source). That can be a lot of work, so be prepared for it.
2. Integration of GB support must not slow down progress of the framework or the installer. I will continue to develop for the latest and greatest version. Afterwards, "somebody" (= anyone but me) has to test if it works with GB and do adjustments if necessary (without adding tons of ugly hacks or removing features on newer ROMs, please).
3. GB support should be tested well by multiple people with different devices. At the current time, I don't see much added value of merging it, while at the same time people would expect a certain stability which I can hardly judge about. It's much easier to get rid of initial issues as long as it is a separate, experimental package.

So far, I haven't seen much feedback about your version at XDA. I'm wondering whether a separate thread for GB support wouldn't be better, I think everyone would benefit. You could keep track of any questions more easily, users would find answers specific to GB instead of Android 4.3, it's more visible and I don't have to care about it. It would also make it easier to estimate how many people actually tried it and how stable it is.

In order to make it more attractive, I think it would help if you made a few more existing modules compatible with GB, ask the developers if they are willing to do so or develop some yourself.

[liudongmiao]

yes, there is no any benefit to support gingerbread. thanks for your support.
anymore, whats the license of XposedInstaller, XposedMods?

for dalvik.c.patch, its just because the xposed is written in c++, and dalvik before android 4.0 is written in c.
in c++, enum cannot be converted to int or other things, vice and vice.
so i just remove the inline implementation in dalvik's headers.

[ghost]

If it had it's own thread and some working modules then I think it'd do a little better. It doesn't help that the ported version of XPrivacy is kind of slow and buggy on my device, so that's not a great way to show off what Xposed can do.

This port is great, but I think the problem is that most people with Gingerbread can install a version of CyanogenMod. That or they've used baksmali/smali and have got custom ROM's containing all of the features they want already. Anyone that's wanted more than that has upgraded to a newer device, so there's not going to be much support from anyone. Heck, even normal apps are starting to drop API 10 support.

[liudongmiao]

@blackbox87 yes, i think you guys are right. however, i will keep porting, because newer devices are so huge to me, and without physical keyboard.

the latest xprivacy (i even didnt push to github), which i havnt release yet, works well on my device.

i will release new versions of xposed/xposed installer/xprivacy using another name, about in this weekend.