Apps2SD All in one tool[2.3+]: Partition SD card and Move/Link Apps to SD card [ROOT]
- Thread starter vickybonick
- Start date
I would say no, you dont need to. Unless the linked apps disappear or are gone after reboot, then you should flag it.
In my sdcard i ' ve 2 partition. 1 for the applications linked and 1 for data.
With Your help now the Partition with applications work and is visible by android system, while the second is not visible by android. If i open file manager of twrp, it see the partition with the data, files, everýthing. But if i start phone normally the partition of data is invisible, like it Was not inserted
With Your help now the Partition with applications work and is visible by android system, while the second is not visible by android. If i open file manager of twrp, it see the partition with the data, files, everýthing. But if i start phone normally the partition of data is invisible, like it Was not inserted
Maybe the 1st partition is what you have your apps linked to, and the 2nd is where your data is. In that case, stock Android ROMs wouldnt be able to access the data partition.
Go to Play Store, install Aparted. Open it and take a screenshot.
I think there is a problem in the script.
My phone has 64gb of intern memory.
Have AN sdcard of 256gb partitioned in one partition of 56gb for applications and one of 200 for data.
But if i look in android, it Was like intern memory of 28gb.
I can' t install anything and i can't make screenshot, because it says there isn't enough space
My phone has 64gb of intern memory.
Have AN sdcard of 256gb partitioned in one partition of 56gb for applications and one of 200 for data.
But if i look in android, it Was like intern memory of 28gb.
I can' t install anything and i can't make screenshot, because it says there isn't enough space
Attachments
You may need to reflash your firmware or do a factory reset to fix this. But first, we need to see if your SD card is partitioned correctly.
Your data partition should be the 1st partition, and partition for linking should be 2nd. If they are in reverse order, stock Android firmwares wont be able to access the 1st partition.
Your data partition should be the 1st partition, and partition for linking should be 2nd. If they are in reverse order, stock Android firmwares wont be able to access the 1st partition.
So you are out of space even without the SD card? If that's the case, then only a firmware/ROM reflash or factory data reset will fix it.
There isn't any solution
Attachments
Last edited:
Great app. It continues to work even now after its last update in 2018. It's sad that it's discontinued.
I have some issues, likely due to android system change over the years. App cache is now located in the app's internal data folder, so linking data will also link cache, but linking cache will reduce performance heavily. I think it's possible to work around this by moving cache elsewhere in /data, then move and link only the internal data (without cache) to sdcard, then link the moved cache to that moved data. So cache will still be in internal memory, linked to data folder in sdcard, then linked back to internal memory inside data folder. The 2nd partition might have to be ext fs, idk.
Does the author have or plan to have the source available publicly, maybe in github?
Edit:
This is achievable "manually" with folder mount option. I linked data to sdext, then I "manually" mounted the cache folder in sdext to a folder I created in /data. I tried this for Facebook app but it turns out it's just as slow as having both data and cache in sdext. I've tried both with Symlink and with Bind, but they're equally bad. It took ages for the app to load. I guess Facebook is heavy on the data folder.
I have some issues, likely due to android system change over the years. App cache is now located in the app's internal data folder, so linking data will also link cache, but linking cache will reduce performance heavily. I think it's possible to work around this by moving cache elsewhere in /data, then move and link only the internal data (without cache) to sdcard, then link the moved cache to that moved data. So cache will still be in internal memory, linked to data folder in sdcard, then linked back to internal memory inside data folder. The 2nd partition might have to be ext fs, idk.
Does the author have or plan to have the source available publicly, maybe in github?
Edit:
This is achievable "manually" with folder mount option. I linked data to sdext, then I "manually" mounted the cache folder in sdext to a folder I created in /data. I tried this for Facebook app but it turns out it's just as slow as having both data and cache in sdext. I've tried both with Symlink and with Bind, but they're equally bad. It took ages for the app to load. I guess Facebook is heavy on the data folder.
Last edited:
Hi,
Can we increase the partition size of SDcard(1st Partition) and reduce the size of sdext2(2nd Partition) without formatting using pc app "Disk Management Tool"? The way we can shrink and expand the pc drive size without formatting, In the same way, Can we change the size of SDcard partition too?
Can we increase the partition size of SDcard(1st Partition) and reduce the size of sdext2(2nd Partition) without formatting using pc app "Disk Management Tool"? The way we can shrink and expand the pc drive size without formatting, In the same way, Can we change the size of SDcard partition too?
Last edited:
@YK RAJ: The "SDcard" partition is first, and sdext2 is 2nd. So, assuming your MicroSD is formatted this way (and it should be this way, due to how stock Android firmwares only natively mounts the 1st primary partition that has a compatible filesystem), then you will need to delete 2nd partition, increase size of 1st partition, then recreate 2nd partition as something being smaller than what it is now.
If you currently have apps linked to sdext2, you should unlink or uninstall them before proceeding.
You can do this in Windows with something like MiniTool free edition. Or in Linux, it has numerous partitioning programs. You can also do it on the phone with Apps2SD or AParted (although I think Apps2SD's inbuilt partitioner isn't so flexible, and will force you to format the entire card). I personally recommend AParted for this, just be careful not to delete what you wish to keep.
If you currently have apps linked to sdext2, you should unlink or uninstall them before proceeding.
You can do this in Windows with something like MiniTool free edition. Or in Linux, it has numerous partitioning programs. You can also do it on the phone with Apps2SD or AParted (although I think Apps2SD's inbuilt partitioner isn't so flexible, and will force you to format the entire card). I personally recommend AParted for this, just be careful not to delete what you wish to keep.
I just upgraded my Samsung tab to Android 12, and decided to test Apps2SD again. Unfortunately my results are the same as before. You can link an app's internal data just fine, linked apps continue working. However, linking obb files to 2nd partition fails. I can link them to the SD's 1st partition, Apps2SD claims linking is successful. But when I check the /Android/obb/ folder on SD, nothing has been moved, and the respective app fails to launch normally.
In short, for Android 11/12, you shouldn't trust Apps2SD to link anything in /sdcard/Android/data or /sdcard/Android/obb, due to the Scoped Storage restrictions. The locations listed above may also/or be located at /storage/emulated/0 on some firmwares. However, linking an app's internal data (located in the data partition, not including internal/external storage) seems to be safe. It's a long shot that Apps2SD will ever be updated, but we can hope.
Most Apps2SD users will be rooted with Magisk these days, so be sure to use /data/adb/service.d for the mount script location (configure it in Apps2SD settings before creating mount script). Also, it's best to not let Apps2SD modify system partition. Using the advanced mount option will likely result in a failure to create the script, or an inability to boot.
Here are some alternatives you can try to address these shortcomings:
XInternalSD:
Requires EdXposed or LSPosed
Can't link internal data
Can select which apps it should be enabled/disabled for
Doesn't require 2nd partition on SD
Obb On SD:
Requires EdXposed or LSPosed
Can't link internal data
Can't select which apps to enable it for
The app will claim it's not enabled in Xposed, you can just ignore this by tapping outside the dialog, it will still work
Doesn't require 2nd partition on SD
Fbind:
Requires Magisk/root
Can't link internal data
Requires usage of a terminal emulator app, it has no GUI
Doesn't require 2nd partition on SD
Not all of these will work with all apps, try more than one if you have issues.
Even with these issues, I think that Apps2SD still remains somewhat useful, but not as much as it was before on older Android versions. If you're willing to root your phone and try EdXposed/LSPosed, you will find that these limitations are tolerable.
An alternative for non rooted users would be adoptable storage.
In short, for Android 11/12, you shouldn't trust Apps2SD to link anything in /sdcard/Android/data or /sdcard/Android/obb, due to the Scoped Storage restrictions. The locations listed above may also/or be located at /storage/emulated/0 on some firmwares. However, linking an app's internal data (located in the data partition, not including internal/external storage) seems to be safe. It's a long shot that Apps2SD will ever be updated, but we can hope.
Most Apps2SD users will be rooted with Magisk these days, so be sure to use /data/adb/service.d for the mount script location (configure it in Apps2SD settings before creating mount script). Also, it's best to not let Apps2SD modify system partition. Using the advanced mount option will likely result in a failure to create the script, or an inability to boot.
Here are some alternatives you can try to address these shortcomings:
XInternalSD:
Requires EdXposed or LSPosed
Can't link internal data
Can select which apps it should be enabled/disabled for
Doesn't require 2nd partition on SD
Obb On SD:
Requires EdXposed or LSPosed
Can't link internal data
Can't select which apps to enable it for
The app will claim it's not enabled in Xposed, you can just ignore this by tapping outside the dialog, it will still work
Doesn't require 2nd partition on SD
Fbind:
Requires Magisk/root
Can't link internal data
Requires usage of a terminal emulator app, it has no GUI
Doesn't require 2nd partition on SD
Not all of these will work with all apps, try more than one if you have issues.
Even with these issues, I think that Apps2SD still remains somewhat useful, but not as much as it was before on older Android versions. If you're willing to root your phone and try EdXposed/LSPosed, you will find that these limitations are tolerable.
An alternative for non rooted users would be adoptable storage.
Last edited:
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
1
Yes, I have, and it's nowhere near as powerful as Apps2SD. AppMgr III is better for not rooted, Apps2SD is better for rooted.1
I meant linking the internal data (located in the userdata partition of the device). To my knowledge fbind can't do that. But even if it's possible to bind mount an entire user, it's not something I would recommend doing. Too much opportunity for weird bugs, crashes, etc to occur. I don't know that much about fbind beyond using it to link some stuff from internal storage to external storage. So if you have questions about it, I'd ask in that thread. @VR25 also has Telegram chat channels you can join.1
Su.d was originally a function of SuperSU. But it's basically nothing more than a function of auto running scripts on boot. Init.d has been able to do that for a long time, and Magisk also. I'm using /data/adb/service.d. if you're using Apps2SD on Android 11/12 in particular, I would also enable the setting to not let the app modify system partition. Too much chance of a bootloop/inability to boot on newer Android versions. It happened to me once on 11, I had to go through a somewhat complicated process to undo Apps2SD's changes and get back into Android. Setting the su.d path works fine though, since it doesn't modify Android's system files.1
Can't advise much with adoptable storage and issues relates to linking/binding with it. I tried it once a few months ago and lost over 150GB of files that can't be recovered. Much of it wasn't critical, but some was. Still reeling a bit recovering from that. As a result, I won't use AS again unless I'm confronted with a scenario where there are no other viable options.
Oh, and since your using AS, you don't really need Apps2SD. The main point of this app is that it lets you link internal data and bind internal/external storage stuff. AS keeps entire apps and their internal data on the SD, including things like obb files. And your SD essentially becomes considered by Android as your device's internal storage. AS cancels out most of the point of using Apps2SD.
And if you have anything important stored on your device while AS is enabled, I very highly recommend backing that stuff up to a PC, the cloud, whatever. Anywhere besides the device itself. That would have saved my bacon had I been more careful. But I was overly confident and not knowledgeable enough about AS to get my stuff off it if/when it fails. Lesson learned, moving on. If you ever find that your adopted SD is no longer accessible, you will regret if you don't have a backup somewhere. If you're rooted or have TWRP, I would make a copy of the encryption keyfile in /data/misc/vold and keep it somewhere safe. It may help you recover your data when something bad happens, as long as the AS partitions on the SD remain intact. Although it wasnt much help for me since those partitions had been accidently destroyed.1
Get rid of adoptable storage while you can, go back to what Android calls "portable storage".Sorry to hear about your data loss due to messing with AS. I know how that feels.
Thanks for your explanation of how AS works. Already having read many pros and cons about it, I'm still lamenting if how AS works is really what I want. Esp. because of the way migrating works - that I can't choose what is getting migrated but am forced to migrate everything. I initially had thought AS would only merge the SD card into Internal Storage, and not also move /data/apps and data/data hidden in the background. Esp. since hardly and app works if run from AS anyway and I had to enable a switch to install and keep apps on internal. I think much rather I'd prefer to have all apps and data on internal by default, and continue to choose willingly via XinternalSD and root Symlinks what exactly to move to SD card.
Re. backups: very good points - here's how I've been doing it:
- backup via TWRP -> images to PC
- phone booted into Android & connected to PC: manual copies of Internal and SD-card's folders/files -> PC
- with SD formatted as AS: SD-card via adapter into PC then 1:1 RAW clone saved as compressed image
The path to folder with the encryption keyfile in /data/misc/vold is great to know - I just backed the entire folder up
Unfortunately LOS won't let you move apps to SD if you're not using AS. This is where Apps2SD etc come into play. I think pretty much all LOS/AOSP/CM based ROMs are like that these days. If it's a stock OEM ROM, you may or may not be able to move apps to SD without AS. Samsung is famous for not supporting AS in most of their firmwares, while still allowing apps to be moved to SD.
Deeper explanation of AS:
Android formats your SD, creates AS partitions, and encrypts them. If you choose not to migrate your data, the SD is still considered separate from internal storage. But once you choose to merge, your SD becomes the internal storage that you would normally have access to (usually at /sdcard/ or /storage/emulated/<User#Here>). Another part of the AS SD partition is designated for app storage, but the files there can't be accessed directly without root. Also, once merged, your internal storage becomes effectively managed/owned by Android. I don't recommend AS for devices that have more than 128GB internal storage, for the reason that you're kind of forfeiting control to at least a part of that storage. A selling point of AS is that it gives you more space for apps and data without having to manage seemingly separate internal/external storages. It just makes everything look like it's all in one place. If your device has a lot of space, AS isn't so useful.
As for whether apps are stored on the real internal storage (in the the data partition), or on the fake AS internal storage (on SD), that's also managed by Android. You can still manually choose to move certain apps back and forth as you wish.
In short, Android takes control of your data partition and allocates a certain portion to you via AS, all the while making it look like your AS SD is internal when it's not. The finer details are managed invisibly in the background. AS is designed to be user friendly ("for dummies"), but I'm a geek and prefer a higher level of control. I feel that AS is less suitable for that than regular portable storage.
As far as the encryption benefits, it also has a slight performance hit. Apps ran from the AS SD will never run as fast as they would if they were located on the "real" (data partition) internal storage. By choosing to move an app to SD, you're selecting the AS SD, and moving to internal puts it back on the real internal storage. But anyway, back to encryption....any attacker with access to that golden key file (via root or TWRP, since there's no other feasible way to get at it without elevated rights) will just be able to unlock your AS SD and they have everything. They can even plug the SD into a PC running Linux, and use the key file to unlock and mount the partitions.
I think Android encryption mechanisms are highly overrated, and they have been demonstrated to have numerous security flaws that makes it easy for an attacker to bypass and have your data. I never store truly critical files on my phone (the ones I wouldn't want anyone seeing), just the stuff I wouldn't care if they got to. As an alternative, you could individually encrypt your important files with (preferably open source) software. Or you could store them in encrypted container files like what EDS (app) can create. Then you would still have the benefit of encryption, and it would be more fine grained, instead of having the entire data partition/AS SD encrypted. Even if an attacker got to these files, they wouldn't be able to use them without either knowing the password, or cracking it via brute force.
I find that encryption methods/softwares on PC are much more reliable and secure than Android's encryption mechanisms. I'm actually very much pro-encryption and use it alot. But I don't like the ways that Android implements it. On PC, most of my partitions are encrypted, except those that shouldn't be for various reasons.
It looks like you already have a good backup plan, not much to say there. So you already know that AS cant be normally accessed on PC without using Android as a go-between. It's also smart that you cloning the entire SD in raw mode. That way it doesn't matter if it's encrypted or not. I'm assuming you're aware of command line tools like dd that can copy in raw mode. A downside of raw mode copying is that it can take a long time to backup/restore.
So, to end this post:
1. Continue using AS just as you are now
2. Continue using AS, but use it in "mixed mode" instead. By default AS will format the entire SD. With mixed mode you can create a 1st portable partition that is clear/plaintext. And another that AS will use for app/fake internal storage. This setup is almost the same as AS in regular/non mixed mode, but it gives you an extra partition that isn't encrypted. You can use the unencrypted partition for regular file storage, while letting AS use the other partition for apps. And of course the AS partition will also have its' fake internal storage you can use for storage too. A downside of this is that you might encounter the issue of only being able to access the portable partition in TWRP, while not having access to the AS storage. Or at least, that's what happened when I tried mixed mode on my older phone. For more info Google "adoptable storage mixed lidicott". You will find a blog post detailing how to create AS partitions in mixed mode.
3. Go back to regular portable storage. For this I'd recommend a 1st partition that is either formatted as exFAT (if you need to store files larger than 4GB, or if the partition will be bigger than 32GB) or FAT32 (less ideal). For the 2nd partition, it should ideally either be formatted as ext4 or f2fs (so that Apps2SD can use it for linking). Now you have the flexibility of app linking, while using fbind and XInternalSD to the fullest when necessary.
Another word about encryption: Physical access is king. If an attacker can physically access your devices, they have already done much of the effort required to get at your files. Never leave your device unattended, never let it out of your sight, never let anyone use it if you don't know them very well. And if you're not using it for an extended period, turn it off if feasible. I'm extremely paranoid in regards to who gets to access my device, I oftentimes won't even let my girlfriend use certain devices. Or if I do, I give access to a clean, sanitized "safe area" where nothing important is stored and they have extremely limited abilities in terms of what they can access. Or I will designate a certain device as "for use by others", unencrypted and with nothing important on it. These days an attacker with high level access can just access the powered on device, dump the contents of your RAM while the encrypted partitions are mounted. Then they take the RAM dump and analyze it for encryption passwords, keyfiles, or anything else that the encrypted partition may have temp-stored in RAM. An attacker can also do a so called "cold boot" attack. In this scenario they get accessible to the device shortly after it's powered off. They then have a time limited window (usually less than 5 minutes) in which to access the RAM and dump a copy. RAM still retains its' contents for a short time after power off before being fully flushed. Obviously these methods won't work everywhere, there are different types of encryption. And none of this will stop an attacker if they can establish remote access to your device while it's on. -
165Hi all,
This is my first post in XDA but I've been a regular reader as a guest. I've developed an app(Apps2SD) to move/link apps from internal storage to external SD card with lots of other cool features.
Apps2SD has evolved from being an app which moves app data to sd card to an all in one app with many cool features.
Translation project http://os3pxnq.oneskyapp.com/collaboration/project/54276
Apps2SD Translation Thread
Tutorials @ https://www.youtube.com/watch?v=-4q5HAHJblI&index=1&list=PLiRFJHKSKUX_q0hsN0oHn4iXGoloJku5s
Prerequisites:
- Device needs to be rooted
- Root permission should be granted to Apps2SD
- 2 partitions on external SD card (use Apps2SD partition tool to create 2nd partition). 1st partition should be FAT/exFat partition, this is your standard SD card storage. The second partition is used as the internal storage for linked application files and can be ext2, ext3, ext4 or f2fs.
12Version 12.2 released in play store and attached in OP
Changelog:
- Updated translations
- Fixed Partial link issue on app install/update
- Fixed obb/ext data linking issue
- Added sd card support for Swap files
- Added option to disable Apps2SD service
- Added option to delete broken symlinks
- Added revert SDFix option
- Added full magisk support
- Added custom su.d path support
- Added display size in Folder mount
- Added background copy/move in Folder mount [Pro]
- Added search option in App analyzer [Pro]
- Added link type sort
- Other bug fixes and performance improvements
11Version 12.0 released in play store and attached in OP
Changelog:
- Added App analyzer to create Folder mount pairs [Pro]
- Added option to create hibernate shortcut [Pro]
- Added app selection in restore apps [Pro]
- Added option to link apps above a certain size [Pro]
- Fixed SDFix for Marshmallow and Nougat
- Performance improvement upto 10 times in creating backup and restore
- Fixed many partition tool issues
- Fixed bug in Hide apps
- Fixed app crash in LineageOS
- Added confirmation before moving files in Folder mount
- Added support for Magisk interface
- Improved mount script
- Added wake lock option
- Fixed bug in broken app cleaner
- Made sdcard path dynamic in Folder mount
- Many other bug fixes and erformance improvements
11First of all I'd like to thank all of you for the continuous support you've given me. After evaluating all the Pros and Cons I have decided not to continue development and support for the the app. I know many of you will be disappointed but trust me it was a very tough decision for me. I have spent countless hours on research, development and testing the app and I'll always be proud of it.
PS: I'll be releasing the final build for free version (with pro features) tonight on play store, hopefully they don't suspend the free version as well.
Update: The apk is updated in play store and attached in the first post
