Related
I'm undertaking a stupid project and would like to ask some questions of some more experienced developers. Yes I know there's no practical reason for this, and no you cannot talk me out of it.
I would like to create a sort of "super nerd" adaptation of CyanogenMod for command line Linux junkies, or at least for Comp Sci grad students like myself. I want my phone to be able to recompile and reinstall nearly everything it runs. Yes I know that's a painful and slow operation: I did "emerge tightvnc" on a chroot Gentoo install and the command took about 18 hours. I remain undeterred.
Questions:
Sun JDK is apparently not available for arm7a. Am I reading the docs correctly, and one can indeed use Apache Ant to compile Android? Or is Ant not what I think it is? I'm not opposed to creating a small Bochs VM that boots, mounts a network filesystem, executes some JDK task, and then signals to terminate. I'd rather not if I can help it though.
How much access does the radio hardware get to the rest of the system? If I were to store something personal in an encrypted loopback partition, could someone abuse direct memory access to read from memory without the host OS knowing about it?
Has anyone played with adapting the Android boot process to use System V type init scripts? I'd like to make it easy for Tasker to say "we're running out of memory -- go from init level 5 to something arbitrary, say 7, which stops some services. Oops, still low, go init level 8, which disables more services.
I definitely plan on sharing my work. What do you guys think of the name CyanoGentoo?
Thanks all.
Apparently Apache Ant is not what I thought it is.
How about this then: does anyone know where I might find a community for people interested in general purpose computing on an Android phone?
Michael Spencer said:
Apparently Apache Ant is not what I thought it is.
How about this then: does anyone know where I might find a community for people interested in general purpose computing on an Android phone?
Click to expand...
Click to collapse
Don't know if you're still around but I'm very interested in helping and believe I may already have some solutions for you. If you're still running chroot or another form of ARM Linux distro (Debian based is what I'm coding for at the moment) then check my github
https://github.com/S0AndS0/Debian-Kit-Mods
The readme file has directions on how to clone and run the main modding script which curently has at least one if not two options that'll peek your interest for sure.
One set of options will download and install Java's JDK (either hard float or soft float) and another will download and install jMonkey (a user friendly programing SDK built on eclips) which will get you one step closer to compiling things on an Android device for Android devices. However, I've yet to crack running "Android SDK" because they have yet to reliece an ARM compatible source and "wine" (a Linux package for emulating other CPU's) is still under heavy development, so building Android from source and such is still out of the scope of what I've been able to script up for easy use.
On a side note; a quick google search of my user name and the key words guide, linux, jdk, arm and xda will result in links of what I've written up on enteracting with Linux on Android if you get stuck anywhere.
And if you search "raspberry pi android adb similar:xda" you'll find what I'll likely be working on bringing to Android; after debugging the script I'm working on to set up a Brendle (one of many methods of "cloud computing" availible for ARM) node/network through all availible network interfaces (bluetooth, 3G/4G, wifi) on Android.
Sent from my SPH-D700 using xda app-developers app
I am still around, and when I get a chance I'll take a look. I think I'm mostly satisfied with AIDE and chroot Ubuntu.
And those worried about dma exploits via radio hardware need only use a wifi-only device with a portable hotspot, I've concluded. No way to prevent these exploits otherwise.
Thanks again.
Michael Spencer said:
I am still around, and when I get a chance I'll take a look. I think I'm mostly satisfied with AIDE and chroot Ubuntu.
And those worried about dma exploits via radio hardware need only use a wifi-only device with a portable hotspot, I've concluded. No way to prevent these exploits otherwise.
Thanks again.
Click to expand...
Click to collapse
Indeed AIDE has been a fantastic tool for me as well.
Heh dma was indeed a concern of mine among other security issues with running Linux over 3/4G but its to bad there's no solution yet. I'm using old phones and tablets for most tests but try as I might I can't break into them from out side my hotspot network... even though I can connect to the divice running the hotspot remotely if it is running Linux too.
hmm, I'm working on a new script of examples for networking now, lots of building blocks to my latest project, which may help new scripters with some networking tedium of finding and assigning specific IP's to variables so they can be shared or saved or modified into other commands quickly. This will upon compleation will be one of the references for other scripts I'm working on for getting openstack and MPI running on multiple devices swiftly.
Speaking of MPI; the installer for Bramble on Android now works (install option 2 within for Debian Kit users) for getting that software package installed and all that is left to work on is the setup for machine files and sshkeys for multi-node quick set-up.
Two questions; seeing as how you have AIDE, perhaps you might be able to help with my other project that I'm working on? I've another github repo where I'm working to incorporate a; soft/hard float Linux installer, terminal emulator, rdp/vnc client, scripter, and forwarding of Linux GUI to a second device and/or Chromecast of a specific desktop or Linux window with x11... Currently stuck on the terminal but still very new to Java for Android.
or because that's a bit much to ask; perhaps some help with Android scripting for installing Linux on Android that uses Debian Kit's methods to provide hard float or soft float?
I'll be around and have modified my sig for easier tracking and will be pushing more updates to github today, hopefully by the end of the day have a sshkey passer script for quickly setting up passwordless remote login. After that will be some work on setting up bridges between USB, Bluetooth, Wifi, and any other network interface available for faster transfer of large data sets.
Edit 03192014
Michael Spencer said:
Has anyone played with adapting the Android boot process to use System V type init scripts? I'd like to make it easy for Tasker to say "we're running out of memory -- go from init level 5 to something arbitrary, say 7, which stops some services. Oops, still low, go init level 8, which disables more services.
Click to expand...
Click to collapse
Check out the Debian Kit app, from what I have found it exposes all of the Linux processes and file system to Android and if running as root user on Linux then the full Android file system is exposed too. Debian Kit doesn't use chroot to run Linux so it's "possible" to run a chroot environment at the same time. And running "ps" commands on Android or Linux terminals, produce nearly identical output, of both Linux and Android processes happily running meaning that if Tasker can't see these processes then a script can run the "ps" command and run a command to shut down Linux processes; likely it's a bit more complex because re-starting those services or even suspending some could cause un-wanted behavior. Still though with testing and time it is possible to have the memory better managed.
Update 03312014- Back on making your phone compile itself subject; I'm working on using(/scripting an installer for) OpenStack on Android, which has QEMU for emulating CPU processors which will eventually allow us to install Android SDK on Android(s) running Linux. I'm using OpenStack because to emulate a normal PC processor one even a quad core ARM processor is really slow (use to be an app for this called Limbo PC emulator but last I searched the market place this app was gone) so using OpenStack will allow us to throw what ever extra Android phones into a pool of sharable CPU power; essentially I'll be creating a 7 or 8 (virtual) core processor out of networked Android phones and then emulate a 2 or 4 core x86 processor within and install the tool kits for android that have CPU requirements.
I've other plans for OpenStack too but those will require that I incorporate mesh networking and google translate. So that users anywhere can build a cloud of shared processing power.
Sent from: SPH-D700 or myTouch3Gs or Sero 7 Pro
Linux Install guide for Android devices that I'm writing:
http://forum.xda-developers.com/showthread.php?t=2240397
Or
https://docs.google.com/document/d/1ssVeIhdBuuy8CtpBP1lWgUkG6fR6oHxP20ToYPPw6zI/edit?usp=drive_web
And my script pack for installing; Java's JDK, node.js and more to your Linux OS
https://github.com/S0AndS0/Debian-Kit-Mods
Note: if you're new to Linux/scripting/command line; check readme file for instructions.
http://www.timelesssky.com/blog/building-android-sdk-build-tools-aapt-for-debian-arm
http://www.timelesssky.com/blog/develop-app-on-android-with-android-sdk
Hey all found the ^answer^ if you've not already found this blog then you all are in for a treat dig around on that above site and you'll find some other really cool stuff for Linux Android systems.
Sent from: SPH-D700 or myTouch3Gs or Sero 7 Pro
Linux Install guide for Android devices that I'm writing:
http://forum.xda-developers.com/showthread.php?t=2240397
Or
https://docs.google.com/document/d/1ssVeIhdBuuy8CtpBP1lWgUkG6fR6oHxP20ToYPPw6zI/edit?usp=drive_web
And my script pack for installing; Java's JDK, node.js and more to your Linux OS
https://github.com/S0AndS0/Debian-Kit-Mods
Note: if you're new to Linux/scripting/command line; check readme file for instructions.
This thread is intended for module developers. Make sure you follow it (i.e. subscribe) to be informed about any API changes and additions.
I will announce changes before the release if they might make existing modules incompatible.
If you're interested in more details, you can follow the GitHub repositories:
https://github.com/rovo89/XposedBridge/commits/master
https://github.com/rovo89/Xposed/commits/master
https://github.com/rovo89/XposedInstaller/commits/master
Here you can also download the API jar file that you need to reference from your project. Make sure you read the development tutorial to understand how it works. Especially make sure that the classes are not included in your APK, but only referenced.
Note that I will only post the latest API version here to drive the adoption of updates.
This is on pretty short notice, but I have removed the method AndroidAppHelper.getActivityThread_mPackages(): https://github.com/rovo89/XposedBridge/commit/892ba9195da5516dd79f175ac95be2b313c8f8ca
It had been used internally some time ago. I scanned the modules which have been uploaded to the repository and didn't find any which uses this method.
Apart from that, I'm planning to make Xposed for command line tools (e.g. am and pm), implemented via IXposedHookCmdInit/initCmdApp(), optional and disabled by default. It is currently used only by App Settings (but unnecessary and therefore removed in the next version) and NFC LockScreenOff Enabler (I will contact the authors).
As the low usage shows, this feature is hardly needed, so there is no need to load Xposed every time such an app is started. It also avoids the additional log entries, which could be confusing for some users. Actually it is so rarely used that I might not even offer a setting in the UI for it, just a command file for experts. I will not remove it completely as it's useful for low-level framework development (I can quickly test whether my native code changes work without having to reboot).
Xposed 2.6 will bring support for replacing dimensions defined in code (instead of merely forwarding to your own resources): https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
The new API will be published once that version is out. Until then, it would still be possible to make adjustments of the API. If you think anything should be changed, please let me know as soon as possible.
Ok devs, 2.6 beta1 is out, and so is the new API (version 52).
Here are the relevant XposedBridge changes to version 42 (internal changes/optimizations are not listed):
The resources API can be disabled via a debug setting in the UI. If your module implements IXposedHookInitPackageResources, it will not be loaded because it likely depends on this API. You can also check (but don't change) the status via XposedBridge.disableResources if you use the API in other ways.
Hooking abstract methods (including methods declared in interfaces) will throw an IllegalArgumentException now. The callback was never executed for them anyway. This change avoids debugging effort on your side because you will notice it immediately.
It's now possible to create a DimensionReplacement object and use it to replace "dimen" resources with values calculated at runtime. Previously it was only possible to forward such resources to your module. Example in the commit message: https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
Removed AndroidAppHelper.createResourcesKey() methods and AndroidAppHelper.getActivityThread_mPackages() - weren't used by any module in the repository.
Fix delayed configuration update for forwarded resources. That's only of interest if your replacement resource contains variants for different qualifiers that might change at runtime (e.g. drawable-land/drawable-port). https://github.com/rovo89/XposedBridge/commit/1c81954e295cdda191cf8a1cf33d21d7c5ea334d
New findConstructorExact() / findAndHookConstructor() methods, similar to the one for methods: https://github.com/rovo89/XposedBridge/commit/a233fa0bc9499eadbe2efc0b49fc3f4a46264614
IXposedHookCmdInit is deprecated now, initCmdApps() won't be called anymore unless an undocumented file has been created. Only two modules used it, both got rid of it without any loss of functionality. This also averts situations like this where logging for tools like am/pm masks errors for Zygote.
Due to some internal changes, the constructor of XResources isn't called anymore (a good thing!), which breaks some features in App Settings (a not so good thing). That's because it relied on updateConfiguration() being called twice, so it could retrieve the package name in the second call and do its changes. A fix for that is on the way, using a new method (getPackageNameDuringConstruction()) added in the last minute, which returns the package name for a very specific situation. You will probably not need it.
Apart from that, there is now an official way to open a certain section in the installer:
Code:
Intent intent = new Intent("de.robv.android.xposed.installer.OPEN_SECTION");
intent.setPackage("de.robv.android.xposed.installer");
intent.putExtra("section", "modules");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Possible values for "section" are currently: install, modules, download, logs, settings, about.
You can for example use this to send the user to the module section if you find out that your module isn't active yet. The best way to find out is something like that:
Code:
// in your Activity, call it to find out the activation status
private static boolean isModuleActive() {
return false;
}
// in handleLoadPackage()
if (lpparam.packageName.equals("your.package.name")) {
// don't use YourActivity.class here
findAndHookMethod("your.package.name.YourActivity", lpparam.classLoader,
"isModuleActive", XC_MethodReplacement.returnConstant(true));
}
Do NOT try to read - or even change - the internal files of the Xposed Installer to get this information or force your module to be activated. Not only can this break anytime, it will also be bad user experience and a security threat if your module is active without explicit selection in the app. You will probably see your app removed from the repository if you break the rules.
If you have any questions or remarks, please let me know. And if you haven't subscribed to this thread yet, make sure to do so now in order to stay up-to-date with new developments.
IllegalAccessException if you use reflection yourself
One additional change in the new version was the removal of a hack that nuked some access checks in Dalvik by making them return "true" every time. After some of the other internal changes, some of the processing that required this hack was no longer necessary. With some more refactoring, I was finally able get rid of this hack. That's good because it caused crashes on some badly built ROMs (incorrect smali hacks), but also in some rare cases in normal apps: https://github.com/rovo89/XposedInstaller/issues/89
However, some modules relied on the deactivation of these access checks. Now they get IllegalAccessExceptions when trying to access e.g. private fields or methods.
Does this mean that Xposed used to cause security issues on the whole system? After all, it meant that any app could access things that they couldn't access otherwise, right? So it destroyed Java's security system!
The answer is: No, that wasn't a security issue! The Java access check system is actually optional. When you get a field/method/class via reflection, you just need to call setAccessible(true) on it to disable the access check. Example in XPrivacy: https://github.com/M66B/XPrivacy/co...430849f#diff-a350382a0ec1158ad9769d07bd754a63
Note that this is only needed if you use reflection yourself, e.g. with getDeclaredMethod() / getDeclaredField(). The methods in XposedHelpers call setAccessible() on the result before returning it to you.
2.6 final comes with XposedBridge v54.
The only changes relevant for developers are the addition of XSharedPreferences.hasFileChanged() and XSharedPreferences.getFile(), and a fix for replaced animation/xml resources. If you're using the latter and want to avoid that someone with the buggy version 2.6 beta1 runs into issues with your module, consider bumping the minimum required Xposed version to 54.
In Lollipop, there were a few architectural changes in Android. I hinted one of them in the Q&A:
The most significant one is that the code for system services has been moved to a separate file. For most of the affected modules, this can be solved by a little refactoring (moving code to a different place).
Click to expand...
Click to collapse
In detail, this means: If you want to hook a system service like PackageManagerService, you can no longer do that in initZygote(). Instead, move your code to handleLoadPackage() and check for dummy package "android". Make sure you use lpparam.classLoaders when looking for classes and hooking methods. This way has worked in older Android versions as well, so you don't lose backwards-compatiblity.
I'll just repeat here what I wrote in the official announcement thread, as it'll be helpful for all module developers:
rovo89 said:
After a long time with mainly bug fixes, version 81 focuses on improvements for developers:
There is a proper API now. Previously, I basically published the sources of XposedBridge.jar, which included many internal classes/methods that modules shouldn't use. Hiding them makes it easier to find the correct methods to use and also makes it easier for me to change implementation details.
The API is published on Bintray/JCenter, so it's easy to use, especially with Gradle/Android Studio. Full explanations here: https://github.com/rovo89/XposedBridge/wiki/Using-the-Xposed-Framework-API
100% of the API are documented with Javadoc now: http://api.xposed.info/
Apart from that, downloads have moved to http://dl-xda.xposed.info/framework/ and are GPG-signed now. You can verify them against this key (fingerprint: 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333). That's actually the master key, the files are signed with subkey 852109AA.
There are no real changes for end-users in this release, nevertheless I would recommend that at least developers test their modules with it.
Click to expand...
Click to collapse
let me start off by saying that the xposed framework is absolutely awesome but if you've noticed recently just the amount of modules have just gotten a bit unruly I suggest adding some sort of tag system to help organize all the modules
for example some the tags could be device specific modules, type of module, android version etc.
ie. I would disable any tags with sense or touchwiz because I do not on that device and those modules wouldn't work on my device
This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.
rovo89 said:
This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.
Click to expand...
Click to collapse
For the Xposed modules index thread, I'm using 9 categories to separate modules by their function, and additional tags for modules that are specific to an Android version or vendor.
If you find that that makes sense and if you'd like to use it, I can share a CSV file (which is easily usable with Python, which is why I picked it) that should have the necessary info to easily add it to your server's data "automatically" (by writing a hopefully short script) (fields include, among others: tags and package name for each module).
I realize this needs discussion and will take a good amount of time and effort, but I'm just offering the index right now should you want to take a look at it. Also, if you think I/the community can make your life easier by categorizing modules with additional tags, I'm sure many will step up to help.
That is so kind of you! Thats awesome
I will also say that I wasn't very clear. (What it became is way awesome)
I meant only like an automatic way to get ones that won't work with my device to be hidden
My scenario for this was I have an aosp gpe tablet. And when I'm brousing modules I don't want to scroll past 6 experia mods that don't apply to me.
I'm going through all the features of the current version of Android Studio (version 1.0.2) and am frustrated by the documentation. There is existing documentation at JetBrains, but much of it appears to be out of date. I've wasted a fair amount of time trying to follow some sections of documentation only to finally decide that they are simply incorrect; then, of course, I have to work through the system by trial-and-error.
My question is: Is there any comprehensive documentation for the current incarnation of Android Studio? The best I've found so far is the book, "Android Studio Development Essentials" by Neil Smyth. Even that, however, spends far more pages on Android development in general than on the Android Studio too.
As an example, take a look at https://www.jetbrains.com/idea/help/accessing-module-settings.html. The first step is to bring up the Project Structure dialog. That comes up fine, but appears to have been completely redone and the very next step, "click Modules", doesn't appear to be pertinent any longer. Furthermore, the "Modules page" that that should bring you to doesn't seem to exist any more (at least I couldn't find it anywhere). This (i.e., module) information seems to be retained in the app.iml file (the module is called "app"), but I don't see where it can be modified in the GUI.
I have a few questions about Android Studio (given the above), but will post them separately.
Thanks for any pointers .
Barry
-------------
UPDATE:
From IntelliJ Support:
Online documentation is for IDEA, not for Android Studio. Android Studio is a narrow tool for Android development, so it doesn't have all IDEA features.
Android Studio is based on IDEA core code, but it is developed by Google.
Closing this item out. (Although, not to put too fine a point on it, I still don't know where good/accurate/current documentation is for Android Studio (Google?).)
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