Related
Hi all,
If you are going to say we don't need Apps2SD on the N1, please leave the thread now . (Actually, read on) There are various reasons I can think of why we need Apps2SD on the N1, and one of the biggest is actually Games. I don't really play any games to begin with, but the last I checked, some games are as large as 19MB, possibly more. Isn't it kind of crappy that the N1, the superphone, can't hold more than 10 such games?
I started this thread with the intention of gathering more information, and hopefully some coders will do it (including myself, if I've the time). Package Manager (the thing in charge of installing, if I'm not wrong), is in the AOSP, under frameworks/base. In such a case, wouldn't it be possible for some programmer to mod it such that it will ask you whether to install to (SD/Phone) before each installation process?
The other issue is, looking at current implementation of A2SD, it seems all apps on Phone are moved to the SD card partition. If we can have an implementation that allows both to co-exist, in addition to the Package Manager mod, I'd say we'll have a pretty nice implementation.
Your thoughts/findings? I may be completely off, have yet to actually look at the AOSP source.
Update:
@ChrisSoyars has an early implementation of this in his SnackPack - http://forum.xda-developers.com/showthread.php?t=638301
I would also like to thank everyone else for their valuable input and support ! Keep them coming. Lastly, sorry I'm not doing much code-wise (not at all), school work's too much .
Would be nice!
....I've got the same problem. Some application are very big and so i have got only 10MB free space anymore...
ADB is god
See my attachment file
And...there is already a post about app2SD and this is not in the correct section...
lazinase said:
See my attachment file
And...there is already a post about app2SD and this is not in the correct section...
Click to expand...
Click to collapse
that doesnt work on roms like the desire by modaco. app2sd doesnt work, ive tried that method and it just hangs. true there is a thread already for app2sd, but its not going anywhere in terms of the newest desire release. i know its still early, but i only had like 50mb for apps and i have over 120 apps and i didnt feel like reinstalling. someone fix it please.
Apps to SD is of course necessary. The Nexus doesn't really have that much space for apps - about 190mb which is only the same as the Hero.
I have apps 2 SD working with CM 5.0.3 from the kitchen.
its also addable to a CM rom using the how to thread.
It WAS working ok with MoDaCo ROMS but for some reason has ceased to work and causes bootloops if you bake it in - shame...
I've no coding experience, but willing to test stuff out anytime.....
Dayz xx
i think what Wysie is trying to do is stimulate discussion about a different way to do A2SD.
He, and a lot of people believe (including myself) that running apps from the sd makes them slower, so what he wants is like WM where when you install an app it gives you an option to install it either onthe device or on the sd. So you can choose to install your most used and apps that require speed the most on your device...
And if this isnt thread development where the hell should he have posted it? It certainly is development if you ask me. he is thinking of ways to develop a better A2SD.
Seems like unionfs + some kind of app to manage which apps live where might work. This would require kernel support, however. You would set up /data/app and /data/app-private as union mounts of (say) /data/app-internal with /sdcard/app and /data/app-private-internal with /sdcard/app-private. You would then want a custom app management tool to move things to the appropriate places.
Nice initative Wysie.
My suggestions are as follows:
Use a different mount point, not inside any of the other file systems.
Like /apps2sd, this makes it alot easier to handle in the recovery realm (which is what I care about).
As for handling the specific apps installed in either /data/app or /apps2sd I suggest we have a look at something simple. Like symlinking individual apps.
Ext filesystem is mounted on /apps2sd on boot.
New installs of apps are done in /data/app like normally. /data/app is not symlinked to the apps2sd directory like it is today.
If a user want a app to be stored on apps2sd instead of in /data/app a management app can just move the .apk from /data/app to /apps2sd and set up a symlink it up into /data/app again.
Simple demonstration:
Initial state, two apps installed normally:
/data/app:
SomeApp.apk
SomeOtherApp.apk
/apps2sd
<empty>
Now the user moves SomeApp to apps2sd:
/data/app
SomeApp.apk -> /apps2sd/SomeApp.apk (symlink)
SomeOtherApp.apk
/apps2sd
SomeApp.apk
If this is possible, i.e. making sure that Android doesn't bork on symlinked apps (can't see why it would, but best to make sure). This is clean simple way handle it. It gives more control on what apps are stored where, better handling of ext stuff in recovery.
Also writing scripts/apps to facilitate this is trivial since it's so simple.
What do you think? Want input especially from ROM makers.
packetlss said:
As for handling the specific apps installed in either /data/app or /apps2sd I suggest we have a look at something simple. Like symlinking individual apps.
Click to expand...
Click to collapse
Okay, that's better than my idea, assuming it works. One disadvantage is that removing the SD card breaks all the links. You could conceivably swap cards with the unionfs approach, as long as you were not using any widgets or launcher icons which rely on APKs in the SD storage, and had a way to properly unmount the disk. Might not be worth the complexity, though.
I think the biggest issue is with regards to removal of SD card. You guys have made it way more complex than I thought, thanks for enlightening/sharing !
I thought it could be as simple as simply modifying the Apps2SD script to allow apps to exist on both the sdcard and the phone, and then modifying the Package Manager to prompt the user on where to install to. Keep those thoughts/opinions coming!
If it wasn't for my school work and lousy time management i'd definitely start doing something. For now, it's good enough if all the necessary knowledge is shared here, then some dev can actually start work and put it on github or something for the rest of the community to contribute!
i haven't looked deeply into android's files. but i've worked on hacking motorola phones to engineer a packet manager system. (EZX phones)
i believe the solution that we want isn't with the use of symlink or that sort. we should aim to find a clean, programmatic way of doing it - built to the heart of android.
any idea how android am manage the apps on the phone? is there an sqlite app db or something? how does it store the installed applications information?
arctu said:
i haven't looked deeply into android's files. but i've worked on hacking motorola phones to engineer a packet manager system. (EZX phones)
i believe the solution that we want isn't with the use of symlink or that sort. we should aim to find a clean, programmatic way of doing it - built to the heart of android.
any idea how android am manage the apps on the phone? is there an sqlite app db or something? how does it store the installed applications information?
Click to expand...
Click to collapse
Well, you have to remember that the solution should work on stuff that we do not have source access to, like people wanting to use on ported ROMs or a rooted stock ROM.
I tried to simlink apk's but for some reason it didn't work, simlink the app directory works.
I think the best way would be to add paths in the program that actually searches/launches the apps (my guess would be that's in framework.jar)
Currently it looks in /system/app, /data/app & /data/app-private there should not be any technical reason why it couldn't look in a forth directory. this way you can keep the imporant/most used apps in the flash and large/less used on the sdcard...
rj3005 said:
I think the best way would be to add paths in the program that actually searches/launches the apps (my guess would be that's in framework.jar)
Currently it looks in /system/app, /data/app & /data/app-private there should not be any technical reason why it couldn't look in a forth directory. this way you can keep the imporant/most used apps in the flash and large/less used on the sdcard...
Click to expand...
Click to collapse
packetlss said:
Well, you have to remember that the solution should work on stuff that we do not have source access to, like people wanting to use on ported ROMs or a rooted stock ROM.
Click to expand...
Click to collapse
Again, this is the problem. A general technique suitable for XDA-type applications must require only root or changes to GPL code. You can't touch the framework, which can (and does) have proprietary branches.
packetlss said:
Well, you have to remember that the solution should work on stuff that we do not have source access to, like people wanting to use on ported ROMs or a rooted stock ROM.
Click to expand...
Click to collapse
i would say that we have no choice but to implement it without considering those groups. however, i do suggest that we should make the implementation compatible, just that, on modded frameworks like cyan, it works to the fullest.
olearyp said:
unionfs
Click to expand...
Click to collapse
Everything old is new again. Oh well.
olearyp said:
Everything old is new again. Oh well.
Click to expand...
Click to collapse
Unionfs is not available for android devices without kernel sources.
Concerning ported rom, I am not sure the package installer get modified by vendors. So it may be possible to implement the changes done to aosp code using baksmali.
So my two cents are:
- modify AOSP sources to have android lookup at /sd/app for apps
- modify package installer to have it asks where to install apps
Sure the removing of sdcard problem is still there. I don't know how we can ever handle a straight manual remove of it. It implies big modifications to AOSP sources to have the system aware of missing applications that have existing home shortcuts or widgets, so it "hides" them until app is back...
Anyway we can start implementing the functionality and look after for that sdcard removal problem.
I've been thinking of doing this for a while, has any progress been made?
I like the idea of modifying pm to prompt for the install location, I was thinking of just writing an app to manage that (but probably would be a good idea to have both).
If progress has been made, great, if not, I may start a fork of CM5's vendor tree for this.
Lox_Dev said:
Unionfs is not available for android devices without kernel sources.
Click to expand...
Click to collapse
Kernel sources are the one thing you most assuredly do have on all devices, at least if they're sold where copyright law can be enforced. No one needs to risk a lawsuit by intentionally violating GPL.
olearyp said:
Kernel sources are the one thing you most assuredly do have on all devices, at least if they're sold where copyright law can be enforced. No one needs to risk a lawsuit by intentionally violating GPL.
Click to expand...
Click to collapse
Well.. it is not the case in real life.... For eg, acer Liquid kernel sources they acer provided is unusable.
Just a clue for aosp source modification:
services/java/com/android/server/PackageManagerService.java:frameworks/base/ Log.d(TAG, "Scanning app dir " + dir
[FIX][XPOSED][4.0+] Universal fix for the several "Master Key" vulnerabilities
You may be aware of recent news about several different security vulnerabilities that allow replacing code on a signed APK without invalidating the signature:
Master Key (Bug 8219321)
An issue related with duplicate entries on the ZIP / APK files.
It was patched by Google back in February 2013 and shared with OEMs, and some of the newer devices might have already received the fix in a recent stock update. At least both Xperia Z 4.2.2 and Galaxy S2 4.1.2 contain the fix; CM has also recently patched it, on this commit.
More info can be found on @Adam77Root's thread here: http://forum.xda-developers.com/showthread.php?t=2359943
Bug 9695860
This also originates in the ZIP file parsing routines, and was disclosed just a few days ago immediately after the previous one was made public. The correction has already been applied by Google to the code (this commit), but it's very likely that its rollout on stock ROMs will take a long time especially on non-Nexus devices.
You can read more about it here.
To know if you're vulnerable, use SRT AppScanner mentioned above.
Unless you're running CM 10.1.2, there's a fairly big chance that you have this issue, at least as of this moment.
Bug 9950697
It's yet another inconsistency in ZIP parsing that could be abused in very a similar way to the previous one.
This one is a bit special to me, since I was fortunate enough to be the first one to report it on Google's bugtracker
It was discovered around the time that the previous bug was acknowledged and Android 4.3 was a few days from being released, but despite the prompt report it was unfortunately too late to include the fix in time for the release; Therefore it wasn't disclosed till Android 4.4 sources came out and I had also decided not including a fix for in on this module, since it would be an easy way to learn about the extra attack vector.
Kudos to Jeff Forristal at Bluebox Security, who I learned was also working on that exact problem and helped me report it properly to Google, and also to Saurik who already released a Substrate-based fix and has written a very interesting article about it here.
Checking if you're vulnerable
You can use some 3rd party apps to test your system, such as:
- SRT AppScanner
- Bluebox Security Scanner
On Android 4.4 all these bugs should be fixed, and therefore this mod is not needed. But you can run one of these scanners to make sure you're not vulnerable.
While technically different, these vulnerabilities permit that legitimate APKs can be manipulated to replace the original code with arbitrary one without breaking the signature. This allows someone to take an update from a well known publisher (e.g. Google Maps), change the APK, and a device receiving it will happily apply the update as if it was indeed from that publisher. Depending on the apps being updated in this way, priviledge escalation can be achieved.
Google has already mentioned that all apps published on the Play Store are checked for this kind of manipulation, but those of us installing APKs from other sources aren't safe.
The universal fix
Since decompiling, fixing and recompiling the code for every possible ROM version is way beyond anyone's capability, the awesome Xposed framework by @rovo89 proves itself once again as an invaluable tool.
By creating hooks around the vulnerable methods and replacing the buggy implementation with a safe one, it's possible to patch the 2 issues on the fly without ever changing the original files. Applying the fix is as easy as installing and enabling an Xposed module.
Installation steps
1. Make sure the Xposed Framework is installed.
Follow the instructions on the thread. Root is required only during installation, it is no longer required afterwards. Only ICS or above is supported.
2. Install the Master Key multi-fix module.
3. Follow the Xposed notification about a new module being available, and on the list of modules activate Master Key multi-fix
4. Reboot
You should now see an image similar to the attached one when opening the app. The green text shows that the module is active and the vulnerabilities have been patched in memory.
Download
Grab it from Google Play (recommended, as you'll get updates) or use the attached APK. The files are the same.
Version history
2.0 - Fix bug 9950697; additional corrections taken from Android 4.4 (also supports GB, provided you have a working version of Xposed Framework for your ROM)
1.3 - Fixed problems with parsing some zips depending on the rom original code
1.2 - Added 2 additional zip entry integrity checks that were missing
1.1 - Support for additional devices with modified core libraries (e.g. MTK6589)
1.0 - Initial version
Sources
Available on GitHub
If you appreciated this fix, consider donating with Paypal.
Thanks!
FAQ
Fequently asked questions
[ 1 ]
Q: Bluebox Security Scanner still says my phone is unpatched after installing this... Any ideas why?
A: Make sure to click the Refresh entry on the app's menu and it should change to green once the mod is active.
[ 2 ]
Q: Bluebox Security Scanner says that the 2nd bug is not patched even after refreshing but SRT AppScanner says it's patched. Which one is right?
A: The scanner was mis-detecting the 2nd bug and it got fixed in version 1.5. Make sure you update Bluebox from the Play store.
[ 3 ]
Q: Does the module permanently patch the vulnerability or is it only when the module is active? If for example, I activate the module and reboot, then after verifying that the exploit is patched, deactivate the module. Would I still be patched? I guess what I'm asking is if I need to have this module active at all times to be patched? Permanent fix, or Just while the module is installed?
A: The fix is not permanent. It's applied only whenever the module is installed and active. If you remove it, after the next boot you're back with the original code from your ROM (which might have the bug or not).
Thank you, this would help a lot
Sent from my GT-I9500 using Tapatalk 4 Beta
Thank you but I don't see any link to the xposed patch app
Envoyé depuis mon LT28h en utilisant Tapatalk 4 Beta
Marsou77 said:
Thank you but I don't see any link to the xposed patch app
Click to expand...
Click to collapse
Have a look now
I needed to create the thread first in order to include the link on the app itself.
Thanks! I was just googling to see if someone had already done this before writing it myself!
XPosed is amazing sauce for Android.
The 4.1.2 update for the T-Mobile galaxy s3 is already patched.
Thanks for the info OP.
Maxamillion said:
The 4.1.2 update for the T-Mobile galaxy s3 is already patched.
Thanks for the info OP.
Click to expand...
Click to collapse
The second bug as well? Check java.util.zip.ZipEntry on /system/framework/core.jar and see if the readShort() values are properly converted to unsigned.
.....
Bluebox security still says my phone is unpatched after installing this... Any ideas why?
Sent from my HTC Sensation Z710e using xda app-developers app
Shredz98 said:
Bluebox security still says my phone is unpatched after installing this... Any ideas why?
Click to expand...
Click to collapse
No idea why it doesn't refresh automatically each time you execute the app, but access the Refresh option from the menu and it should change to green once the mod is active.
Tungstwenty said:
No idea why it doesn't refresh automatically each time you execute the app, but access the Refresh option from the menu and it should change to green once the mod is active.
Click to expand...
Click to collapse
Yeah you're correct mate, says patched when I rescanned so all good the patch does exactly what it says, brilliant work! Was beginning to think I would have to live with this security hole active on my device!
Sent from my HTC Sensation Z710e using xda app-developers app
Shredz98 said:
Yeah you're correct mate, says patched when I rescanned so all good the patch does exactly what it says, brilliant work! Was beginning to think I would have to live with this security hole active on my device!
Click to expand...
Click to collapse
Added to the FAQ (post #2)
Hey Everyone,
I've found an alternative for the blueboox app. It's called the SRT AppScanner and seems to work better than the BlueBox Scanner and it provides more functionality, too.
Since I'am a new user, i can't post links. Simply query SRT AppScanner in the PlayStore.
Best regards
Boradin
Thanks for great patch.
I've tested with SRT AppScanner and found I'm still vulnerable to bug 9695860.
How do I make sure bug 9695860 was fixed?
mnirun said:
Thanks for great patch.
I've tested with SRT AppScanner and found I'm still vulnerable to bug 9695860.
How do I make sure bug 9695860 was fixed?
Click to expand...
Click to collapse
When I initially installed SRT it was always giving me 2 greens even with the mod disabled, even though I checked the code for my ROM and the 2nd bug is there.
Now, after a very recent update, it always gives me a red on the second bug even with the mod active. I'll need to double check how they are doing the detection because it doesn't seem to be correct.
Bluebox Security, on the other hand, does reflect the change although it only detects the first bug. Running it on an emulator with a vulnerable ROM correctly said so, and after applying the mod and forcing a rescan it will change to no longer vulnerable.
SRT AppScanner has just received an additional update from Play and now appears to correctly detect the status of bug 9695860 depending on whether the mod is active or not and if your base ROM is vulnerable.
The sources are now available on GitHub (check 1st post).
Tungstwenty said:
SRT AppScanner has just received an additional update from Play and now appears to correctly detect the status of bug 9695860 depending on whether the mod is active or not and if your base ROM is vulnerable.
Click to expand...
Click to collapse
Confirmed, you patch is now detected by SRT AppScanner.
Thank you.
Tungstwenty said:
You may be aware of recent news about 2 different security vulnerabilities that allow replacing code on a signed APK without invalidating the signature:
Master Key (Bug 8219321)
An issue related with duplicate entries on the ZIP / APK files.
It was patched by Google back in February 2013 and shared with OEMs, and some of the newer devices might have already received the fix in a recent stock update. At least both Xperia Z 4.2.2 and Galaxy S2 4.1.2 contain the fix; CM has also recently patched it, on this commit.
An easy way to know if you're vulnerable is installing this app by Bluebox Security. Update: An ever better one is SRT AppScanner, which can detect both bugs.
More info can be found on @Adam77Root's thread here: http://forum.xda-developers.com/showthread.php?t=2359943
Bug 9695860
This also originates in the ZIP file parsing routines, and was disclosed just a few days ago immediately after the previous one was made public. The correction has already been applied by Google to the code (this commit), but it's very likely that its rollout on stock ROMs will take a long time especially on non-Nexus devices.
You can read more about it here.
To know if you're vulnerable, use SRT AppScanner mentioned above.
Unless you're running CM 10.1.2, there's a fairly big chance that you have this issue, at least as of this moment.
While technically different, both of these vulnerabilities permit that legitimate APKs can be manipulated to replace the original code with arbitrary one without breaking the signature. This allows someone to take an update from a well known publisher (e.g. Google Maps), change the APK, and a device receiving it will happily apply the update as if it was indeed from that publisher. Depending on the apps being updated in this way, priviledge escalation can be achieved.
Google has already mentioned that all apps published on the Play Store are checked for this kind of manipulation, but those of us installing APKs from other sources aren't safe.
The universal patch
Since decompiling, fixing and recompiling the code for every possible ROM version is way beyond anyone's capability, the awesome Xposed framework by @rovo89 proves itself once again as an invaluable tool.
By creating hooks around the vulnerable methods and replacing the buggy implementation with a safe one, it's possible to patch the 2 issues on the fly without ever changing the original files. Applying the fix is as easy as installing and enabling an Xposed module.
Installation steps
1. Make sure the Xposed Framework is installed.
Follow the instructions on the thread. Root is required only during installation, it is no longer required afterwards. Only ICS or above is supported.
2. Install the Master Key dual fix module.
3. Follow the Xposed notification about a new module being available, and on the list of modules activate Master Key dual fix
4. Reboot the device (a Soft reboot is sufficient)
You should now see an image similar to the attached one. The green text shows that the module is active and the 2 vulnerabilities have been patched.
Download
Grab it from Google Play or use the attached APK.
Sources
Available on GitHub
If you appreciated this fix, consider donating with Paypal.
Thanks!
Click to expand...
Click to collapse
Thank you for this patch, but can we install this mod over "REKEY" patch or remove rekey and enable this patch instead ??
Hi, I am the author of VirtualXposed: https://forum.xda-developers.com/xposed/virtualxposed-xposed-root-unlock-t3760313
VirtualXposed can run some Xposed modules on Non-Root devices without needing to unlock the bootloader or flash any sysytem images, but it can not act on system processes.
After a lot of exploration and experiment, I found a better way to run (Xposed) modules. It can run on both root and non-root devices, and it support Android 5.0 ~ 10.0 I release the beta version in China at 2019/1/5, after many tests and improvements, it is stable enough now to introduce it for you.
The app, or framework is named TaiChi
## Introduction
TaiChi is a framework to use Xposed module with or without Root/Unlock bootloader, it support Android 5.0 ~ 9.0.
In simple words, TaiChi is Xposed-Styled Framework, it can load Xposed modules, do hooks and so on.
## Feature
TaiChi is Xposed-Styled, but it has no relation with Xposed. The only relevance is that TaiChi can load Xposed modules, the implementation of TaiChi and Xposed Framework is very different.
Here are some features of Taichi:
1. TaiChi has fully supports for Android Pie.
2. TaiChi can run in non-root mode.
3. TaiChi does not effect the android system and it does not hook all apps in system. Only the apps you want to apply Xposed modules are hooked. Other apps in system run in a completely clean environment, which means TaiChi can pass SafeNet easily.
4. TaiChi doesn't need to reboot system in most cases
5. TaiChi is hard to detect. TaiChi doesn't modify the libart and app_process, it has nearly no noticeable characteristics.
## Usage
TaiChi has two work mode: magisk mode and non-root mode. If you don't want to unlock the bootloader/flash system images, you can use the non-root mode, if you prefer more powerful functions, just try magisk mode.
### What is the different with magisk mode and non-root mode?
The only difference is that magisk mode can hook system process, so more modules are supported, such as Xposed Edge/Greenify.But magisk mode need to unlock the bootloader and install Magisk, while non-root mode just needs to install a simple app.
### Non-Root mode
TaiChi run in non-root mode in genernal, just install a simple app, all the installation is over. If you want to use Xposed modules, for example, you'd like to use SnapFreedom on SnapChat, follow these steps:
1. Click the float button in Home page of TaiChi, and then click the button : **Create App**.
2. Select the app you'd like to apply Xposed modules, such as SnapChat.
3. Click the "Create" button at the bottom and then wait the creation to finish pariently.
4. When creation finished, TaiChi tells you that you need to unstall the original SnapChat, please uninstall it, this is necessary. Because TaiChi in non-root mode needs to modify the APK file which means we have to re-sign the APK.
5. Follow the steps in TaiChi app until you installed the new app.
6. Enter the **Module Manage** activity by click the button "Module Manager" of the float button in Home page.
7. Check the SnapFreedom module.
8. Kill the process of SnapChat and the Xposed modules should work properly.(You don't need to reboot system)
### Magisk mode
Non-root mode of TaiChi has some shortcomming even though it do not need to unlock bootloader, so i develop a magisk module, this module can give TaiChi extra power to overcome these shortcommings:
1. magisk mode can hook into system process.
2. magisk mode don't need to modify the apk, and the signature keeps same.
When you flashed the [magisk module]https://github.com/tiann/TaiChi-Magisk provided by TaiChi, TaiChi app switch to magisk mode automaticly: TaiChi App + magisk module = TaiChi·Magisk. When the magisk module is disabled or removed, TaiChi app turn to non-root mode.
If you want to use magisk mode, please read the [wiki](https://github.com/tiann/Tai-Chi/wiki/taichi-magisk-beta) carefully.
## For Developers
TaiChi is a Framework, developers can wrote modules to do hooks. The TaiChi modules is fully compatible to Xposed modules, so just wrote the Xposed-Styled modules and it can run well in TaiChi, too.
But there are still some difference from TaiChi Framework and Xposed Framework, please refer [For Xposed Developers]https://github.com/tiann/Tai-Chi/wiki/For-Xposed-developer
## Discuss
- [Telegram Group](https://t.me/vxp_group)
## Contact me
(mailto:[email protected])
[B]## Other [/B]
1. TaiChi is closed-source now, it may be open-sourced in the future, but not now.
2. TaiChi can not run Xposed modules arbitrarily(it supports it in technical-speaking), it can only run specific version and specific modules now. If you want to use other modules, please fire an issue. Here is the support list: https://taichi.cool/module/module.html
3. TaiChi is compatible to Xposed modules, but it may have its own module in the future.
[B][U][SIZE="4"][PLAIN]XDAevDB Information[/PLAIN][/SIZE][/U][/B]
[SIZE=3][B]TaiChi, Xposed for all devices (see above for details)[/B][/SIZE]
[B][U]Contributors[/U][/B]
[URL="https://forum.xda-developers.com/member.php?u=8994560"]weishu[/URL], [URL="https://forum.xda-developers.com/member.php?u=8994560"]weishu[/URL]
[B]Source Code:[/B] [URL="https://github.com/taichi-framework"]https://github.com/taichi-framework[/URL]
[B]Xposed Package Name:[/B]
[B][U]Version Information[/U][/B]
[B]Status:[/B] Stable
[B]Created[/B] 2019-03-11
[B]Last Updated[/B] 2019-03-16
I noticed the magisk module today on the repo. Sounds very promising and... tempting to me.
But, regardless of how much I'd love to finally have xposed modules on pie, there's one major deal-breaker here: Closed source.
TaiChi magisk (as well as xposed) are extremely mighty - which makes it mandatory for us to see and confirm what's happening behind the curtains.
As soon as it gets open source, I'll be back and support this project.
Sent from my OnePlus 6 using XDA Labs
weishu said:
TaiChi run in non-root mode in genernal, just install a simple app, all the installation is over. If you want to use Xposed modules, for example, you'd like to use SnapFreedom on SnapChat, follow these steps:
1. Click the float button in Home page of TaiChi, and then click the button : **Create App**.
2. Select the app you'd like to apply Xposed modules, such as SnapChat.
3. Click the "Create" button at the bottom and then wait the creation to finish pariently.
4. When creation finished, TaiChi tells you that you need to unstall the original SnapChat, please uninstall it, this is necessary. Because TaiChi in non-root mode needs to modify the APK file which means we have to re-sign the APK.
5. Follow the steps in TaiChi app until you installed the new app.
6. Enter the **Module Manage** activity by click the button "Module Manager" of the float button in Home page.
7. Check the SnapFreedom module.
8. Kill the process of SnapChat and the Xposed modules should work properly.(You don't need to reboot system)
Click to expand...
Click to collapse
Thanks for this great module, its nice to know there is hope for our locked bootloader devices.
I want to use snapfreedom, but the above steps wont actually work, snapchat will refuse to log me in since the signature of the apk has changed and its been uninstalled so my data is gone. Without root access I can't figure a way to copy my user data over to remain logged in. Any ideas would be greatly appreciated!
flamery said:
Thanks for this great module, its nice to know there is hope for our locked bootloader devices.
I want to use snapfreedom, but the above steps wont actually work, snapchat will refuse to log me in since the signature of the apk has changed and its been uninstalled so my data is gone. Without root access I can't figure a way to copy my user data over to remain logged in. Any ideas would be greatly appreciated!
Click to expand...
Click to collapse
The SnapChat itself refused you to login or other app can not login by Snapchat?
In fact, TaiChi non-root mode cheats the signature of app, if it cannot cheats SnapChat, i will look into it.
Depressed T.Bear said:
I noticed the magisk module today on the repo. Sounds very promising and... tempting to me.
But, regardless of how much I'd love to finally have xposed modules on pie, there's one major deal-breaker here: Closed source.
TaiChi magisk (as well as xposed) are extremely mighty - which makes it mandatory for us to see and confirm what's happening behind the curtains.
As soon as it gets open source, I'll be back and support this project.
Sent from my OnePlus 6 using XDA Labs
Click to expand...
Click to collapse
In fact, I’ve been tangled for a long time whether to open source the TaiChi.
Whether it's TaiChi or Xposed-Framework, they are so powerful that it's hard to believe its security if it's not open source. But there are some reasons for me to not open source it now:
1. TaiChi is a framework, it gives the same power to modules, modules can do all that TaiChi can do. In magisk-mode, TaiChi can control your device completely(Although I didn't do that), so dose the modules. If TaiChi is open-source but some modules don't, it is not secure too. You can choose to use only open-source modules, but others may not. There are so many excellent modules are closed-source, such as Greenify, Xposed Edge, Snapchat, etc. Only open source TaiChi is far from security if some module developer are malicious.
2. Open source doesn't mean security. VirtualXposed is open-source: https://github.com/android-hacker/VirtualXposed . But if you read the XDA Thread of it: https://forum.xda-developers.com/xpo...nlock-t3760313 . There are still so many users thinks it is not safe to use
Depressed T.Bear said:
I noticed the magisk module today on the repo. Sounds very promising and... tempting to me.
But, regardless of how much I'd love to finally have xposed modules on pie, there's one major deal-breaker here: Closed source.
TaiChi magisk (as well as xposed) are extremely mighty - which makes it mandatory for us to see and confirm what's happening behind the curtains.
As soon as it gets open source, I'll be back and support this project.
Sent from my OnePlus 6 using XDA Labs
Click to expand...
Click to collapse
In fact, I’ve been tangled for a long time whether to open source the TaiChi.
Whether it's TaiChi or Xposed-Framework, they are so powerful that it's hard to believe its security if it's not open source. But there are some reasons for me to not open source it now:
1. TaiChi is a framework, it gives the same power to modules, modules can do all that TaiChi can do. In magisk-mode, TaiChi can control your device completely(Although I didn't do that), so dose the modules. If TaiChi is open-source but some modules don't, it is not secure too. You can choose to use only open-source modules, but others may not. There are so many excellent modules are closed-source, such as Greenify, Xposed Edge, Snapchat, etc. Only open source TaiChi is far from security if some module developer are malicious.
2. Open source doesn't mean security. VirtualXposed is open-source: https://github.com/android-hacker/VirtualXposed . But if you read the XDA Thread of it: https://forum.xda-developers.com/xpo...nlock-t3760313 . There are still so many users thinks it is not safe to use.
Depressed T.Bear said:
I noticed the magisk module today on the repo. Sounds very promising and... tempting to me.
But, regardless of how much I'd love to finally have xposed modules on pie, there's one major deal-breaker here: Closed source.
TaiChi magisk (as well as xposed) are extremely mighty - which makes it mandatory for us to see and confirm what's happening behind the curtains.
As soon as it gets open source, I'll be back and support this project.
Sent from my OnePlus 6 using XDA Labs
Click to expand...
Click to collapse
In fact, I’ve been tangled for a long time whether to open source the TaiChi.
Whether it's TaiChi or Xposed-Framework, they are so powerful that it's hard to believe its security if it's not open source. But there are some reasons for me to not open source it now:
1. TaiChi is a framework, it gives the same power to modules, modules can do all that TaiChi can do. In magisk-mode, TaiChi can control your device completely(Although I didn't do that), so dose the modules. If TaiChi is open-source but some modules don't, it is not secure too. You can choose to use only open-source modules, but others may not. There are so many excellent modules are closed-source, such as Greenify, Xposed Edge, Snapchat, etc. Only open source TaiChi is far from security if some module developer are malicious.
2. Open source doesn't mean security. VirtualXposed is open-source: https://github.com/android-hacker/VirtualXposed . But if you read the XDA Thread of it: https://forum.xda-developers.com/xpo...nlock-t3760313 . There are still so many users thinks it is not safe to use. When it is closed-source, users think it is insecure becuase it is not open-source, when you open source it, users think it is insecure becuase no one to review the huge and ****-source code.
3. Xposed-Framework is not open-source after Android O, too. (correct me if i am wrong)
4. Closed-source can provide security for normal users. Closed source means that TaiChi can restrict the ****ing and harmful modules run in TaiChi(it won't load unknown modules). And also, The module developer won't worry about crack( it won't load the re-signed modules).
Happy to hear from all your advices.
weishu said:
In fact, I’ve been tangled for a long time whether to open source the TaiChi.
Whether it's TaiChi or Xposed-Framework, they are so powerful that it's hard to believe its security if it's not open source. But there are some reasons for me to not open source it now:
1. TaiChi is a framework, it gives the same power to modules, modules can do all that TaiChi can do. In magisk-mode, TaiChi can control your device completely(Although I didn't do that), so dose the modules. If TaiChi is open-source but some modules don't, it is not secure too. You can choose to use only open-source modules, but others may not. There are so many excellent modules are closed-source, such as Greenify, Xposed Edge, Snapchat, etc. Only open source TaiChi is far from security if some module developer are malicious.
2. Open source doesn't mean security. VirtualXposed is open-source: https://github.com/android-hacker/VirtualXposed . But if you read the XDA Thread of it: https://forum.xda-developers.com/xpo...nlock-t3760313 . There are still so many users thinks it is not safe to use
Click to expand...
Click to collapse
I think it is a pretty weak reasoning to not make the framework open source because the modules are closed source.
Both open and closed source do not mean security, so this is not a real argument either.
So, it lets me just wondering what the real reason is to not open source.
weishu said:
The SnapChat itself refused you to login or other app can not login by Snapchat?
In fact, TaiChi non-root mode cheats the signature of app, if it cannot cheats SnapChat, i will look into it.
Click to expand...
Click to collapse
Its the login to snapchat, they have very high security around 3rd party apps and app modding. If the apk has been modified you get the "login has temporarily failed" message when trying to login.
The workaround in the past has been to login with xposed disabled, titanium backup data, flash xposed, then restore data so you remain logged in. But there is no way to achieve that without root that I can see! thanks for looking into it!
so how do i enable the Magisk module?
Just tried Taichi today and it instantly bring the good old days for me with Xposed. I need to have certain Apps to run in different locale and Xposed module is to the only way to get this done! However Xposed also stopped Google pay so I have to stop using Xposed ever since.
With Taichi I can start use Xposed again and have Google Pay at the same time... Great solution!
Unfortunately with current international politics it immediately mark anything from China as insecure. I am not sure if TaiChi is secure or not, but I guess since the day I rooted my phone I am assuming all the risk inherited.
Anyway good work! Weishu! (Just donated)
Hmm I must be high on something because I dont see the download link.
woomera said:
Hmm I must be high on something because I dont see the download link.
Click to expand...
Click to collapse
Check the magisk manager downloads section.
@weishu , I hope you can help. I've purchased xprivacylua pro from the google play store some time ago and reinstalled it on Pie. Xprivacylua pro does not seem to recognize xprivacylua is installed also. Do you have any suggestions?
dirtyreturn said:
@weishu , I hope you can help. I've purchased xprivacylua pro from the google play store some time ago and reinstalled it on Pie. Xprivacylua pro does not seem to recognize xprivacylua is installed also. Do you have any suggestions?
Click to expand...
Click to collapse
It sounds like you misunderstood something. The "Pro" app from. Google Play is just a companion app, which enables the pro features you bought. It doesn't contain the actual xposed module (and app) of xprivacy Lua.
Simply download it through the xposed repo or get the latest apk directly from the xprivacy lua website.
Sent from my OnePlus 6 using XDA Labs
Depressed T.Bear said:
It sounds like you misunderstood something. The "Pro" app from. Google Play is just a companion app, which enables the pro features you bought. It doesn't contain the actual xposed module (and app) of xprivacy Lua.
Simply download it through the xposed repo or get the latest apk directly from the xprivacy lua website.
Click to expand...
Click to collapse
Thanks for the reply. I just assumed by my post it would make sense.
I do have the taichi magisk module installed, and from there I've installed xprivacylua. And from the google play store the pro companion app. @Depressed T.Bear - are you using xprivacylua on Pie? Does the pro app recognize the main app as installed for you?
Depressed T.Bear said:
It sounds like you misunderstood something. The "Pro" app from. Google Play is just a companion app, which enables the pro features you bought. It doesn't contain the actual xposed module (and app) of xprivacy Lua.
Simply download it through the xposed repo or get the latest apk directly from the xprivacy lua website.
Click to expand...
Click to collapse
Please see screenshots.
dirtyreturn said:
Thanks for the reply. I just assumed by my post it would make sense.
I do have the taichi magisk module installed, and from there I've installed xprivacylua. And from the google play store the pro companion app. @Depressed T.Bear - are you using xprivacylua on Pie? Does the pro app recognize the main app as installed for you?
Click to expand...
Click to collapse
Then it might be due to TaiChi.
Yes, I'm using XPrivacyLua on Pie - but with EdExposed and not with TaiChi. For one simple reason: TaiChi is not open source! EdExposed and RiruCore instead are.
So it would be absolute nonsense to use an app like XPrivacyLua to protect your privacy, while using a xposed version with is closed-source and nobody can tell what it actually does.
So, I can't help you with TaiChi. Only the developer can.
All I can say is that it works flawlessly with EdExposed.
Sent from my OnePlus 6 using XDA Labs
I have edxposed but I'm thinking of trying Taichi out to see if it's more stable. Will this work with modules such as xposed edge where the module doesnt target a specific app?
Soumy1234 said:
I have edxposed but I'm thinking of trying Taichi out to see if it's more stable. Will this work with modules such as xposed edge where the module doesnt target a specific app?
Click to expand...
Click to collapse
Your question is answered clearly in the first post
Sent from my OnePlus 6 using XDA Labs
I am trying to gradually stripe AOSP out of its default apps. But I wonder if the method I am going to apply is correct and is the most effective.
After looking through ways of doing that I have come to the following method: (example app - "package_name")
1. Pick particular app and find out its "LOCAL_PACKAGE_NAME"
2. Use "envsetup.sh" provided command "mgrep package_name"
3. Look at the output to determine where package_name is mentioned
4. Remove lines of code containing package_name from makefiles
Click to expand...
Click to collapse
I have also stumbled upon this solution:
Instead of modifying bunch of .mk files in AOSP in many folders, you can add a new module, a stub, and disable modules in its Android.mk using LOCAL_OVERRIDES_PACKAGES. If a module still appear in target, you'll probably need to add to LOCAL_OVERRIDES_PACKAGES another modules which added undesired packages via LOCAL_REQUIRED_MODULES.
Click to expand...
Click to collapse
But sadly I am not aware yet how one builds a new "module, a stub" so I can't apply this method as of now.
Are there any steps I can take to make sure a particular app is removed from my build completely without harming anything. What do you think is the most elegant solution to this specific task if there is one? What(literature/docs/website)would be useful for me to get familiar with making "scratch-surface" changes to AOSP code like the abovementioned case?
Thanks in advance for your responses!
P.S If any extra information is needed I am ready to specify
If that matters what I am trying to remove at the moment: Calculator; Calendar; Camera; Clock; Contacts; Files; Gallery; Messaging; Music; Phone; Search; WebView
MAGISK Module which does this job:
I found a magisk module which does the same work explained in this thread.
Module Link: Download here
SOURCE:
Github Download link: HERE
Gitgub source code link: HERE
< ALTERNATIVELY IF YOU WANT TO DO IT YOURSELF, FOLLOW THE STEPS BELOW >
Pre-Requites:
a. Device rooted with magisk 19.4+
b. Teminal Emulator installed (Link)
b. SQL database editor is installed (Link)
Steps:
1. Force close Google Pay app (just in case). If you have disabled this app, enable it before continue and force close)
2. Open SQL editor and go to File explorer in the app. Navigate to /data/data/com.google.android.gms/databases
3. Open dg.db and go to main
4. You will see entries "attest" (not "ad_attest"), long press and select Edit and change value under C (which is 3rd column) to 0. Mine was showing a value of 10 in the third column for each of these values. (Column c for sqlite database editor I used)
5. Open Terminal emulator.
6. Get root access (su) (i.e type su and ENTER)
7. Now type cd /data/data/com.google.android.gms/databases and ENTER
8. Type chmod 440 dg.db ENTER. This makes dg.db read only so that it will not over written and you can continue to use Google Pay.
9. Reboot your device and enjoy Google Pay.
Note: When gms is updated, you have to change chmod value for dg.db via terminal emulator (i.e type chmod 660 dg.db) to get write permission. Now follow all the steps to change value to 0 and change chmod to 440
Thanks to @BostonDan for the thread https://forum.xda-developers.com/apps/magisk/magisk-google-pay-gms-17-1-22-pie-t3929950
Nice Man... First method that actually worked for me. I am on Android 10 Xiaomi.eu latest
Serbinhio said:
Nice Man... First method that actually worked for me. I am on Android 10 Xiaomi.eu latest
Click to expand...
Click to collapse
Hi
Glad to hear that it worked for you. I changed my phone from OP5 to this device and GPay was not working until modded as explained in OP. It is very handy that I don't have to carry my wallet all the time.
You only need to do step 8, the rest isn't required.
nahsha said:
You only need to do step 8, the rest isn't required.
Click to expand...
Click to collapse
I have never tested with attest value being 10.
Do you mean, with attest value 10 and change to write permission of dg.db to 440 makes Gpay to work?
If this is the case, I agree that only step 8 is enough.
Thanks.
Its working, thanks
Congrats
Good job man. Works well with MIUI Global 11.0.3.0 (QFAMIXM) and latest Android 10.
Thanks
I flashed MIUI 11 Beta version (xiaomi.eu version) weekly update v9.12.5. I can see that CTS profile and basic integrity passes. Also, I can see that Device certified in Google Play settings. But GPay was reporting that device is rooted hence GPay could not work.
I went through following attempts to make it work.
Attempt 1:
Flashed magisk module Safety Patcher. GPay didn't work.
Attempt 2:
Removed Safety Patcher and flashed MagiskHide Props config modules. Used certified fingerprint for xiaomi mi9. GPay didn't work.
Attempt 3:
Removed all magisk modules mentioned above. Went through the method mentioned in this thread. GPay is working now.
Though this thread is made by me, I was lazy enough to go through the steps and that's why wanted to use something readily made like Safety Patcher or MagiskHide Props config).
Hope this update helps.
Working great on latest stable Miui.eu.
Thanks!.
It works great on latest Revolution OS.
Thank You!
Instead of:
a) Uploading a single release of my module to androidfilehost (which will mean anyone using that will likely never know theres an update)
b) Link to my actual releases page, but to a specific release (which will mean anyone using that will likely never know theres an update)
c) Incorrectly linking a source link to the releases page (the source is available as a zip option alongside the module zip for every release)
d) Omitting that the module relies on an sqlite3 binary being present on the device BEFORE installing the GPay SQL Fix module (not sure if your device by default has an sqlite3 binary, in any event in my OP for my module in BostonDan's thread i offer one universal SQLite package to test for this and if necessary, install one)
e) Omitting a link to my OP in BostanDan's thread so people can see the correct install procedure (it matters), keep up to date with important info, warnings, changelogs, and things such as extra steps necessary of using say edXposed....
I would suggest (In other words, your linking is bad, and youre only passing on part of the story in referencing my module):
1) A link to my OP in BostanDans thread:
https://forum.xda-developers.com/showpost.php?p=79643248&postcount=176
2) A link the releases page for my module (it will always link to the latest release this way)
GPay SQLite Fix:
release: https://github.com/stylemessiah/GPay-SQLite-Fix/releases/latest
3) A link to the SQLite3 binary module
SQLite3 Universal Binaries v1.0 (installs to /system/xbin if exists, otherwise .system/bin) here:
release: https://github.com/stylemessiah/SQLite3-Universal-Binaries/releases/latest
4) Remove the source link, its unnecessary
Cheers
73sydney said:
Instead of:
a) Uploading a single release of my module to androidfilehost (which will mean anyone using that will likely never know theres an update)
b) Link to my actual releases page, but to a specific release (which will mean anyone using that will likely never know theres an update)
c) Incorrectly linking a source link to the releases page (the source is available as a zip option alongside the module zip for every release)
d) Omitting that the module relies on an sqlite3 binary being present on the device BEFORE installing the GPay SQL Fix module (not sure if your device by default has an sqlite3 binary, in any event in my OP for my module in BostonDan's thread i offer one universal SQLite package to test for this and if necessary, install one)
e) Omitting a link to my OP in BostanDan's thread so people can see the correct install procedure (it matters), keep up to date with important info, warnings, changelogs, and things such as extra steps necessary of using say edXposed....
I would suggest (In other words, your linking is bad, and youre only passing on part of the story in referencing my module):
1) A link to my OP in BostanDans thread:
https://forum.xda-developers.com/showpost.php?p=79643248&postcount=176
2) A link the releases page for my module (it will always link to the latest release this way)
GPay SQLite Fix:
release: https://github.com/stylemessiah/GPay-SQLite-Fix/releases/latest
3) A link to the SQLite3 binary module
SQLite3 Universal Binaries v1.0 (installs to /system/xbin if exists, otherwise .system/bin) here:
release: https://github.com/stylemessiah/SQLite3-Universal-Binaries/releases/latest
4) Remove the source link, its unnecessary
Cheers
Click to expand...
Click to collapse
Have been using this module for months and I can't thank you enough to make GPay work with such an automated method.
Quick suggestion - why don't you start a new post with your work instead of letting it hide in reply #176 of another thread? You can always include a link back to the original post to give credit.
Cheers ! Thanks again !!!
seemebreakthis said:
Have been using this module for months and I can't thank you enough to make GPay work with such an automated method.
Quick suggestion - why don't you start a new post with your work instead of letting it hide in reply #176 of another thread? You can always include a link back to the original post to give credit.
Cheers ! Thanks again !!!
Click to expand...
Click to collapse
I didnt invent the method, i just repackaged it to make it a little easier for those who wanted to try it...
So i didnt move it into its own thread because i felt it might be disrespectful to BostanDan, i just repackaged his and others work, seemed only right to at least keep it where it started.
At least you didnt ask why its not in the repo, i get tired of telling THAT story
Wow, stumbled on this thread and was struggling to get GPay succesfully activated using all other tricks mentioned online. This one does actually work!
Yove just made my day, thank you!