[Galaxy Note II Original Android Development] rovo89:
You can only compare this if the app is the same one. For SystemUI, I'm pretty sure PA has massively modified it, as has CM (I think PA is partly based on CM, isn't it?). As the switch to tablet UI is own of their big announced features, they will surely have done something for it. And SystemUI is deeply integrated into the system. For example, the decision about which UI to use is made in PhoneWindowManager as far as I can see - not in SystemUI! I would see SystemUI as an extension of the framework rather than a normal app. It's the last "app" I would except to work with the App Settings module, which targets settings that can be used for all apps.

Anyway, I looked at this thread and implemented the first step for tablet UI:

findAndHookMethod("com.android.internal.policy.impl.PhoneWindowManager", null, "setInitialDisplaySize",
Display.class, int.class, int.class, int.class, new XC_MethodHook() {
@Override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
setBooleanField(param.thisObject, "mHasSystemNavBar", true);
setBooleanField(param.thisObject, "mNavigationBarCanMove", false);
}
});

Result:

And if it that's a good sign: Yes, it crashes if I try to expand the notifications, same as here (it's clear from the source that this will happen though). But: This is on CM10.1. It might not work on other ROMs if they aren't prepared to handle it. And actually, this is a very special case and not really the target of the generic App Settings module.

If you activate a different screen size in App Settings, then other resources are loaded. If that doesn't work, let me know what the folder name is and I'll tell you which settings to use.

We are probably talking about different things. This quote is about changing layouts from hardcoded values to a properly designed UI which keeps some parts static (such as a sidebar) and uses the remaining space for the main content. How would PA be able to do that dynamically? How should it know which parts should always have a fixed size and which should resize? This isn't what you mean, or is it?

I think that's close to what I'm saying, although it's more about hardcoding dimensions in general. Back to my sidebar example: It doesn't matter if the sidebar has 150dip and the main content has 300dip or if its 200px / 400px. The ratio is always the same. If I lower the density, I will want the fonts etc. to be smalle. If the layout uses px, I won't see any difference at all. If the factor for the dpi->px conversion is 1.00 instead of 1.33 now, I get a 150px sidebar, 300px main content and 150px unused space. What I really want is: 150px sidebar, remaining space (in this case 450px, maybe more or less on other devices) main content (with smaller fonts etc.) But how should any generic code decide that it's exactly the layout for the main content which has to be resized? I don't think PA or anything else could do that. Does that make it clear?

And again, this is exactly what the App Settings module is doing. When Android sees a dip value, it uses applyDimension() to calculate the px value with the same formula as your script: px = dip*(density/160). Let's say a layout is made for a dpi of 320. Then you would enter 320 in your script and it turns 300dip into 600px, right? In App Settings, you set the density to 320 and Android will again get 600px. There is no difference, except that the way App Settings does it, it doesn't need to find all relevant dimensions and will also work for dimensions defined in the Android framework.

That's no problem. But as I said: What you are doing with the script is already working.