Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Thread Closed

Xposed - Legacy thread. Don't panic, Xposed is still here.

OP rovo89

5th July 2012, 10:48 PM   |  #101  
Member
Thanks Meter: 32
 
33 posts
Join Date:Joined: May 2012
More
Quote:
Originally Posted by Phil3759

Grant root access: hangs, no FC
Home button works, kill with task manager and reboot manually

I also had exactly the same issue, reboot from withing the app didn't work.
I'm using SuperSU in case it matters.

The message about manually setting DPI settings was very helpful, thanks! Hope it'll become available in the GUI soon.
The Following User Says Thank You to Oso Polar For This Useful Post: [ View ]
6th July 2012, 02:38 AM   |  #102  
Tungstwenty's Avatar
Recognized Contributor
Thanks Meter: 4,408
 
1,824 posts
Join Date:Joined: Nov 2011
Donate to Me
More
Quote:
Originally Posted by Phil3759

My issues:

1. boot is slowed, even after modifications (can live with it)

2. first hang up on reboot from app during root grant: killed with task manager

3. when try to "Clean up complete remove): hangs, could only shutdown by power button menu. After reboot, clean up works

4. tweakbox: here is my big issue with many confusion with JKay. Some redundant entries with Jkay mod cannot be disabled in tweakbox while other options can. They override the JKay settings. You need to configure them manually in the Tweakbox
- CRT effect: despite not enabling in Tweakbox and not enable the library in Tweakinstaller, it will override and disable JKay CRT off effect. It needs to be set in your app
- SIP: when disabled in your app, JKay can still activate it
- Signal strength: if set on 4 in your app, it is not disabled. When JKay is set to 6 bars, only 4 are shown (ugly icon effect on full signal)
- I use another app to configure long home menu and the tweakbox will override it always
- Battery full notification: did not test it


What I would expected was to be able to disable the parts of code I do not like. For example, CRT: have an option to ignore it in your app so that the Jkay mod does it. Advantage of JKay mod is that settings are immediate, yours needs a reboot

So if you can add an option to enable / disable code instead of toggle function, it will be great. We use parts we like and completely disable other parts

I will try the locale now

Thank you a lot and hope a final release fixes soon these small issues

---------- Post added at 10:34 PM ---------- Previous post was at 10:23 PM ----------

I edited the part about signal. Sadly, xposed wins here too. When set on 4, it is not disabled. We end with 6 bars icon on JKay but only 4 max active on full signal

So, all the tweaks are forced and not switchable

Thanks for the detailed report.
I took note of all the issues and myself and rovo89 will try to address them as soon as possible.

We did worry about having everything in a way that can be configured. On earlier versions a couple of tweaks were built in and not configurable (e.g. the 240 dpi force for the Market). What you're now saying, about having it configurable but the settings on Tweakbox overriding other mods, does make sense. We'll try to create yet another toggle for each area so that you can state "ignore"; meaning - don't bother checking if it's True or False in Xposed, just leave it as is (on the original ROM, on existing mods, whatever).

About the hangups on Install and on Cleanup, the good news is that I can replicate it
I'm using SuperSU and it does show that behavior, perhaps Superuser also has the same issue.
This happens when the app requests a 2nd su execution in order to perform the reboot, but due to the way it works, the binary used to start every application (including this one) has been replaced either with the Xposed one, or back with the original. This confuses SU.
We'll try to perform the install on a single step (although an information box before reboot is still required in order to know if all went well).
In the meantime, and as a workaround, you can perform the installation or the cleanup in the app, but then use the power menu to perform the reboot instead of within the app.

Still about the configurations, the example you gave about SIP is the way you think it should work (or be able to work) for every setting - have a configuration state where it's the other modules that mandate how things work: SIP visible or not, CRT active or not, etc. In other words, the example you give for SIP is a positive one, and the way you suggest that toggles should work on Tweakbox. Is that it?

Finally, about the boot slowdown. Can you give more details? Is the slowdown on boot only on the first reboot after installation, or in all of them? Do you have an idea of the time difference? Do you notice any difference *after* boot is complete? Can you try doing reboots with a lib replacement active (e.g. CRT) and with all libs disabled to see if there's an influence?
Thanks for any inputs on this.


EDIT: Just one comment. CRT configurations are applied on the fly, there is no need for a reboot. The same goes for Phone Increasing Ringer and Phone Vibrate on Call Wait. In time, hopefully more and more settings will have immediate response to changes.
This doesn't collide however with the convenience of having a "no change" option in order to let it be controlled elsewhere. We'll try to look into that.
Last edited by Tungstwenty; 6th July 2012 at 02:44 AM.
The Following User Says Thank You to Tungstwenty For This Useful Post: [ View ]
6th July 2012, 08:37 AM   |  #103  
Phil3759's Avatar
Recognized Developer
Thanks Meter: 32,038
 
9,397 posts
Join Date:Joined: May 2012
Donate to Me
Having the ignore toggle for every setting is all i need. For the SIP also, an ignore toggle is ok. In fact i do not care much about SIP now.
The hang issues are easily avoided as you say by rebooting from phone
Hope you continue development of this application.
Thank you very much. I will test your next release when available

About boot time, finally, only first boot is a bit longer, but next are ok now

Sent from my GT-I9100 using Tapatalk 2
Last edited by Phil3759; 6th July 2012 at 08:41 AM.
6th July 2012, 10:25 AM   |  #104  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 15,376
 
2,386 posts
Join Date:Joined: Jan 2012
More
First, thanks very much for your feedback!
Second, I disagree with a couple of answers Tungstwenty gave.

In general, I think everything is configurable. The 240 dpi fix for the Play Store was just hardcoded in the development version for some time, but I think every setting in all released versions was configurable.

Problems start if you tell two tools which operate on the same level to do contradictory things, then the result will be undefined. So the obvious easy fix is to configure them in a consistent way, selecting the same options in both. Therefore, I'm a bit sad that you blame this on Tweakbox.

Of course, having not only "yes" and "no", but also "don't change" would be an improvement worth thinking about. The main problem is: How can this be displayed in the UI? This is no option for me:

Quote:
Originally Posted by Tungstwenty

We'll try to create yet another toggle for each area so that you can state "ignore"; meaning - don't bother checking if it's True or False in Xposed, just leave it as is (on the original ROM, on existing mods, whatever).

Having an additional toggle for each setting will be confusing to the user (bad usability). Also, it would mean to basically duplicate the XML for the preferences. I'm not sure what an alternative would look like. For "yes"/"no" options, the best thing in my opinion would be a checkbox with three states (adding for example a state which displays a question mark and means "ignore"). But I don't think such a checkbox exists in Android, so it would have to be built from scratch (including a preference that uses it). Another, but again not very nice approach would be presenting a menu with radio buttons when clicking on the option. This can be considered "ok" for choosing the value, although the current choice should be displayed in more appealing way, maybe using images like a checkmark, cross and a question mark.

For colors, such a toggle already exists. That's mainly because you can hardly select the default value with the color picker. For everything where you have sliders, maybe a checkbox would be ok... even though it will reduce the space that the slider can use. For selection menus, it would be pretty easy to implement.

As you can see, a good solution (where "good" is a personal opinion) is not that easy. If you have any other ideas how this could work, please let us know. For now, as I said, please try and configure both tools in the same way.

Quote:
Originally Posted by Tungstwenty

About the hangups on Install and on Cleanup, the good news is that I can replicate it
We'll try to perform the install on a single step (although an information box before reboot is still required in order to know if all went well).

I will try to reproduce this as well, it's working fine with the "normal" su. It mgith very well be a bug in SuperSU, which occurs of the the binary has been overwritten (as Tungstwenty mentioned). If nothing else helps, then maybe we really have to execute the reboot automatically. But it would be good if this could be avoided, so you just need one reboot to install the framework, enable the modules and configure them.

Quote:
Originally Posted by Tungstwenty

EDIT: Just one comment. CRT configurations are applied on the fly, there is no need for a reboot. The same goes for Phone Increasing Ringer and Phone Vibrate on Call Wait. In time, hopefully more and more settings will have immediate response to changes.

Well, for most of the settings, this is a "won't fix" for me. Yes, Jkay has this now with ICS. But Xposed has other advantages. If the immediate response is possible without much effort, then why not. But take for example the status bar color or the number of signal bars. This is a configuration that is normally static. Therefore, the Android code reads the setting once and adjusts its variables according to it. For an immediate response, there would have to be either a constant polling for configuration changes or some kind of push mechanism from the settings app to the target app, which is in a different process. Even when this is done (which is something quite difficult), we still need to find out which variables are affected and what other things were triggered depending on this value.
The Following User Says Thank You to rovo89 For This Useful Post: [ View ]
6th July 2012, 01:12 PM   |  #105  
Phil3759's Avatar
Recognized Developer
Thanks Meter: 32,038
 
9,397 posts
Join Date:Joined: May 2012
Donate to Me
Thank you for your answer

I feel in it all the work that you made, I imagine it is a hard and long work, for no rewards...

Anyway, I do not want to make any suggestion as you mentioned most possibilities. It is up to you to see if it's doable or not

I just felt "bizarre" to have to setup both tools to achieve the same result for many settings. An option to ignore a setting would seem more logic for me, but maybe not for you and for some others... I needed to set it to keep a current setting, others won't...

For example, call recording needing a library. It is easy and clear, if not enabled, it will stay silent and not do anything. When not enabled, the setting can be grayed out or any alternative

Anyway, it was my detailed feedback after testing your great app and most of its functions.

If you need more debugging / testing, let me know

Thank you a lot
The Following User Says Thank You to Phil3759 For This Useful Post: [ View ]
6th July 2012, 01:25 PM   |  #106  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 15,376
 
2,386 posts
Join Date:Joined: Jan 2012
More
Quote:
Originally Posted by Phil3759

An option to ignore a setting would seem more logic for me, but maybe not for you and for some others...

No no, it does make sense. The question is just how this can be presented to the user. In a way that doesn't make it to hard to activate the tweaks and which provides a clear feedback what will happen, without cluttering the UI.

Quote:
Originally Posted by Phil3759

For example, call recording needing a library. It is easy and clear, if not enabled, it will stay silent and not do anything. When not enabled, the setting can be grayed out or any alternative

Sure, we are trying to use such logic where possible. Android makes this very simple for preferences that just depend on one other setting. In this specific case, it is quite complicated because the lib is enabled in the installer (to avoid that every module has to provide its own implementation of the settings etc). Therefore, this kind of dependency is currently not used, but if there are dependent tweaks in the future, we will make use of this.

Quote:
Originally Posted by Phil3759

If you need more debugging / testing, let me know

Thank you a lot

Thank you for testing and your feedback!
The Following User Says Thank You to rovo89 For This Useful Post: [ View ]
6th July 2012, 05:29 PM   |  #107  
Phil3759's Avatar
Recognized Developer
Thanks Meter: 32,038
 
9,397 posts
Join Date:Joined: May 2012
Donate to Me
Thank you for being open to change it, if you find it ok for you :)
I read again your previous post about different approaches and I understand better your meaning
Your proposition here is what seems the most logical in regards of what you said:

Quote:

Another, but again not very nice approach would be presenting a menu with radio buttons when clicking on the option. This can be considered "ok" for choosing the value, although the current choice should be displayed in more appealing way, maybe using images like a checkmark, cross and a question mark.

Here are some options I tried to think at:

One option, is to use Titanium Backup approach:
A submenu appear on checkbox activation (see TitaniumBackup / Preferences / Cloud Sync settings / Enable Dropbox). When the check box "Dropbox" is checked, a submenu of preferences is displayed. This will avoid to have a radio button with disabled in the options of the sub-menu and is very intuitive
The submenu can also be grayed/ungrayed instead of show/hide like in Titanium Backup

I do not know if you have to build from scratch though


The other option is to use radio buttons

- status bar: menu with 4 radio buttons (4 - 5 - 6 - ignore)

- show input method: menu with 3 radio buttons (show - hide - ignore)

- CRT effect: a simple approach is to keep it as it is and replace check-marks with 3 radio button menus for each of the 3 items : activate effect - deactivate effect - ignore

Another way is a menu box that gives on touch a 4 radio buttons menu (ignore/off/on/on+off). If ignore radio button is selected, a submenu box with only the check-box to add auto-orientation is grayed. When an option other than ignore is checked, the box for auto-orientation is ungrayed to be check-able.

Another option is to have the check box in the radio menu (I do not know if it needs to be done from scratch here too)

A less nice option, but clear and usable in my opinion is to have only radio buttons like for status bar. They would be: CRT-on / CRT-on+Auto / CRT-off / CRT-off+Auto / both / both+Auto / disable
It is a long radio buttons menu, but clear and maybe easier to implement for you

A last option for the CRT is if all check marks are disabled AND library is not loaded in framework installer, then it would keep actual setting. In other words, if the library is not loaded, the CRT effect is ignored completely (again, I do not know if it is feasible)

- Battery: a simple option is to keep it like it is for the sliders part. Only the last item with "Battery full notification" could be a radio button with (show - hide - ignore)

- Phone: radio buttons for each item of this menu

- Miscellaneous: radio buttons for each item of this menu

Hope it is clear what I mean with my bad English. Do not hesitate to ask me to explain it better for some parts. Radio buttons on all menus does not seem so bad for me and it makes it homogeneous interface wise.
The Following User Says Thank You to Phil3759 For This Useful Post: [ View ]
6th July 2012, 06:53 PM   |  #108  
Member
Thanks Meter: 32
 
33 posts
Join Date:Joined: May 2012
More
Thirst of all, thanks again for your great job! Now, some comments...

I very much agree with Phil3759 - some value like "use defaults" should be present, so users have a clear idea if Xposed overrides some values from ROM or not. For example, once I installed Xposed with Tweakbox my "CRT off" animation that was perfectly working before just stopped working without me changing any settings. It is because defaults in ROM and Tweakbox were different. Some tweaks can be disabled in Tweakbox by default, some - enabled, result of interaction of these settings with ROM settings (or defaults) is unpredictable. This is very confusing. What I'd like to see is that after installation all settings are set to "use defaults" state, so all overrides are disabled. And then features can be selectively enabled/disabled/tuned.

As for GUI I think the good way to implement this will be to have two tabs in the app, e.g. "Features" and "Configuration". On the "Features" tab you'll have complete list of features that are provided by application ("DPI override", "Locale override", SIP state override", "CRT animation override" etc.) with a simple checkbox for each. If checkbox is disabled (that should be default state after installation) then this particular feature of the app is completely disabled and ROM settings are in effect. On "Configuration" tab you'll have settings (more or less the same way as you have them now) but it'll only show the settings for the features enabled on the first tab. If nothing is enabled yet (e.g. right after installation) this tab can have some text like "Please select some features you want to use from the "Features" tab first." IMHO it'll be pretty simple to understand and it doesn't require implementation of any complex custom controls etc.
6th July 2012, 10:15 PM   |  #109  
rovo89's Avatar
OP Senior Recognized Developer
Thanks Meter: 15,376
 
2,386 posts
Join Date:Joined: Jan 2012
More
After investigating the problem with the hanging reboot button, I'm even more sure than before that this is a SuperSU bug (or incompatibility, as this is a very special situation that I guess no one else uses). As I see an automatic reboot as the last resort, I have asked Chainfire if he can slightly modify a part of a check: http://forum.xda-developers.com/show...3#post28380083

As for the "use defaults" option: The defaults are chosen how as they are in a stock Samsung ROM. So unless the ROM is customized, there are no changes by default. But ok, I'm getting that this is not the expected behavior for custom ROMs. However, I couldn't really decide yet how this could be implemented.

Honestly, I don't think the TB settings are intuitive. The stars just seem to say "this setting was changed from the default" if I get it correctly. This is a bit confusing if you sometimes see that the checkbox is checked and the star as well, and then you see other settings which are not checked but have a star nonetheless.
I also looked at the Dropbox option there. It just toggles the visibility of the submenu. This is ok in this case. But in Tweakbox, it would mean that we would need one of these toggles for each settings (or group of settings). Also, you would need to enable these toggles to see which tweaks are behind it. The same applies to the suggestion with the tabs. Generally, it is something to consider, but it's not very appealing and usable.

So I'm still thinking about other ways of implementing this (or if maybe I can live with anything suggested so far).
The Following User Says Thank You to rovo89 For This Useful Post: [ View ]
6th July 2012, 10:31 PM   |  #110  
Phil3759's Avatar
Recognized Developer
Thanks Meter: 32,038
 
9,397 posts
Join Date:Joined: May 2012
Donate to Me
Quote:
Originally Posted by rovo89

After investigating the problem with the hanging reboot button, I'm even more sure than before that this is a SuperSU bug (or incompatibility, as this is a very special situation that I guess no one else uses). As I see an automatic reboot as the last resort, I have asked Chainfire if he can slightly modify a part of a check: http://forum.xda-developers.com/show...3#post28380083

If Chainfire does not like to modify his check routine, you can prompt for a manual reboot, better than auto reboot. Few advanced users like this type of auto-reboot in my opinion.

Quote:

So I'm still thinking about other ways of implementing this (or if maybe I can live with anything suggested so far).

Thank you a lot for getting this in your plans, you have a great support
In fact, it is ok for stock ROMs, but some confusing on custom roms.

Edit: I have a question. When we update ROM or need to flash something, your framework needs to be uninstalled/removed?

Thank you again, a great tool, really

Thread Closed Subscribe to Thread

Tags
don't ask questions about modules here!!!, framework, xposed
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes