[Q] Why hasnt anyone messed with the special processors - Moto X Q&A

Since active notifications uses the special coprocessor why hasn't someone found the code and created an API required for its use. Apps like Knock Notifactions and others that make custom notifications would greatly benefit from using this.

also stuff like daydream
MarcusSi1516 said:
Since active notifications uses the special coprocessor why hasn't someone found the code and created an API required for its use. Apps like Knock Notifactions and others that make custom notifications would greatly benefit from using this.
Click to expand...
Click to collapse
this would work great with stuff like a modified version of Android Daydream

Related

develop option on ics

Any thoughts on why the OTA ICS upgrade enables the Develop option menu? Possibly AT&T mistakenly pushed it out, or did so on an extremely limited basis for testing purposes? Surely they wouldn't want just anybody messing with those settings. The Android version number is strange too, 4.0.3 710RD, when I see RD makes me think research & development.
No problems here, just wondering out loud.
I have seen this option on the Galaxy Nexus. I do believe it is a standard option for ICS.
Oh, I had assumed from the nature of the options inside and the fact that it seems to be at best awkwardly translated that it was a menu which was normally unavailable. A lot of older phones used to have secret menus like that unlocked by some convoluted series of actions.
ransack said:
Any thoughts on why the OTA ICS upgrade enables the Develop option menu? Possibly AT&T mistakenly pushed it out, or did so on an extremely limited basis for testing purposes? Surely they wouldn't want just anybody messing with those settings. The Android version number is strange too, 4.0.3 710RD, when I see RD makes me think research & development.
No problems here, just wondering out loud.
Click to expand...
Click to collapse
I've been wondering about the version myself...
Not sure if enabling it was intentional, but I know I found the "Stay Awake" option to be useful. Keeps the screen on while charging unless I turn it off using the power button.
It helps when using the phone at my desk as an audio player.
-Brett.
Also if u mess with the window animations and the other one below it ....u can turn it up to like 5x I believe it makes cool transitions on the windows and menus..
It's intentional, a feature (if you will) built into ICS. It's a part of AOSP builds as wel so it's ultimately up to the Mobile phone companies to leave it or not.

[REQ] NFC support for S II

have been using this rom since a month without problems and i got the "P" version of i9100 with nfc included, but obviously it not working with this rom. i'm thinking about of the implemetation on kernel of this option for i9100P users like me. i have been reading about that in xda, and i found this thread:
http://forum.xda-developers.com/showthread.php?t=1822447
but, its not continuous or seems to be stopped.
could be this feature implemented someday?
i think i found the driver of nfc chipset ,https://android.googlesource.com/ke...7456ef92735a1257c95eac44/drivers/misc/pn544.c
Edray said:
have been using this rom since a month without problems and i got the "P" version of i9100 with nfc included, but obviously it not working with this rom. i'm thinking about of the implemetation on kernel of this option for i9100P users like me. i have been reading about that in xda, and i found this thread:
http://forum.xda-developers.com/showthread.php?t=1822447
but, its not continuous or seems to be stopped.
could be this feature implemented someday?
i think i found the driver of nfc chipset ,https://android.googlesource.com/ke...7456ef92735a1257c95eac44/drivers/misc/pn544.c
Click to expand...
Click to collapse
The main problem is handling the fact that some of the NFC stuff behaves VERY badly if put into a device that doesn't have the hardware.
No one ever figured out a way to get it added to the P without either having a separate build or breaking the non-P I9100.
Although with the new infrstructure for "unified" device builds, this might now be possible.
As an FYI, the I777 (which REQUIRES a different build due to having different call audio, touchkeys, and a few other things) has NFC. The main blocker on the P was not wanting to create yet another build.
and it will be not possible a flashable zip with NFC enabler, and a script like superSU for not being erased by the updates?
thanks for your reply:good:
Edray said:
and it will be not possible a flashable zip with NFC enabler, and a script like superSU for not being erased by the updates?
thanks for your reply:good:
Click to expand...
Click to collapse
We don't do separate flashable ZIPs and stuff like that. Our build system doesn't support it, among other things.
One more in the request
I join to the kind request for this feature. As you know, NFC is now of use for payment and ID (to enter your office, for example), so I hope it makes sense for you to consider the effort and risk of creating a separate version in a near future. I can't adopt any ROM wo NFC unless I carry additional ID/VISA cards (2 more in my crowded wallet).
bajajel said:
I join to the kind request for this feature. As you know, NFC is now of use for payment and ID (to enter your office, for example), so I hope it makes sense for you to consider the effort and risk of creating a separate version in a near future. I can't adopt any ROM wo NFC unless I carry additional ID/VISA cards (2 more in my crowded wallet).
Click to expand...
Click to collapse
Sorry, but adding NFC to the I9100P won't help you here.
AOSP is missing HCE support for any device with an NXP NFC chipset. Until that changes, the I777/I9100P will not be payment capable even if NFC is added for P builds.

[NST/G] R.I.P. WeatherACE for the Nook Simple Touch

Another one bites the dust.
It took awhile for Wunderground's API to actually die, but it finally did and I used my last data point yesterday. None of the other APIs in the app (OpenWeatherMap, Norwegian MET, Yahoo) have worked for awhile. I tried the obvious with OWM and N-MET, getting new API strings, decompiling the app, replacing the APIs and stitching it all back together. But no joy. The data structures in the new APIs are probably different and that's way beyond me. The jiggered app ran, but it was unable to gather data from anywhere (other than what my location is).
Too bad. Nothing left like it, AFAIK.
Yeah, I'm bummed. Weather Ace was one of the few apps that had nice widgets appropriate for the eInk screen.
scotte9999 said:
Yeah, I'm bummed. Weather Ace was one of the few apps that had nice widgets appropriate for the eInk screen.
Click to expand...
Click to collapse
I came across this: https://f-droid.org/en/packages/org.jsharkey.sky/
It works, which is rare for something so old, but the widgets are butt-ugly on the NST
Looks like I'll be researching changing colors, etc. So far it looks like the icons could be easily replaced, but the most offensive part is the widget background which is a 9-patch png (of course...).
The WeatherACE developer is a nice fellow but it would be ridiculous to contact him over this. So we move on.
nmyshkin said:
I came across this: https://f-droid.org/en/packages/org.jsharkey.sky/
So we move on.
Click to expand...
Click to collapse
Indeed. I spent some time yesterday exploring web-based widgets, thinking we could just point the browser at a URL, but most widgets use HTTPS and Javascript, neither of which are the strong suit of the NST, even with Opera Classic instead of the native browser.
Did this work?
disTrck33 said:
Did this work?
Click to expand...
Click to collapse
Depends on what "this" is.
I eventually wrote my own weather widget app for the NST/G: https://forum.xda-developers.com/nook-touch/themes-apps/app-nst-weather-widget-t3946270
This works.
nmyshkin said:
I came across this: https://f-droid.org/en/packages/org.jsharkey.sky/
It works, which is rare for something so old, but the widgets are butt-ugly on the NST
Looks like I'll be researching changing colors, etc. So far it looks like the icons could be easily replaced, but the most offensive part is the widget background which is a 9-patch png (of course...).
The WeatherACE developer is a nice fellow but it would be ridiculous to contact him over this. So we move on.
Click to expand...
Click to collapse
Link said USA only . There is a weather app that can be used for Europe which uses yr.no site for data. It runs on my tablet and should work with Android 1.5+. Nothing special but good enough. Might require some customization to e-ink display though. That needs to be checked.
SJT75 said:
Link said USA only . There is a weather app that can be used for Europe which uses yr.no site for data. It runs on my tablet and should work with Android 1.5+. Nothing special but good enough. Might require some customization to e-ink display though. That needs to be checked.
Click to expand...
Click to collapse
Didn't remember the US restriction, but all of the potential apps I looked at back then looked terrible on the NST or required network location. That is why (shameless promotion...) I eventually worked up my own Weather widget/app just for the NST. It lacks many bells and whistles but will work for any locale that OWM has stations. And, if I say so myself, looks pretty good on the NST.
nmyshkin said:
Another one bites the dust.
It took awhile for Wunderground's API to actually die, but it finally did and I used my last data point yesterday. None of the other APIs in the app (OpenWeatherMap, Norwegian MET, Yahoo) have worked for awhile. I tried the obvious with OWM and N-MET, getting new API strings, decompiling the app, replacing the APIs and stitching it all back together. But no joy. The data structures in the new APIs are probably different and that's way beyond me. The jiggered app ran, but it was unable to gather data from anywhere (other than what my location is).
Too bad. Nothing left like it, AFAIK.
Click to expand...
Click to collapse
The app is not dead.
I working on adding more weather sources. Atm, the app has 5 weather sources worked correctly - NOAA (USA only), OpenWeatherMap, Norwegian MET (yes, its back to work again, I switched WeatherACE to the their new API), Weatherbit.IO (new weather sources that added to WeatherACE in last build 1.12.30) and Forecast.IO (they are not provide new keys atm). Currently I working on 2 more weather source.
As for Wunderground, they were bought by IBM. The lowest price for weather data from IBM is around of $10000 per year, for a limited set of data. They also provide some weather API for people that provide them data from personal weather stations, but its just current and few days weather and no hourly data forecasts...
So, please check the app again.
mycodefab said:
The app is not dead.
I working on adding more weather sources. Atm, the app has 5 weather sources worked correctly - NOAA (USA only), OpenWeatherMap, Norwegian MET (yes, its back to work again, I switched WeatherACE to the their new API), Weatherbit.IO (new weather sources that added to WeatherACE in last build 1.12.30) and Forecast.IO (they are not provide new keys atm). Currently I working on 2 more weather source.
As for Wunderground, they were bought by IBM. The lowest price for weather data from IBM is around of $10000 per year, for a limited set of data. They also provide some weather API for people that provide them data from personal weather stations, but its just current and few days weather and no hourly data forecasts...
So, please check the app again.
Click to expand...
Click to collapse
No, it's not dead. In fact, I run it on most of my devices. I really appreciate the clean-looking widgets and I would recommend it to anyone looking for a good weather app with widgets.
Sadly, in the context of this forum, it is "as good as" dead since the old version that would still run on Android 2.1 can't connect to any of the weather services any longer
I'm sorry if Google-bots picked up this posting and are making it seem like the app is non-functional. I've edited the post title so that maybe in the future that will be corrected.
nmyshkin said:
No, it's not dead. In fact, I run it on most of my devices. I really appreciate the clean-looking widgets and I would recommend it to anyone looking for a good weather app with widgets.
Sadly, in the context of this forum, it is "as good as" dead since the old version that would still run on Android 2.1 can't connect to any of the weather services any longer
I'm sorry if Google-bots picked up this posting and are making it seem like the app is non-functional. I've edited the post title so that maybe in the future that will be corrected.
Click to expand...
Click to collapse
Hmm... What version of WeatherACE you use on the old device? Its too bad that I didnt used VCS (version control system) in the time (like I do it now). But I still have backups of source code of some really old versions of the app. The oldest is 1.6.2, then 1.7.4, 1.80, etc.
Not sure if Google will allows me to make it (uploading to Google Play will not be possible for sure), but I could try at least. If everything depended on me, the application would continue to support android 2.1 (or 2.3 was in the very first version, I don't remember exactly). Unfortunately, Google constantly demands to gradually raise the minimum API, and with it, support for older devices decreases.
mycodefab said:
Hmm... What version of WeatherACE you use on the old device? Its too bad that I didnt used VCS (version control system) in the time (like I do it now). But I still have backups of source code of some really old versions of the app. The oldest is 1.6.2, then 1.7.4, 1.80, etc.
Not sure if Google will allows me to make it (uploading to Google Play will not be possible for sure), but I could try at least. If everything depended on me, the application would continue to support android 2.1 (or 2.3 was in the very first version, I don't remember exactly). Unfortunately, Google constantly demands to gradually raise the minimum API, and with it, support for older devices decreases.
Click to expand...
Click to collapse
And I completely understand that. It's why I said in post #3 that it would be silly to contact you about this. I still remember how promptly and helpfully you responded to a question I had about more recent versions of the app I was running on my tablet. But restructuring an app that, in Android terms, is nearly an archaeological artifact, is not, I'm sure, a simple matter.
In any case, it looks like this version (1.4.4) is earlier than anything you may still have source code for.
nmyshkin said:
And I completely understand that. It's why I said in post #3 that it would be silly to contact you about this. I still remember how promptly and helpfully you responded to a question I had about more recent versions of the app I was running on my tablet. But restructuring an app that, in Android terms, is nearly an archaeological artifact, is not, I'm sure, a simple matter.
In any case, it looks like this version (1.4.4) is earlier than anything you may still have source code for.
Click to expand...
Click to collapse
Seems like the last version that support Android 2.1 and 2.2 is version 1.7.4 and I have sources for it. The changes log for 1.7.4 has mention about such fixes "Hotfixed crash on devices with android 2.1 - 2.3.X for weather alerts"." The version support WeatherACE API for external apps/widgets/early verions of tasker plugin, weather alerts and Forecast.IO source.
Luckily, there is a place where you can get almost any version of this app https://4pda.ru/forum/index.php?showtopic=511055&st=0 The last spoiler in the start post has links to my posts with most of the versions of WeatherACE. So, if you will have time, please try 1.7.4 from the post https://4pda.ru/forum/index.php?s=&showtopic=511055&view=findpost&p=32402422
If 1.7.4 will work for you. I could try to build it from the sources I have. In case it will build correctly, it will not be so hard to update support for OpenWeatherMap and Norwegian MET.NO weather sources. Probably I also could add support for Weatherbit.IO.
mycodefab said:
Seems like the last version that support Android 2.1 and 2.2 is version 1.7.4 and I have sources for it. The changes log for 1.7.4 has mention about such fixes "Hotfixed crash on devices with android 2.1 - 2.3.X for weather alerts"." The version support WeatherACE API for external apps/widgets/early verions of tasker plugin, weather alerts and Forecast.IO source.
Luckily, there is a place where you can get almost any version of this app https://4pda.ru/forum/index.php?showtopic=511055&st=0 The last spoiler in the start post has links to my posts with most of the versions of WeatherACE. So, if you will have time, please try 1.7.4 from the post https://4pda.ru/forum/index.php?s=&showtopic=511055&view=findpost&p=32402422
If 1.7.4 will work for you. I could try to build it from the sources I have. In case it will build correctly, it will not be so hard to update support for OpenWeatherMap and Norwegian MET.NO weather sources. Probably I also could add support for Weatherbit.IO.
Click to expand...
Click to collapse
That would be amazing. Unfortunately I get a 404 error when I try to download the app. I always get the error on that site. Not sure if you have to be logged in or what. I'll keep searching for the correct version.
nmyshkin said:
That would be amazing. Unfortunately I get a 404 error when I try to download the app. I always get the error on that site. Not sure if you have to be logged in or what. I'll keep searching for the correct version.
Click to expand...
Click to collapse
Please try http://mycodefab.com/files/WeatherACEv1v7v4.apk
mycodefab said:
Please try http://mycodefab.com/files/WeatherACEv1v7v4.apk
Click to expand...
Click to collapse
Thanks so much. I tried this version on two NSTs, one with Network Location enabled and the other without. It works on both to the extent I can judge without any weather data being fetched. No sudden crashes or odd behavior. The map at the initial setup is blank, but that was the case in 1.4.4 (something to do with e-ink and the assumptions for default themes, I guess). Anyway, the map does not matter if you can type in your own geocoordinates which is what I did on the device without Network Location.
So this looks like a good candidate.
nmyshkin said:
Thanks so much. I tried this version on two NSTs, one with Network Location enabled and the other without. It works on both to the extent I can judge without any weather data being fetched. No sudden crashes or odd behavior. The map at the initial setup is blank, but that was the case in 1.4.4 (something to do with e-ink and the assumptions for default themes, I guess). Anyway, the map does not matter if you can type in your own geocoordinates which is what I did on the device without Network Location.
So this looks like a good candidate.
Click to expand...
Click to collapse
OK, thanks. In case you have DarkSky API key (the app know it as Forecase.IO, it was an old name of the DarkSky API) please use it with the version 1.7.4, the app version support the weather source. Once purchased by Apple, DarkSky (Forecast.IO) no longer give out free keys. But any old keys continue to work atm, as far as I know.
Building a new version with updated support for weather sources will take some time. As usual, most problems in the case are not related with app itself, but with other libraries. For example, a library that provided map does not support Android 2.1 anymore, so probably I will need to completely remove map from the app. Google libraries related with analytics and ads - also does not support old android versions anymore. I will work on it this weekend.
nmyshkin said:
Anyway, the map does not matter if you can type in your own geocoordinates which is what I did on the device without Network Location.
Click to expand...
Click to collapse
You need GPS.
nmyshkin said:
So this looks like a good candidate.
Click to expand...
Click to collapse
OK, seems like its done http://mycodefab.com/files/WeatherACEv1v7v4v2.apk Hope it will work, because I dont have Android 2.1 devices to test. In case of problems, I will try to find something.
The version support 2 weather sources - OWM (open weather map) and Norwegian MET.NO.
Limitations:
1. Removed weather map and adding locations via map. I cant find any android weather libraries that support Android 2.1 devices.
2. Removed ads for same reason.
3. Weather icons limited to the small set of icons inside the app + 1 custom icon set.
As for custom icon set, its mostly same as for latest versions of WeatherACE, just a bit different directory for images. Directory is "Android/data/mycodefab.aleph.weather/files/custom/icons/". It use same format as for the latest versions. So, for example, for "clear sky in day" condition it will use "d_100.png" file, "clear sky in night" will look for "n_100.png" file, "overcast" will use "d_104.png", etc.
In case the version of the appt will start, but not show the weather after weather info update, please get to Menu->Settings->Advanced->Weather Sources. Here you could see Active weather sources on the top. Tap on it. Uncheck OpenWeatherMap and Norwegian MET, tap OK. Enter Active weather sources again. Set check OpenWeatherMap and Norwegian MET, tap OK. It will recheck availability of sources for existing locations and will update the weather info.
mycodefab said:
OK, seems like its done http://mycodefab.com/files/WeatherACEv1v7v4v2.apk Hope it will work, because I dont have Android 2.1 devices to test. In case of problems, I will try to find something.
Click to expand...
Click to collapse
I tried the app on both devices (with and without Network Location). Unfortunately it does not want to run
There is immediate funny business as the package shows in the file manager as a generic "package" icon rather than the app icon. Also, the package name (and generic package icon) are displayed in the launcher rather than the app icon and name.
I've attached a section of a logcat for trying to open the app. I don't know whether it has information that is helpful.
It may or may not have any bearing on what you have done, but as you're already going way beyond any expectations, I would suggest that leaving the app alone except for fixing the weather sources would be more than enough. I can understand your desire to have things "right". I have that same problem , and I do appreciate it, but maybe without so many changes there would be a better chance of the app still working, which is what it did even now, except for the access to weather sources. Of course, it's probably not that simple.
Thanks for your efforts.

[Xposed] (Security) Disable Quick Settings Pulldown on Lock Screen

This is just a simple Xposed module that disables pulling down the notification shade / quick settings tiles while on the lock screen (but doesn't break media player controls on lock screen). Only tested on Pixel 4 and Pixel 4 XL on Android 10 (more on this later).
Background: This has always been an annoying aspect of Android for me, and it's dumb from a security standpoint. Being able to pull down the quick settings tiles on a locked phone is dumb. Why hasn't Android natively built this in yet? Using this and Gravity Box to disable power menu on lock screen makes me feel a lot better in the event my phone ever gets lost or stolen. It's dumb that anyone can steal your phone and immediately toggle your settings (turn off WiFi, Mobile Data, toggle Airplane Mode, etc) and/or turn the phone off... I've been spoiled for years by the OG HTC devs (particularly LeeDroid and Team Venom) and their ROMs with these features baked in, so it's back to using Xposed to fill that gap for me and my wife, lol. Anyway, I pair these mods along with the Lockwatch app from Play Store and it gives me more peace of mind. Hey, anything to increase the chances of recovering a lost or stolen phone, am I right?
Credits / Technical Details: This module is based off of char101's published Xposed Repo module, and all credits and thanks should go to him. This is the first app / APK I've compiled so it was a nice learning experience, but it was all based off of his source and I really just needed to remove a few lines of code to get it to work properly with our phones. His mod worked fine and disabled the quick settings pull down on the lock screen, as intended. The problem was that it would also prevent media player controls from functioning (and I would assume other possible functions as well). To fix this, I just removed DISABLE2_NOTIFICATION_SHADE references from the code, leaving DISABLE2_NONE and DISABLE2_QUICK_SETTINGS untouched. The mod still works perfectly as intended. Only tested on Pixel 4 / 4 XL on Android 10. I'm sure it would work on other devices as well.
I really just did this on a whim for me and my wife's own phones and wasn't planning on sharing it, but I figure other people may have also wanted this for their P4's as well, so enjoy. Again, all thanks go to @char101!
Installation:
- Download .APK file attached to this post.
* If you have char101's original module installed already, I would highly recommend uninstalling it first.
- It's an Xposed module. Install the APK and enable in your Xposed Manager.
- Reboot and test.
Based on: https://repo.xposed.info/module/com.github.char101.qslock
Source for modified module: https://github.com/i5lee8bit/xposed-qslock-P4mod
thanks for this!!! any difference between this one and the one posted on the XL forums?
vdevl said:
thanks for this!!! any difference between this one and the one posted on the XL forums?
Click to expand...
Click to collapse
Nope, they are exactly the same. I have a 4 XL and got my wife the regular 4, and so I've been posting on both forums to share some of my findings on both devices. I just figured most 4-only owners probably won't be checking the 4 XL forums, and since this mod worked perfectly on my wife's phone I wanted to share with both communities. Glad to help though!
PS: Please try to refrain from quoting the entire OP, it makes the thread kind of cluttered. Just for future reference. =)
thanks much dude! gonna try edxposed with this module for 1st time after kitkat days. Miss those easy android days.
Appreciate the effort youre putting for sharing mods and patched boot imgs. Cool guy
i5lee8bit said:
This is just a simple Xposed module that disables pulling down the notification shade / quick settings tiles while on the lock screen (but doesn't break media player controls on lock screen). Only tested on Pixel 4 and Pixel 4 XL on Android 10 (more on this later).
Background: This has always been an annoying aspect of Android for me, and it's dumb from a security standpoint. Being able to pull down the quick settings tiles on a locked phone is dumb. Why hasn't Android natively built this in yet? Using this and Gravity Box to disable power menu on lock screen makes me feel a lot better in the event my phone ever gets lost or stolen. It's dumb that anyone can steal your phone and immediately toggle your settings (turn off WiFi, Mobile Data, toggle Airplane Mode, etc) and/or turn the phone off... I've been spoiled for years by the OG HTC devs (particularly LeeDroid and Team Venom) and their ROMs with these features baked in, so it's back to using Xposed to fill that gap for me and my wife, lol. Anyway, I pair these mods along with the Lockwatch app from Play Store and it gives me more peace of mind. Hey, anything to increase the chances of recovering a lost or stolen phone, am I right?
Credits / Technical Details: This module is based off of char101's published Xposed Repo module, and all credits and thanks should go to him. This is the first app / APK I've compiled so it was a nice learning experience, but it was all based off of his source and I really just needed to remove a few lines of code to get it to work properly with our phones. His mod worked fine and disabled the quick settings pull down on the lock screen, as intended. The problem was that it would also prevent media player controls from functioning (and I would assume other possible functions as well). To fix this, I just removed DISABLE2_NOTIFICATION_SHADE references from the code, leaving DISABLE2_NONE and DISABLE2_QUICK_SETTINGS untouched. The mod still works perfectly as intended. Only tested on Pixel 4 / 4 XL on Android 10. I'm sure it would work on other devices as well.
I really just did this on a whim for me and my wife's own phones and wasn't planning on sharing it, but I figure other people may have also wanted this for their P4's as well, so enjoy. Again, all thanks go to @char101!
Installation:
- Download .APK file attached to this post.
* If you have char101's original module installed already, I would highly recommend uninstalling it first.
- It's an Xposed module. Install the APK and enable in your Xposed Manager.
- Reboot and test.
Based on: https://repo.xposed.info/module/com.github.char101.qslock
Source for modified module: https://github.com/i5lee8bit/xposed-qslock-P4mod
Click to expand...
Click to collapse
thanks, mate, it's working perfectly on poco f3 android 12.1 lineageOS
Thank you so much for sharing this!!!!!!!
i5lee8bit said:
Nope, they are exactly the same. I have a 4 XL and got my wife the regular 4, and so I've been posting on both forums to share some of my findings on both devices. I just figured most 4-only owners probably won't be checking the 4 XL forums, and since this mod worked perfectly on my wife's phone I wanted to share with both communities. Glad to help though!
PS: Please try to refrain from quoting the entire OP, it makes the thread kind of cluttered. Just for future reference. =)
Click to expand...
Click to collapse
are you able to update the app to work with android 13. Am using a pixel 6 and the app doesnt work
v.konvict said:
are you able to update the app to work with android 13. Am using a pixel 6 and the app doesnt work
Click to expand...
Click to collapse
I was able to modify the code to run in android 13, see my reply at https://forum.xda-developers.com/t/...n-on-lock-screen.4076593/page-2#post-88165351

New Xposed API Proposal

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.
siavash79​Yeah 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

Categories

Resources