In the past week or so I've been working on getting all useful filesystems (EXT4, NTFS, exFAT) to work on OTG drives natively with stock Pie on Pixel 2 XL. After a lot of headaches (mostly with SELinux stuff) I've been successful.
I want to preface it saying that this is mostly thanks to null4n's work on the Oreo Magisk vold-posix module, as I started off from there: https://github.com/null4n/vold-posix .
What you need:
- a slightly customized version of Magisk. This is required because the userland daemon which handles mounting filesystems on Android only supports exFAT/FAT32 and is started before Magisk processes its modules, as it has to do /data decryption. The modded magisk replaces vold (using an init.rc script addition made by null4n) with a modified one systemlessly before it starts. It also injects a custom split sepolicy file to make everything play nice with SELinux, taking advantage of the fact our devices have the possibility of generating a sepolicy from split .cil files (basically text files). Both vold and the custom .cil are hidden by MagiskHide.
- mkfs/fsck binaries for NTFS and exFAT, plus a mount binary for NTFS (plus libraries), built from LineageOS sources. These are provided as a magisk module.
- a kernel including an exFAT driver. I used Samsung's sdFAT (used in their recent devices with a 4.4 kernel) from this repo: https://github.com/cryptomilk/kernel-sdfat and compiled it in SultanXDA's kernel.
How to install:
Install "Sultan-kernel-wahoo_20181212-exFAT.zip" and "Magisk-v18.0-extrafs.zip" from recovery. Put "fsbinaries.zip" on the internal SD card and install it by going to Magisk Manager -> Modules.
Download:
View attachment Magisk-v18.1-extrafs.zip
View attachment Sultan-kernel-wahoo_20190113.zip-exFAT.zip
View attachment fsbinaries.zip
Source code:
https://github.com/AuroraWright/vold
https://github.com/AuroraWright/Magisk
https://github.com/LineageOS/android_external_ntfs-3g
https://github.com/LineageOS/android_external_exfat
https://github.com/kerneltoast/android_kernel_google_wahoo
View attachment sultanexfat.7z
Does it work for pixel 3 ?
The modded magisk build and fs binaries should (they won't give you ExFAT support on their own, for that you should compile sdFAT into your Pixel 3 kernel of choice)
Just curious as to why you would want this and what would it be for?
djcrystals said:
Just curious as to why you would want this and what would it be for?
Click to expand...
Click to collapse
I have my external HDD formatted to NTFS because I use both macOS and Windows, so it's useful for that personally. FAT32 is the only natively supported filesystem for USB storage on the pixel, and while it might be enough to occasionally transfer files with, FAT32 isn't really reliable for any storage that's more permanent (due to the lack of a journal etc). Plus it doesn't support files over 4 GB if you need to transfer one of those for some reason.
Phoenix Wright said:
I have my external HDD formatted to NTFS because I use both macOS and Windows, so it's useful for that personally. FAT32 is the only natively supported filesystem for USB storage on the pixel, and while it might be enough to occasionally transfer files with, FAT32 isn't really reliable for any storage that's more permanent (due to the lack of a journal etc). Plus it doesn't support files over 4 GB if you need to transfer one of those for some reason.
Click to expand...
Click to collapse
Gotcha ?
Thank you
Phoenix Wright said:
I have my external HDD formatted to NTFS because I use both macOS and Windows, so it's useful for that personally. FAT32 is the only natively supported filesystem for USB storage on the pixel, and while it might be enough to occasionally transfer files with, FAT32 isn't really reliable for any storage that's more permanent (due to the lack of a journal etc). Plus it doesn't support files over 4 GB if you need to transfer one of those for some reason.
Click to expand...
Click to collapse
1. will this break in non-stock Pie?
2. if my hard drive is already in exFat, and I don't care about NTFS, do I still need this mod?
thank you
iu1nguoi said:
1. will this break in non-stock Pie?
2. if my hard drive is already in exFat, and I don't care about NTFS, do I still need this mod?
thank you
Click to expand...
Click to collapse
1) no idea, it is possible. however most custom roms would already have this feature built-in I believe, so no need for this.
2) assuming the rom you use is like stock, you'd at least need the custom kernel and the fs binaries. The custom magisk (and custom vold within it) are only required for ntfs/ext4 support
Also, I updated the kernel (which has the February security patches from Google as a bonus) and the magisk build
Thank you!
Just wanted to show my appreciation of this mod. Got it running no problems and it works seamlessly.
I find it incredibly irritating that Pixel devices support no other format than FAT32. It seems pretty unacceptable to me. I can maybe see that exFAT/NTFS support would be tricky with Microsoft (others have managed, so I doubt that is actually the reason) but ext4? Come on!
Anyway, this MOD works around the problem.
Thanks Phoenix!
Is there any chance of getting an update for this? It's just that this version of Magisk breaks Google Pay, and I believe from 19 that is fixed.
Thanks!
This modo is only google pixel? Other divice is compatible?
Are the patched/modified versions of the kernel and Magisk supposed to be flashed IN PLACE of the originals? Or over the top? And does this functionality persist if we update Magisk or the kernel or apply a monthly security patch?
Thanks!
Phoenix Wright said:
The modded magisk build and fs binaries should (they won't give you ExFAT support on their own, for that you should compile sdFAT into your Pixel 3 kernel of choice)
Click to expand...
Click to collapse
This module is super great ,but the modify magisk it offered is based magisk V18. Can u share the newest magisk package?
Thx
Updated Magisk & fs-binaries Installers
MAGISK 20.4 LATEST STABLE (MMT-EX)
Ziona said:
Updated Magisk & fs-binaries Installers
MAGISK 20.4 LATEST STABLE (MMT-EX)
Click to expand...
Click to collapse
Does there happen to be a way to use this without having a custom kernel? Trying to use this on an Android 10 GSI, but it makes no difference.
veekay said:
Does there happen to be a way to use this without having a custom kernel? Trying to use this on an Android 10 GSI, but it makes no difference.
Click to expand...
Click to collapse
Trying to get exfat or ntfs support
Exfat.
veekay said:
Exfat.
Click to expand...
Click to collapse
Check this out
https://forum.xda-developers.com/android/general/mods-external-sdcard-linker-write-t4078731
It bricked my device!!!
Now I'm unable to access my Internal Storage. Phone is booting but File Explorers show blank. How do I fix it??? Can't even browse or anything. I lost my magisk also. I had flashed my stock recovery after installing magisk now I'm unable to do anything with the phone which will require me to access the internal memory
Ziona said:
Updated Magisk & fs-binaries Installers
MAGISK 20.4 LATEST STABLE (MMT-EX)
Click to expand...
Click to collapse
Can you update them for magisk 23?
Related
On the back of my previous hybrid root effort, I now have an even easier root solution!
Benefits of using this...
- auto A2SD pulled from Cyanogen's ROM (muchos kudos to him...) - just create your partition (I use EXT3) and you're done!
- much easier install process than before!
- root access (with 'adb remount' permissions for full access)
- superuser APK
- busybox is installed and configured, meaning you can use apps that use things such as 'swapon' (e.g. swapper)
- /data/init.sh is called at startup so you can create your own startup commands
- if you're a bit mad (like me) you can set the system partition to always mount RW using init.sh, to save adb remount'ing all the time (this is dangerous potentially ofc!)
- MORE TO COME - gimme your requests!
[caveat: i'm pretty new to Android tweaking, so use at your own risk!]
Details and download:
http://android.modaco.com/content/h...1-1-modaco-hero-patch-root-busybox-much-more/
Changelog
1.4
- Fixed WiFI issues (tested on fresh built Hero)
- USB debugging is now enabled by default
1.3
- A2SD from Cyanogen's latest ROM (full credit to Cyanogen!)
1.2
- Performance fix
1.1
- Initial Release
Well,
First off all, thank you for putting your effort in this. I really appriciate youre work sofar.
Nick
Brill - I would like to have a go, but worried that I'll be messed up cos already rooted (XDA Method) and also applied your Update from your rooting method to get adb remount (ta!!)
Can I just apply the update zip with no problems from those other rootings?
Hugs Dayzee
Other rootings have no impact, so it's cool.
Checking out a reported WiFi issue atm however...
P
no wifi problem here, no problem with previously rooted too
busybox works fine, trying ap2sd soon
stupid question.. how do i use ap2sd now
i applied update.zip once again
any help on the appstosd ????
We need to download the application, or is it built in to transfer all apps to the sd card?? Do we need to format the card with fat32 and ext2??
No probs with my install. Not done anything with it mind you, but no probs been thrown up as a result of doing it and wifi working fine. xxx
Dayzz
Why does the wifi work for some and not for other? Maybe thoose with a root already gets a working wifi and thoose without root before applying this gets a not functioning wifi...
wifi doesnt work for me... i really need it to work.. so im reverting back until it gets fixed..
I had already rooted using method here, then updated using this method and no wifi, restored nandroid backup and wifi back again.
I have the white sim free model, not sure if that makes any differance.
Also was rooted with the 1.2 method, then gave the 1.3 a try and no wifi... Anyone figure out how to get the apps to sd working???
@atsavlis what phone do you have? sim free or locked?
modaco said:
Other rootings have no impact, so it's cool.
Checking out a reported WiFi issue atm however...
P
Click to expand...
Click to collapse
Wifi doesn't work because the wlan.ko module of the people who are having problems is compiled for a different kernel version.
To solve the wifi issue, just include your(or the one of the same build of your boot.img) wlan.ko module in the "update".
You can find it in /system/lib/modules/
enlightener said:
Wifi doesn't work because the wlan.ko module of the people who are having problems is compiled for a different kernel version.
To solve the wifi issue, just include your(or the one of the same build of your boot.img) wlan.ko module in the "update".
You can find it in /system/lib/modules/
Click to expand...
Click to collapse
Not right actually... as the original kernel is being used.
Investigating now, I probably screwed up something in the init.rc in the boot image
P
For A2SD, as with other ROMs, just ensure you have a second partition on your SD card that is EXT3, and the A2SD app will do the magic itself.
P
ext3 ok ... i formated with ext2
That should work too...
P
modaco said:
Not right actually... as the original kernel is being used.
Investigating now, I probably screwed up something in the init.rc in the boot image
P
Click to expand...
Click to collapse
Have you checked that your kernel is the same as the kernel of the people who's wifi doesnt work?
Maybe it's simple to check logcat for any error while atempting to enable wifi
Team Win Recovery Project 2.2, or twrp2 for short, is a custom recovery built with ease of use and customization in mind. It’s a fully touch driven user interface – no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
ChangeLogs
CHANGELOG for 2.6.1.0:
Initial SELinux support (only a few devices, need testers so come by IRC if your device doesn't have it and needs it)
Initial support for f2fs file system formatting (Moto X)
Update SuperSU install for 4.3 ROMs
Fixed a permissions bug on files created during backup
Fixed a bug that caused TWRP to not wait for compressed backups to finish causing 0 byte files and md5sums to not match
Fixed decryption of encrypted data so that both TouchWiz and AOSP decryption are possible
Ignore lost+found folder during backup and size calculations
Various other minor bug fixes and tweaks
CHANGELOG for 2.6.0.0:
What's new in 2.6.0.0:
Special Note: If you are running a custom theme, some of the changes in 2.6.0.0 will likely not be visible with your custom theme.
Can encrypt a backup to prevent theft of private data from your backup files
Updated graphics / icon courtesy of shift
Updated exFAT to latest commits
Fixed a problem with Samsung TouchWiz decryption
Update SuperSU binary
Fixed saving of backup partitions list
Fixed saving of last used zip install folder
Fixed backup of datadata on devices that use a separate partition for datadata
Fixed some issues with the advanced wipe list (android_secure, can now wipe internal storage on data/media deivces and wipe data on the advanced list no longer formats the entire data partition)
Fixed some problems with partitioning a SD card
Various other bug fixes and tweaks
Notes about encrypted backups:
Why encrypt your backups? -- Most people store their backups on the device. Any app that has permission to access storage could potentially read your backup files and try to harvest your data. Encrypted backups also provide an added layer of security if you move your backups to other storage devices or to the cloud. The encryption that we're using is probably not strong enough for enterprise level security, but should be strong enough to make it significantly difficult to get to your data.
Encryption is using OpenAES which uses AES 128-bit cbc encryption. If you happen to use a longer password (over 16 characters) then the encryption strength improves to 192 or 256 bits. Do not forget your password. If you forget your password you will be unable to restore your backup. We don't encrypt the entire backup. Encryption is very CPU intensive and can be fairly slow even when we spread the workload over multiple cores even on the latest high-end devices. To ensure that encrypted backups don't take forever, we don't encrypt any other partitions besides /data and in /data we don't encrypt /data/app (or other app related directories where apks are stored) and we don't encrypt dalvik cache.
CHANGELOG for 2.5.0.0:
Special Note: If you are running a custom theme, you will likely need to remove that theme before updating to 2.5.0.0 as your custom theme will likely not be compatible with the new changes!
-Added scrollable partition lists for mount, backup, restore, wipe, and storage selection
-Add new SliderValue GUI element for selecting brightness and screen timeout (thanks to Tassadar)
-Re-work AOSP and TWRP code to improve license compatibility between GPL and Apache
-Added official theme for 1080x1920 portrait devices (HTC One m7, HTC DNA, HTC Butterfly, Oppo Find 5, Sony Xperia Z, etc)
-Fixed a problem with directory permissions on split archive backups (backups usually restored with no app data)
-Fixed a problem with md5 verification of backups
-Added a search function to libtar (thanks to kokotas)
-Improve handling of XML errors (fix permissions)
-Fixed handling of subpartitions
-Improvements to recovery.fstab flags
-Fixed a problem with decryption not being able to locate the decryption key in some situations
CHANGELOG for 2.4.1.0:
Fixed a problem with mkdosfs that formatted sdcards to 2GB
Fixed handoff between vfat and exFAT on devices where blkid didn't detect vfat (fixes some issues with mounting sdcards)
Fixed problems with changing working directory on MD5 creation/checking that may have prevented unmounting
Backups will now store a copy of the backup log after the backup is completed (only if backup is successful)
CHANGELOG for 2.4.0.0:
Using libtar instead of busybox's tar for better control over tar file creation and breaking the 2GB barrier that busybox imposes (thanks to bigbiff)
Support for exFAT formatted sdcards (also thanks to bigbiff)
Support for decrypting Samsung TouchWiz encrypted devices including internal and external storage (special thanks to a3955269 for figuring it out)
Improvements to OpenRecoveryScript including displaying a proper GUI while the script is running
Added wipe cache and dalvik after ADB Sideload
Replaced many system calls with their native C counterparts
Fixed bugs in file manager where it would display an empty list after moving or deleting a folder
Fixed AOSP recovery commands to run after decryption on encrypted devices
Improvements for building TWRP in CM10.1
Other minor bugfixes and improvements
CHANGELOG for 2.3.3.0:
-Fix renaming backups with a space in the name
-Add decrypt button to mount page if you cancel decryption during startup
-Added ignore blkid flag
-Fixed handling of MTD partitions during mount
-Fixed some keyboard mapping issues on 800x1280 layout
[/hide]
This is an unofficial port of TWRP by ME (runandhide05)
Standard disclaimers
blablabla im not responsible for anything.
Download Links
2.7x pulled
*NOTE THAT YOU SHOULD ALWAYS USE THE MOST UP TO DATE RECOVERY, IF YOU ARE PLANING ON FLASHING A 4.2 BASED ROM YOU SHOULD UPDATE TO THE LATEST BEFORE FLASHING ROM.*
R.A.H._TWRPv2.6.3.zip
zip
https://www.androidfilehost.com/?fid=95916177934538765
img
https://www.androidfilehost.com/?fid=95916177934538766
all in one
https://www.androidfilehost.com/?fid=95916177934538767
R.A.H._TWRPv2.6.1.zip
Install_Scripts_R.A.H._TWRPv2.6.1.zip - 11.70 MB
R.A.H._TWRPv2.6.1.img - 5.70 MB
R.A.H._TWRPv2.6.1.zip - 5.79 MB
Install_Scripts_R.A.H._TWRPv2.6.0.zip - 11.60 MB
R.A.H._TWRPv2.6.0.img - 5.65 MB
R.A.H._TWRPv2.6.0.zip - 5.75 MB
TWRPv2.5.0
Install_Scripts_R.A.H.v3_TWRPv2.5.0.zip - 11.61 MB
R.A.H.v3_TWRPv2.5.0.img - 5.64 MB
R.A.H.v3_TWRPv2.5.0.zip - 5.75 MB
TWRPv2.4.1.0
Install_Scripts_v2.4.1.0.zip - 10.24 MB
TWRPv2.4.1.0.img - 4.95 MB
TWRPv2.4.1.0.zip - 5.06 MB
Installation Options
Installation instructions (option 1)
Download zip file from link below
Place zip on Micro SDcard
Reboot into existing recovery
Flash TWRP2.2.0_R.A.H.v0.0.X.zip
Installation instructions (option 2)
download recovery.img
place tablet in to FastBoot
Flash Recovery with
Code:
fastboot flash recovery name-of-recoveryimage.img
Installation instructions (option 3)
Download zip file, extract zip to anywhere, choose the Operating system
linux or windows folder,
For windows:
Simply click the RUNME.bat
For Linux:
Make adb and fastboot files included in the linux folder executable
Make script executable.
click RUNME.sh
Installation instructions (option 4)
download through goomanager app
GooManager
I am proud to announce that today twrp recovery is now officially available through goomanager app.
These are the Stock (non-EOS themed)
Thank you Dees_Troy
Source: runandhide05's Github
For more info on TWRP see the Team Page teamw.in
Bug tracker bug tracker
Nice
I'll try it as soon as possible & report soon
Wow. Dude you got the win factor baby!
Were you able to get open recovery script working? Heck I'll just flash . Epic win bro.
Sweet, thanks runandhide05!
(Not often I thank other people around here!)
bigrushdog said:
Wow. Dude you got the win factor baby!
Were you able to get open recovery script working? Heck I'll just flash . Epic win bro.
Click to expand...
Click to collapse
Not yet, It still errors on opening file, I'm thinking its due to the file location as /storage/.... and not /sdcard...
This is something that I will be working for next release.
Sent from my Galaxy Nexus using Tapatalk 2
solarnz said:
Sweet, thanks runandhide05!
(Not often I thank other people around here!)
Click to expand...
Click to collapse
WOW!!!! Goosebumps!
Thanks, mean a lot from you and brd!
Thanks for everything you guys do!
Sent from my Galaxy Nexus using Tapatalk 2
Big thanks, already do a backup, restore, and move file from internal to external, so many features to get use to again thanks for a very fine software...
since this is working why not change the direction of this thread to xoom android development section?
Thanks in advance
Anyone else having problems with the download links not working.
TheBurgh said:
Anyone else having problems with the download links not working.
Click to expand...
Click to collapse
Dev-host is down it seems. And I'm mobile right now.
They will be back up soon enough
Sent from my Galaxy Nexus using Tapatalk 2
runandhide05 said:
Dev-host is down it seems. And I'm mobile right now.
They will be back up soon enough
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
I love this, but I was unable to backup to external or actually do anything with external storage. Am I doing something wrong?
okantomi said:
I love this, but I was unable to backup to external or actually do anything with external storage. Am I doing something wrong?
Click to expand...
Click to collapse
Must be doing something wrong, I am able to backup to external and internal with 3 1/2 gig /data size.
Look at where it says to backup to, and select internal or external
Sent from my Galaxy Nexus using Tapatalk 2
Any mirrors dev-host seem to go down a lot lately
thisismalhotra said:
Any mirrors dev-host seem to go down a lot lately
Click to expand...
Click to collapse
Mirrors are in OP now
Sent from my Galaxy Nexus using Tapatalk 2
runandhide05 said:
Must be doing something wrong, I am able to backup to external and internal with 3 1/2 gig /data size.
Look at where it says to backup to, and select internal or external
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Problem is, it won't let me choose external, but that's not my biggest issue right now.
I can't restore from the backup I've just done (on internal), can't install anything from internal and still can't access external. I've tried many different approaches.
I can't reflash a recovery.img because I'm away from my PC so I'm stuck. I'm sure there's something I'm not getting about the file system this recovery sees...it doesn't see "storage" on the root directory. I can't access it that way.
But this is really a cool recovery, and has many great features.
okantomi said:
Problem is, it won't let me choose external, but that's not my biggest issue right now.
I can't restore from the backup I've just done (on internal), can't install anything from internal and still can't access external. I've tried many different approaches.
I can't reflash a recovery.img because I'm away from my PC so I'm stuck. I'm sure there's something I'm not getting about the file system this recovery sees...it doesn't see "storage" on the root directory. I can't access it that way.
Click to expand...
Click to collapse
Look at op where the external and internal are mounted as. I'll look into it when I have a mome t
Sent from my Galaxy Nexus using Tapatalk 2
runandhide05 said:
Look at op where the external and internal are mounted as. I'll look into it when I have a mome t
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
I think I may have resolved my issue of not being able to flash ROM and Gapps...I could do it from Goomanager in internal. If everything works, then I'll experiment some more.
Thanks for adding the locations to internal and external in the OP. It was not something I would have figured out on my own ;^)
okantomi said:
I think I may have resolved my issue of not being able to flash ROM and Gapps...I could do it from Goomanager in internal. If everything works, then I'll experiment some more.
Thanks for adding the locations to internal and external in the OP. It was not something I would have figured out on my own ;^)
Click to expand...
Click to collapse
No problem... FYI they were in op from the beginning... no anything I added.. helps to read.. lol I kid buddy.
Hope all works out for ya
Sent from my Galaxy Nexus using Tapatalk 2
runandhide05 said:
No problem... FYI they were in op from the beginning... no anything I added.. helps to read.. lol I kid buddy.
Hope all works out for ya
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Haha...thought I read it all.
Seriously, still can't seem to restore from my back-up...seems like it says complete and successful, but hasn't actually changed anything.
Let me explore it a bit more (read more, lol) and see what I've been doing wrong.
Thanks again...all of your work is very high quality and high value for us here on the Xoom.
okantomi said:
Haha...thought I read it all.
Seriously, still can't seem to restore from my back-up...seems like it says complete and successful, but hasn't actually changed anything.
Let me explore it a bit more (read more, lol) and see what I've been doing wrong.
Thanks again...all of your work is very high quality and high value for us here on the Xoom.
Click to expand...
Click to collapse
OK well I have made a backup, flashed a ROM, wiped every partition than can be formated and flashed other recoverys zips with no problem. I haven't restored a backup yet, I am at work but believe me I will be working on this tonight to get open script working and I will do some more extensive testing also.
Sent from my Galaxy Nexus using Tapatalk 2
OK, this thread is going to be a work in progress, intended to serve as a reference for the work I've been doing on LVM partition remapping.
My work was done initially on a Find 7, but this should eventually be usable on many other devices (I have the Find 5 and N1 in mind for when I return from vacation). Also, this would not have been possible without the work Steven676 did years ago on the Nexus S, which has been used by all AOSP-derivative projects to support the Samsung Aries (Galaxy S) family for quite some time now.
The current state of things is that the patches are solid and work very well for the system side of things, but there is still a bit of work needed on the recovery side of things. This is due to TWRP having an architectural limitation I need to work on - Whether a device uses emulated storage or not is set at compile time, which is a problem if your design requires automatic detection of configuration at run time.
One of the key design goals here was to support both normal and LVM configurations automatically with a single build that detects which configuration is present on a device at run time.
A second key design goal was that the underlying partition table of the device is not touched in any way. Touching the partition table of a mobile device in the field is a fundamentally dangerous operation, as many partitions contain data that is device-unique or will render a device unbootable if altered. Recovery methods that involve DDing partition images to nonstandard partitions is asking for trouble due to typos... There's no protection against a user typoing the name of a critical partition.
Initially, I'm going to dump the contents of an email I wrote to someone giving them documentation on how to integrate LVM into their project. Over time I'll clean up and reorganize this post, including adding some more links. Also, since this email was written, I've added a LOT of comments to each patch explaining what is going on.
For additional documentation, especially a more user-oriented view of things (such as how to set this up if you want to use it with Omni nightlies) - see the Omni nightlies thread on XDA.
So here goes:
How it's implemented - the complete patch set is at:
https://gerrit.omnirom.org/#/q/topic:find7_lvm - Expect this to periodically change as work on this feature continues (Note: All patches required to support nightly builds of Omni have been merged. At this point, all remaining work that I expect is on polishing up TWRP.)
With the rest of this post, I'll talk about each individual patch and what it does.
https://gerrit.omnirom.org/#/c/9273/ - This is a patch against frameworks/base which adds an alternative to storage_list.xml called storage_list_lvm.xml - The frameworks will choose storage_list_lvm.xml instead of storage_list.xml if the property ro.lvm_storage is set to 1 - The device init scripts will set this property if they detect an LVM configuration.
https://gerrit.omnirom.org/#/c/9207/ - This is an Omni-specific patch. Omni builds for both the Find 7 and OnePlus One (also known as find7op) and both share a common device tree. The LVM patches do not apply to the find7op, so we move init.recovery.rc out of the msm8974-common tree - You likely don't have to worry about this unless you also have a -common tree for find7 and find7op
https://gerrit.omnirom.org/#/c/9276/ - Normal Android kernel ramdisks do not include busybox or any form of shell, making it impossible to run shell scripts without /system mounted. Since we need to run a shell script prior to mounting partitions, we need to add busybox to the ramdisk. This patch does that. For legal reasons you may wish to replace busybox with system/core/toolbox and system/core/sh - I have not tried doing so. If you choose to stay with busybox, you will have to provide the busybox source code in order to comply with the GPL.
https://gerrit.omnirom.org/#/c/9205/ - This adds the LVM binary and LVM configuration file to the ramdisks of both normal boot and recovery. This patch does not actually begin doing anything with the binaries, I separated it out from the other patches as a way to keep things organized so I could start working with the binaries when I began this project. The original source code and documentation for the binary is at https://github.com/steven676/android-lvm-mod
One change I made in lvm.conf that differs from the Samsung aries family (galaxysmtd, fascinatemtd, captivatemtd, etc.) is that I changed the filter line to only allow the userdata and sdcard partitions. This prevents LVM's vgscan from accidentally determining another partition is a physical volume, and also prevents users from accidentally running pvcreate on a critical partition.
https://gerrit.omnirom.org/#/c/9206/ - This is where all of the "heavy lifting" is done. I'm going to work on adding more comments to the init scripts and shell scripts to document them tonight and tomorrow, but I'll try to explain things here.
Android's init system is a bit limited in that it's very difficult to have conditional behavior defined in init.rc - which appears to be why Qualcomm loves to use shell scripts called from init. Similarly, much of the LVM magic happens in three shell scripts (which execute at three different phases within the boot sequence).
In the early-init phase, the two "wait" blocks ensure that the underlying block devices are ready before vgscan/vgchange are called. This will probably slow down booting by a few fractions of a second unfortunately.
vgscan will scan the volumes defined in lvm.conf (in this case, only the userdata and sdcard partitions) for LVM physical volumes. If LVM physical volumes are detected and form a proper volume group, vgscan will create appropriate device nodes. With the configuration I'm using, the device node will be /dev/lvpool/userdata - which consists of a single logical volume that merges the sdcard and physical userdata physical volumes (partitions). The configuration of lvm.conf prevents LVM commands (especially pvcreate) from altering partitions we don't want to alter. If someone accidentally tries to, for example, run pvcreate on the system partition, it will give an error indicating that the partition was not part of the filter.
vgchange will activate the physical volumes detected by vgscan
lvm_init.sh will check to see if /dev/lvpool/userdata exists, and copy fstab.qcom.lvm to fstab.qcom, init.fs.rc.lvm to init.fs.rc, and twrp.fstab.lvm to twrp.fstab if it does. If it does not, it selects fstab.qcom.std, etc.
In the "on init" section, the init script exports all environment variables from init.fs.rc, and creates all storage-related directories and symlinks needed for both configurations (except for when they conflict). lvm_symlinks.sh will create directories/symlinks that must be configuration-specific. Just like lvm_init.sh - it decides what to do based on whether /dev/lvpool/userdata exists
In the "on fs" section - we do an SELinux restorecon on /dev/mapper/lvpool-userdata (/dev/lvpool/userdata would probably work here too). If it doesn't exist, this will fail gracefully without causing any issues.
In "on early-boot" - lvm_setprop.sh uses /system/bin/setprop to set ro.lvm_storage to 0 or 1 depending on the detected configuration. The property service is not available until early-boot - so this cannot be in lvm_init.sh or lvm_symlinks.sh This propery is used by the frameworks/base patch above to determine which storage_list to choose.
At the end of the init.qcom.rc, the fuse daemon for emulated storage is added for all configurations. (I could not figure out a good way to make this conditional based on whether LVM was present or not). In a non-LVM configuration, it runs but is harmless - it maps /data/media (which is empty) to /mnt/shell/emulated (which nothing is looking at due to the environment variables and symlinks set in the "on init" section )
You will probably notice that Omni's standard storage configuration is fairly different from ColorOS - this is due to the way KitKat storage works, but it allowed us to get away without using Oppo's ext4 permissions hacks in our kernel (by remapping permissions instead, in a manner similar to how the emulated storage system works) The way we handle our /sdcard partition does interoperate without issues with the ColorOS approach.
https://gerrit.omnirom.org/#/c/9279/ is a patch specifically for TWRP. TWRP currently determines whether to use emulated storage (/sdcard on /data/media) at build time instead of at run time. Until I have time to fix this, the patch here operates as a workaround. It is similar to the behavior of the fuse sdcard daemon in the previous patch - it maps /data/media to /sdcard whether the configuration is actually emulated storage or not. If the device is not using emulated storage (LVM), mapping of /data/media to /sdcard is still mostly harmless. However it does result in undesirable changes to TWRP's user interface. DO NOT USE THIS APPROACH IN PRODUCTION RELEASES. It's a horrible hack. You'll need to figure out how to properly do /data/media handling depending on whether LVM is present or not based on how your own recovery architecture works.
https://gerrit.omnirom.org/#/c/9281/ adds "raw" sdcard and userdata partition entries to the partition table for the LVM configuration. This allows a user to return their device to a standard configuration by formatting the underlying sdcard and userdata partitions directly, instead of the removelvm ZIP at the beginning of this email. - To be abandoned, this patch was squashed into 9206
FAQ
Q: Coldbird already had repartitioning support. Why did you create this different approach?
A: Even before he started work, I strongly recommended that he not touch the partition table of the device. It's a really bad idea and is fundamentally dangerous. It's pure luck that someone hasn't hardbricked yet. (A number of people have come close.) If you read through his thread and the ColorOS 2.0.2 thread, you'll see that the repartitioning approach fails frequently, and in multiple ways. (Missing partition contents, partition table ending early, etc. The latter is really scary, one person had the process fail at mmcblk0p19 - what if someone else's partition table write operation aborted even earlier?.) Also, nearly everyone that has implemented support for that approach has needed a separate build to support it. (Oppo is the first to manage autodetection.) I also provided him all of the reference information from Steven676's work.
LVM is far safer. The underlying partition table is not touched in any way. Instead, LVM remaps sectors on the fly so that two partitions that are not adjacent to each other on the physical storage appear as a single contiguous partition to the filesystem drivers. Linux has supported LVM for on the order of a decade, if not more. I've been using LVM on my file server since 2006. (Yes, the system is 8 years old and still working other than needing a new power supply after a thunderstorm. Nothing to do with LVM. ) In addition, the lvm.conf configuration used here provides protection against accidental typos causing damage. Undoing the changes is as simple as doing a wipe of /data and /sdcard from any standard recovery and can be done in seconds, not of running a special batch file that runs a bunch of fastboot commands and takes 4-5 minutes. Similarly, the LVM setup process currently described in the Omni thread involves flashing a single ZIP from recovery that takes only 10-15 seconds, and most of that process is flashing an LVM-aware recovery. (The only limitation currently is that the ZIP must be on external storage - USB OTG or MicroSD)
To put it simply, it Just Works. No need to back up a pile of partitions other than /data and /sdcard because those partitions are never touched or altered.
Q: I have a device with a ridiculously oversized /system partition, can I get some of that back for /data?
A: Yes, you can. Add the physical /system partition to the lvm.conf filters and add it to the lvpool when creating it, then create a smaller /system LV out of this big pool. (see updater.sh in device/samsung/aries-common/ of any AOSP-derivative for hints here.) Be careful though - leave enough spare space for growth (new Android versions, etc.) While it should be possible to use some of the LVM tools along with ext4 resize tools to reorganize the LVs without wiping, this is very difficult and you'll probably have to make users wipe /data if you want to alter /system.
*reserved 2*
Nice work, I hope all the patches can be widely used on some other devices and other roms.
systop said:
Nice work, I hope all the patches can be widely used on some other devices and other roms.
Click to expand...
Click to collapse
Yup. I know Andre from PA was working on it last week but I haven't heard from him lately.
My priority when I return from vacation will be fixing up the TWRP side of things. It's working for now, but the user interface on non-LVM configs is a little funky thanks to RECOVERY_SDCARD_ON_DATA being compile time. This has never been a problem before since a single TWRP binary never had to support two different configurations before. I plan on either doing a property-based approach or fstab-based like CWM. (It should be possible for someone to make a CWM build that automatically detects configuration without any modifications to CWM, based on reading the code - but I haven't tried it myself.)
Once TWRP is in better shape, I plan on doing the Find 5 and N1. These will have the challenge of not having a MicroSD slot, so I may have to change TWRP so that it use /tmp instead of /sdcard when doing "adb sideload", or at least gives the user that option.
Good stuff :good: I don't really need it as of yet, but when my new device is provided (warranty) I will surely give this a try.
I hope ayysir will merge the LVM support very soon ^^
Find 7u PA 4.6 beta 1
Awesome work mate. I have avoided other methods because I'm always the guy that will have a device fail at very bad timing; like during boatloader or SBL stage.
I'm really glad you have continued to work on this. I have hit thanks a few times but would also like to thank you here
tork987 said:
I hope ayysir will merge the LVM support very soon ^^
Find 7u PA 4.6 beta 1
Click to expand...
Click to collapse
He had issues with merging support, hopefully now that I've added more documentation he can try again.
how are the *.std files created?
atm this is tough for me to port from omni to cm base which AOSPA Oppo trees
ayysir said:
how are the *.std files created?
atm this is tough for me to port from omni to cm base which AOSPA Oppo trees
Click to expand...
Click to collapse
the std files are also part of the device tree
https://github.com/omnirom/android_device_oppo_find7/tree/android-4.4/configs
ayysir said:
how are the *.std files created?
atm this is tough for me to port from omni to cm base which AOSPA Oppo trees
Click to expand...
Click to collapse
For the fstabs - they are simply moves/renames of the fstab files and other storage-related items from the standard Oppo configuration (they should appear as renames/moves in the Gerrit commit...)
For the init.fs.rc file - all of the "export <blah>_STORAGE" lines from init.qcom.rc/init.find7.rc are cut out of the RC file and put into .std
Obviously, the .lvm versions of the files are the ones where the fstab has been altered to support a single data partition with emulated storage.
Amazing work and amazing posts. Thanks a lot for your sharing. ?
I've got a question related to your configuration (/data and /sdcard merged) : are the LV hot-resizables?
Wendigogo said:
Amazing work and amazing posts. Thanks a lot for your sharing. ?
I've got a question related to your configuration (/data and /sdcard merged) : are the LV hot-resizables?
Click to expand...
Click to collapse
In theory, you could probably use some of the ext4 resizing tools to do something like this, but I haven't looked into it as there isn't much point in the current config (since the LVM userdata volume is allocated to use all space on the volume group).
Something like that might be more useful if someone ever uses LVM to regain some of the wasted /system partition space on certain excessively bloated devices (like some GS4 units).
Entropy512 said:
In theory, you could probably use some of the ext4 resizing tools to do something like this, but I haven't looked into it as there isn't much point in the current config (since the LVM userdata volume is allocated to use all space on the volume group).
Something like that might be more useful if someone ever uses LVM to regain some of the wasted /system partition space on certain excessively bloated devices (like some GS4 units).
Click to expand...
Click to collapse
Thanks for your answer.
Seems I misunderstood the way it's implemented here. All space is allocated to /data? So there's no more internal sdcard right?
But in that case an external sdcard is mandatory. How is it managed when there's no sdcard?
Enjoy!
Wendigogo said:
Thanks for your answer.
Seems I misunderstood the way it's implemented here. All space is allocated to /data? So there's no more internal sdcard right?
But in that case an external sdcard is mandatory. How is it managed when there's no sdcard?
Enjoy!
Click to expand...
Click to collapse
Android has supported emulated storage (where /data/media is mapped to /sdcard with a special FUSE daemon that makes /sdcard have DOS-like permissions despite an underlying ext4 partition) since ICS. It's pretty much the standard in all new devices - the Find 7 is to my knowledge the only device launched in 2014 not to use emulated storage. Most devices in 2013 also did - Oppos were again the rare exception.
As I understand it - for some reason Chinese users prefer the legacy pre-ICS partitioning scheme. My guess is due to UMS vs. MTP - MTP is required for access to emulated storage, UMS can't be used, but a lot of older desktop OSes have issues with MTP. So Oppo finds themselves in conflict between their home market (China) and expanding in the West. That said, the Find 7 was kind of a screwup in achieving this goal, since the internal sdcard partition was ext4 which meant UMS was a no-go for it.
Entropy512 said:
Android has supported emulated storage (where /data/media is mapped to /sdcard with a special FUSE daemon that makes /sdcard have DOS-like permissions despite an underlying ext4 partition) since ICS. It's pretty much the standard in all new devices - the Find 7 is to my knowledge the only device launched in 2014 not to use emulated storage. Most devices in 2013 also did - Oppos were again the rare exception.
As I understand it - for some reason Chinese users prefer the legacy pre-ICS partitioning scheme. My guess is due to UMS vs. MTP - MTP is required for access to emulated storage, UMS can't be used, but a lot of older desktop OSes have issues with MTP. So Oppo finds themselves in conflict between their home market (China) and expanding in the West. That said, the Find 7 was kind of a screwup in achieving this goal, since the internal sdcard partition was ext4 which meant UMS was a no-go for it.
Click to expand...
Click to collapse
I've got it now. Thanks for your explanations
I saw that Oppo phones didn't follow Android guidelines (yet?) by not using the emulated_storage mounting method but I didn't know why.
And your right, mtp doesn't work in Windows XP (or is hard to make working) and there's a lot of Asian people still using it. Obvious once you said it...
And that's also why only external sdcard is accessible in UMS mode in recovery.
Thanks again for your enlightenment. ?
Reading some of the comments on G+ it looks like Oppo might be using this solution for their KitKat release. I would be so pleased if they did.
Sent from my X9076 using Tapatalk
kishd said:
Reading some of the comments on G+ it looks like Oppo might be using this solution for their KitKat release. I would be so pleased if they did.
Sent from my X9076 using Tapatalk
Click to expand...
Click to collapse
You could be pleased...
Wendigogo said:
You could be pleased...
Click to expand...
Click to collapse
Had some problems with camera focus on earlier versions of omnirom for find 7. Now those have been addressed. I installed Omni and am on the nightlies with lvm. My find 7 and find 7a will not see another rom again.
Hi guys,
I bought an USB-C flash drive recently which I wanted to use with my phone. I wanted to store big movies on it so I did a quick Google search about exFAT support. According to what I found Android supports it since KitKat. Nontheless, it doesn't work on my Nexus 5X.
I did some more digging and I found out that OEMs can simply decide not to enable this feature (possibly because it costs a license fee). Is it possible that Google wanted to save a few bucks and simply removed the support from this device?
I tried to use ext3/4 as my file system but that did fail too. I find it painfully ridiculous, that Android, which builds on Linux doesn't let me use filesystems that are supposed to be supported natively by the kernel. It's like they are trying to make things difficult on purpose.
What can I do to use my flash drive with a file system that works with my phone and doesn't have the 4GB file limit? Is there any other FS that may work without serious tinkering? Currently I'm not rooted and I intend to keep it that way because my banking app wouldn't work otherwise. I know about apps that adds support to specific filesystems but aren't they more limited than the native support?
I don't remember if I tested file system support with Android 7 or 8. Is it possible that things changed since the new Android version?
manfreed said:
Hi guys,
I bought an USB-C flash drive recently which I wanted to use with my phone. I wanted to store big movies on it so I did a quick Google search about exFAT support. According to what I found Android supports it since KitKat. Nontheless, it doesn't work on my Nexus 5X.
I did some more digging and I found out that OEMs can simply decide not to enable this feature (possibly because it costs a license fee). Is it possible that Google wanted to save a few bucks and simply removed the support from this device?
I tried to use ext3/4 as my file system but that did fail too. I find it painfully ridiculous, that Android, which builds on Linux doesn't let me use filesystems that are supposed to be supported natively by the kernel. It's like they are trying to make things difficult on purpose.
What can I do to use my flash drive with a file system that works with my phone and doesn't have the 4GB file limit? Is there any other FS that may work without serious tinkering? Currently I'm not rooted and I intend to keep it that way because my banking app wouldn't work otherwise. I know about apps that adds support to specific filesystems but aren't they more limited than the native support?
I don't remember if I tested file system support with Android 7 or 8. Is it possible that things changed since the new Android version?
Click to expand...
Click to collapse
It's not about what file systems are supported by the kernel and tools, of course ext2/3/4 is supported (the internal storage is ext4). It's about what OTG supports and that would be FAT32 and *probably* NTFS.
The tools included on the phone do not support NTFS so you cannot format it to NTFS using your phone but you can do that with the computer and then use it on the phone, if it does indeed support NTFS.
Hello!
This is my first post in this forum, please be indulgent if I don't understand some stuff or abbreviations immediately.
I recently bought a Galaxy A3 2017 (SM-A320FL) to replace my old one with shattered screen and back cover. I tried the new Poco X3 for two weeks, but I wasn't satisfied with it since it was just wayyy too large for me, and also the phone speaker was unbearably loud (all people around me could follow the conversation on phone, even on lowest volume), which then led to the decision of sending it back and buying another used A3 2017 in good condition, as I was very satisfied with it, except of limited internal storage which continued to be an issue over months and years. And since the spare parts would have cost the same as the smartphone costs used at the moment, the decision was easy.
To avoid the single problem I had with the old phone, I wanted to root the phone right from the start so I could adopt the SD card as internal storage and/or change the folder some apps (especially WhatsApp) are storing their data and media in. Since the phone is factory reset and I have the other one which is still functioning, I don't have to take much care while trying things, which is great. I took yesterday evening until late night for that plan, and although a lot of threads and posts I read said that rooting the stock OS with latest update of Android 8 is not possible, I did it after some trial and error with flashing the custom recovery TWRP through Odin and then flashing SuperSU through TWRP. If a tutorial is needed, I'd happily write down how I did it, just ask.
But I still have a problem with adopting the storage. And as far as I understood, this is related to the storage encryption of Android/Samsung. Please explain if someone knows, I'd really like to understand the mechanisms that make all of this so laborious. I tried to mount the storage in TWRP when I started it first after flashing (it persists btw, as some people said it is gone and no recovery system can be found after the phone booted normally once, why?), but ran into the problem of "internal storage (0MB)". This was solved by wiping it, then I was able to mount the SD card as internal storage and the internal storage also was shown with a reasonable size in MB. I then started the phone which was obviously factory reset by the wiping. Unfortunately I couldn't see any results in the OS (does stock Android or file manager even show these changes in some way?) and also noticed the adopted storage was not anymore adopted when inspecting it in the TWRP recovery and again the internal storage was at 0MB. I then stumbled upon the app "Root Essentials" which is said to be able to adopt the storage, but needs a zip file which must be flashed by the recovery for that process. I tried it, but the flashing process does not work, as it can't find an installation of the app - my guess is, that this also is related to encrypted storage and the 0MB problem, how should the flash be able to look for something in encrypted space?
Soo, my problem now is, that I want to adopt the storage and don't know how to continue & where to begin. I also don't know if that app "Root Essentials" is any good, just read it at several places while googling so gave it a try. The phone is rooted with TWRP (0MB problem persisting) and stock OS now, and the adoptable storage per se is no must-have for me - if there is any other solution to migrate apps and more importantly their data to the SD card, please let me know, I'd be perfectly fine with that also.
Thank you!
Flo
Hey there Flo,
I am facing the same issues like you, always having to clear up space (e.g. Chrome cache) because the internal storage is not enough for the apps. And you cannot move many of the apps to the SD card, only their data. Last time I had to rermove Teams altogether because it was eating up 500+MB, and I couldn't afford it anymore as the free space dropped below 600MB.
Sooo, here are some basics I have learnt while looking for solutions.
Current custom ROMs are not an option for me as I use this phone for banking and production tasks, and I could not find any of them stable and issue-free enough to switch from the stock one.
The stock ROM is full of bloatware, especially Samsung stuff I do not need, and some others, like the Facebook app. However, you cannot extend internal storage with your SD card as Samsung does not allow this, and this is impossible with the stock ROM.
So I am stuck here, as I cannot leave the stock ROM, but I am constantly running out of space. Currently, I have rooted my device and installed TWRP, too, and I am planning to try one of the debloated stock ROMs to see if they can solve at least my problem with running out of free space on the internal storage.
In any case, what I can confirm is that you either have the stock ROM, and then you can only install apps on the internal storage, or if you want to extend your internal storage with the SD card, you'll have to choose one of the custom ROMs that allow this and wave goodbye to Knox and some other features.
I hope the above helps.
Hi!
Thanks for your detailed answer!
I didn't find a way to adopt the storage persistently, and I think at this point I'll just take your word that it won't be possible with the stock ROM. I knew that the stock ROM adopt storage option isn't able to be brought back by some adb shell commands as it was possible earlier (until 6.0 Marshmallow I think), but I thought that it maybe is possible by tricking the storage the OS sees with the mount in TWRP before the first start. Doesn't seem to work at all (for mostly unknown reasons, at least for me ).
And same for me, I don't know if the custom ROMs nowadays are better a lot, but doesn't sound like that as you described it. I flashed Resurrection Remix on my Galaxy S4 a few years ago, and although I liked the customizability and slimness, I too often ran into bugs and errors with it, which is why I abandoned the phone in the end.
However, I kind of found a fix I can live with on the SM-A320FL: I downloaded Link2SD from Playstore and also upgraded to the plus version, which is reasonably priced. This enables to also store app data on the SD card. I tried it with the 64GB SD card I had rolling around, partitioned it with MiniTool Partition Wizard following this guide to conform Link2SD requirements, and it worked perfectly. I also uninstalled all sorts of bloatware, and as far as i saw the shift to external storage of the apps I tried works fine. All data, including app, cache and app data is moved (and/or linked, not sure) to the ext2 partition on the SD card (which is shown to be a broken partition in Android storage settings btw, but that's fine). If any, only <1KB of file size per app remains in internal storage, which seems great!
I am currently waiting for my ordered 256GB SD card (U3, A2) to arrive next week, then I will do the full port from the old to the new A3 and I'll see how WhatsApp and Spotify behave being stored in external storage. Hopefully Link2SD is able to shift them, especially WhatsApp, since that was the main factor in cluttering the internal storage very fast and efficient.
If the Link2SD doesn't work for WhatsApp media, I'll give FolderMount a try, the direct mount then seems to work for many.
Since you mentioned it: What are the great features of Knox? The secure folder? Data encryption by screen lock? I can't remember using Knox features knowingly in the past three years. Is Knox not already blown by flashing a custom recovery?
Thanks for your help!
Flo
The internal storage data partition not mounting in TWRP is due to the partition being encypted when Android is booted, but also due to quota being enabled and latest version of TWRP for this phone (3.2.3-0 AFAIK) being unable to mount this. Fix for this is to flash a zip from Zackptg5 which disables both these options. See https://forum.xda-developers.com/t/...y-a3-sm-a320f-fl-y-2017.3562302/post-79260952 for full details
I see that OrangeFox is available now (https://orangefox.download/device/a3y17lte), so maybe this is able to mount without these problems, I am going to flash this soon so I will let you know!
FYI I am using H-ROM by Astrako. Very close to stock (it is a port from the A7) and seems to work well. VoWiFI is working in this ROM which was essential for me.
lastsaskatchewanpirate said:
The internal storage data partition not mounting in TWRP is due to the partition being encypted when Android is booted, but also due to quota being enabled and latest version of TWRP for this phone (3.2.3-0 AFAIK) being unable to mount this. Fix for this is to flash a zip from Zackptg5 which disables both these options. See https://forum.xda-developers.com/t/...y-a3-sm-a320f-fl-y-2017.3562302/post-79260952 for full details
I see that OrangeFox is available now (https://orangefox.download/device/a3y17lte), so maybe this is able to mount without these problems, I am going to flash this soon so I will let you know!
FYI I am using H-ROM by Astrako. Very close to stock (it is a port from the A7) and seems to work well. VoWiFI is working in this ROM which was essential for me.
Click to expand...
Click to collapse
Did “orange fox” work?
King p1n said:
Did “orange fox” work?
Click to expand...
Click to collapse
Yes, with OrangeFox I didn't need to flash the zip file from Zackptg5 which removes quota. I didn't get on with the latest H-ROM 6.0 (too many niggles, particularly ambient light sensor doesn't work so no adaptive brightness; fingerprint scanner doesn't work in apps; video call doesn't work in WhatsApp), but OrangeFox worked really well, definitely recommend it. Sorry for not remembering to come back and update sooner!
lastsaskatchewanpirate said:
Yes, with OrangeFox I didn't need to flash the zip file from Zackptg5 which removes quota. I didn't get on with the latest H-ROM 6.0 (too many niggles, particularly ambient light sensor doesn't work so no adaptive brightness; fingerprint scanner doesn't work in apps; video call doesn't work in WhatsApp), but OrangeFox worked really well, definitely recommend it. Sorry for not remembering to come back and update sooner!
Click to expand...
Click to collapse
Thank you
Which rom do you use and recommend?
Or can orange fox be used with the stock rom?
Doing this on behalf on a friend who is struggling with storage issues, been years since I’ve touched android
King p1n said:
Thank you
Which rom do you use and recommend?
Or can orange fox be used with the stock rom?
Doing this on behalf on a friend who is struggling with storage issues, been years since I’ve touched android
Click to expand...
Click to collapse
Currently I use H-ROM 2.0 (https://forum.xda-developers.com/t/...7-port-v2-0-pie-oneui-64-bits-treble.3940532/) which works well. Only two main niggles that I might change back to stock - video doesn't work in WhatsApp (but is OK in WhatsApp Business) and some VoWiFi calls have echo, but this might just be normal for VoWiFi, not had echo on normal cell network calls. Stock ROM is now available with Android 8 (Oreo) so when I have time I was intending to try that again, maybe with debloat to remove some of the stock apps.
I would recommend OrangeFox, and although I started with TWRP and flashed this over the top, I think you should be OK to just flash this straight from Odin. TWRP would only flash in old version of Odin, I would guess OrangeFox maybe would be the same. Flash in AP using older version Odin3 v3.12.10. Untick auto reboot, when complete power off with vol down + power, then force to recovery using volume up, home and power
lastsaskatchewanpirate said:
Currently I use H-ROM 2.0 (https://forum.xda-developers.com/t/...7-port-v2-0-pie-oneui-64-bits-treble.3940532/) which works well. Only two main niggles that I might change back to stock - video doesn't work in WhatsApp (but is OK in WhatsApp Business) and some VoWiFi calls have echo, but this might just be normal for VoWiFi, not had echo on normal cell network calls. Stock ROM is now available with Android 8 (Oreo) so when I have time I was intending to try that again, maybe with debloat to remove some of the stock apps.
I would recommend OrangeFox, and although I started with TWRP and flashed this over the top, I think you should be OK to just flash this straight from Odin. TWRP would only flash in old version of Odin, I would guess OrangeFox maybe would be the same. Flash in AP using older version Odin3 v3.12.10. Untick auto reboot, when complete power off with vol down + power, then force to recovery using volume up, home and power
Click to expand...
Click to collapse
just to clarify I could use Orange fox with stock rom and enable adopted storage? So I can use SD for apps when necessary.
I did get adopted storage working of sorts, but certain screens were missing from storage in the setting menu (I think Samsung didn't include or removed these as the phone was not intended to work with Adopted Storage), so it would crash when trying to perform certain actions. I can't actually remember now if you could move apps to the Adopted Storage using the standard system menus, it was so flakey that I stopped using that and switched to using Link2SD (which I had already used before so had a Plus license for) and this does exactly what I needed. These are the steps I used to get Link2SD working: https://forum.xda-developers.com/t/app-1-6-link2sd.919326/post-82757807. I don't think you need the Plus version, but it doesn't cost much, removes the ads and lets you move a few more files. Hope that helps