Hi,
Here is what I want to hook: https://github.com/android/platform...a/android/content/pm/PackageParser.java#L1212
I want minVers was always lower than SDK_VERSION.
So I had thought that the easiest way is change field SDK_VERSION. But then I saw it is constant - https://github.com/android/platform...va/android/content/pm/PackageParser.java#L150
Is possible to hook it? Or find other way (hook Build.VERSION.SDK_INT?)
Not AFAIK.
You could recreate the last part of that method if the minVers check is true (after recreating that check, too), I suppose.
Not sure what you're trying to accomplish but hooking something like SDK_VERSION, even if it were possible, sounds like a horrible idea.
Probably res. I have decided to ditch this idea (i wanted to enable install apks which are targeted for higher OS ver than user has)
I am using a hm-10 to connect to my Android test application. Unfortunately, is a big struggle compared to the hc-05 device. Anyway. The "samplegatt" does not work, either with my device or for whatever reason. So I found a different blog that explains the sample must be modified:
(the dumb forum won't allow me to post a link)
ayh tee tee pee android-er.blogspot.com/2015/12/connect-hm-10-ble-module-to-android.html?showComment=1454055306623#c9017603593836048433
So after the modifications, THAT won't work either. It's not the first one, just the most recent.... I have tried so many example applications from google searching, I have saturated my efforts. I KNOW the module can work with my phone, from using a ble test application from play store (that I can't seem to find company website or track down the source code for).
I was hoping to know if anyone else struggled with this, and if you can advise me on how / where to get a working sample application.
It turns out, the new changes for sdk version 23 require all types of permission changes in the code, since someone decided it was a good idea to enable gps location in order to use bluetooth. I had to change my target sdk back to 22 and the samples started working.
Hello, dear community,
I just recently got me a P10 (Stock ROM / rooted (Magisk) / HyperPlus kernel ) and was wondering why there is not auto-brightness setting available. I can neither find a toggle in the quick settings nor anything in the 'normal' display settings. I obviously searched Google/XDA but there doesn't seem to be anybody else missing it, only found some reports about screen dimming problems with EMUI 8 when openingsome apps, which seems to be a totally different issue.
Has this 'feature' been disabled with a recent update or did the Huawei P10 never have it at all? Could it have something to do with my phone begin rooted (Magisk), using a different kernel (HyperPlus) or choosing another design?
Thanks in advance for any help
Auto brightness is included in stock and in open kirin lineageos.
Well, that's what I've thought. But do you have any idea why this setting might not be available to me? If necessary I could provide screenshots... Is it enabled by default and just can't be turned off?
I definitely have to adjust it manually for different lighting conditions...
I posted a thread a while back here about the same problem I had with a stock P10.
After its 1st update, lost auto brightness setting. In the end, had to send it back to Huawei UK for them to sort out.
Could only suggest reinstalling your software from Firmware finder and hope that cures it. If not, you may have to get in touch with Huawei.
I am looking for a Magisk module / Root application that allows me to adjust the microphone gain globally, so that all recordings using other applications will be affected. Does any such solution exist?
Not as far as i know as the mixer paths/pins can be device specific.
Its been asked before
i.e. I used to have a mixer config for my old Note 4, doesnt work on my Pixel 2 XL due to above
The file to edit if you want to try is (on most modern device) /vendor/etc/mixer_paths_<yourdevicename>.xml - always make a backup
MIC is probably a good start on what to search for, but as there are many entries, i cant tell you which is likely to be the right one
Your best bet is to look in your own devices thread to see if anyone has a) reported the same issue and b) if they have a solution
If you can find a set of mixer_paths<yourdevicename>.xml settings that work, its trivial to make it into a module if you wanted to for personal use across any ROMs you may flash, or to share with others for your device
Skvalex used to have a great app called ALSA Mixer than i used years ago to do the testing before making it either into a flashable zip for others with our device or later into a magisk module for our devices users, but its been long out of print on the Play Store....and i cant find alternative to recommend in 5 minutes of looking
p.s. Also be aware that individual apps can impose their own gain limits regardless of what the mixer_paths file sets, so a universal level may not be possible
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
You can vote at the LSPosed Telegram group or write your opinion here. Also we are glad to hear your suggestions about the new API.
@AndroidX @siavash79 @Dark_Eyes_ @firefds @David B. @Quinny899 @wanam
Just mentioning you guys since you're all active here on XDA. Please see the first post.
Regards,
shadowstep
Senior Moderator
Dr-TSNG said:
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
You can vote at the LSPosed Telegram group or write your opinion here. Also we are glad to hear your suggestions about the new API.
Click to expand...
Click to collapse
Thanks for getting opinions
1. Xshared preferences interface overhaul is good news since it was always unstable for me. I personally switched to remote preferences API for AOSPMods
2. When going to systemUI and framework, it's sometimes very difficult and complicated to change some variable values through Xposed, specially with R8 code optimizations which dramatically limit the points we can hook into code.
There are two workarounds I know of, being Xposed resource hooking that can be also dynamic in runtime, or overlays, which being static, still limit the way we can change resources dramatically.
So, I'd really suggest keeping it in the API
siavash79 said:
2. When going to systemUI and framework, it's sometimes very difficult and complicated to change some variable values through Xposed, specially with R8 code optimizations which dramatically limit the points we can hook into code.
Click to expand...
Click to collapse
For R8 code optimizations, we introduced a new API to parse dex file, which allows modules to find methods/fields more accurately.
Anyway if we finally decide to keep resources hook API, do you have any suggestions on keeping/adding/removing specific methods of it or refine it to a more modern interface?
Perfect news.
About resource hooking, few things to note are that: it can't differentiate between different resource files, for example normal values vs landscape or dark/light values. It would be great if there's a way to push different values to different resource files.
Also, there are more limitations when talking about special resources such as themes. As an example, in AOSPMods, one of the reasons it's a magisk module instead of being a normal APK is that overlay files have to be used in cases that need modification of theme resources and that can't be done via resource hooking.
I personally love to get a more complete/flexible resource hooking API, but I completely understand if that's too much to ask. So even keeping it as currently is would be good enough
Thank you @shadowstep for bringing this to my attention!
Dr-TSNG said:
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Click to expand...
Click to collapse
That's wonderful news, although I do not quite understand what you have against the new XSharedPreferences interface. I use it in my modules, and I've never had any issues with it.
Dr-TSNG said:
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
Click to expand...
Click to collapse
I am not currently using the resources hook in any of my modules, so removing it would not impact me, but even so, I'm not a fan of the suggestion to get rid of it completely. I think that at the very least, it should be kept as maintain-only. It is unfortunate that it does not work with Taichi, but given that Taichi isn't a true Xposed implementation, I'm not sure that it's worth worrying about.
This looks great, I've been waiting for it since the initial issue talking about it. Prefs are always a pain to handle, and while the "new" method worked, I always preferred to use a Content Provider, which was nerfed in Android 12.
Really like the idea of setting the scope, it would be beneficial to the Xposed part of DarQ, the only suggestion I have is to make sure it includes some sort of "am I enabled?" check - currently I use self hooks (literally the module hooking itself and changing a method returning false to true) to verify it's enabled, but it doesn't seem to be foolproof as people sometimes still complain it doesn't work.
Quinny899 said:
the only suggestion I have is to make sure it includes some sort of "am I enabled?" check
Click to expand...
Click to collapse
Of course does, and the module app can get more info about the the Xposed state like it's under which framework and which version, and whether it is rootless or not without self-hooking.
You can view the detail here.
@shadowstep Thanks for the head up.
Glad to see a new api to manage configs across apps, shared prefs has been always painful to handle even with the new-xshared prefs.
I would suggest having an api to get the version name of scope's package, I'm aware of some workarounds that help get the version name, but it's not a reliable solution on the latest Android versions, this information is needed for logging/debugging purposes.
@Dr-TSNG thanks and keep up the good work.
@Dr-TSNG Thanks for new api I was wating for this api from more then 1 year coz when I build my first module (Android Faker) its was really pain in ass coz of Xsharedpreference after some research I found better solution which was remote preference but Quinny899 mention in Github issue that its not work in android 11 so after that I move to new Xsharedpreference which was introduce by lsposed team and its working great but its still create issue in some devices so I think it will be a better solution if we get it soon and I am not sure about resources hook coz I don't use it before .
The problem with xshared preferences is that if the apk is a system app it won't work for some reason. Only works on user apps
siavash79 said:
The problem with xshared preferences is that if the apk is a system app it won't work for some reason. Only works on user apps
Click to expand...
Click to collapse
Interesting. I use XSharedPreferences in a System Framework hook and haven't had any issues with it.
David B. said:
Interesting. I use XSharedPreferences in a System Framework hook and haven't had any issues with it.
Click to expand...
Click to collapse
Is your module installed as APK or as magisk module?
Try mounting it to system through magisk and preferences will stop working
siavash79 said:
Is your module installed as APK or as magisk module?
Try mounting it to system through magisk and preferences will stop working
Click to expand...
Click to collapse
It's installed as an APK. I misunderstood what you had said earlier. I thought you meant that the hook doesn't work when you try to use it on system APKs. I didn't realize that you meant that it doesn't work when the module is itself a system APK.
siavash79Yeah I agree with this and in my testing if you set target sdk 23 its doesn't matter if its as system app or user its work without any issues but its not worth coz it have some other issues
Thank you for accepting the API invokeSpecial() !
Add invokeSpecial · libxposed/[email protected]
Fix #2
github.com
Implement invoke special and new instance special · LSPosed/[email protected]
LSPosed Framework. Contribute to LSPosed/LSPosed development by creating an account on GitHub.
github.com
Looking forward to the new API release.
Happy Chinese New Year!
I just want to see @M66B happy again
Somewhat unrelated, but is there any chance of seeing original Xprivacy return or compatibility? I think it's a lot better than Lua
lawrencee said:
Somewhat unrelated, but is there any chance of seeing original Xprivacy return or compatibility? I think it's a lot better than Lua
Click to expand...
Click to collapse
No. Xprivacy will never "return".
XPrivacyLua is the best ever