Develop Bugs

Making a bigger /data partition for apps

I've been wanting to make a larger /data partition on a Droid Incredible. I mean, after all, it comes with a lot of storage. But there is not nearly enough for apps. Sure. I can use my SD card. But unless there is something I'm not aware of, you can only install some apps to the SD and even when you do, pieces of that app still exist in /data. But what's even worse is the fact that I already use my SD card for movies and videos and such and I just don't really use the unclaimed space of which there is plenty, in the phone, for that sort of thing and yet I can't use it to install apps. I haven't found too much on this topic outside of using App2SD. I did find a lot of talk of using parted and even gparted. But this talk is generally about partitioning your SD card. If I were to use parted or gparted to resize the /data partition at the expense of another partition's space and I did it properly, would the Android system not boot because of it? And if this is doable, is there a better, easier way to do it than using parted and adb or gparted? Also, is there a guide for resizing your /data partition? I could probably survive without one if I had to but it would really be helpful just in case there are some big DO NOT DO's that should be avoided that aren't obvious. Any help would be greatly appreciated.

enigmatl said:
I've been wanting to make a larger /data partition on a Droid Incredible. I mean, after all, it comes with a lot of storage. But there is not nearly enough for apps. Sure. I can use my SD card. But unless there is something I'm not aware of, you can only install some apps to the SD and even when you do, pieces of that app still exist in /data. But what's even worse is the fact that I already use my SD card for movies and videos and such and I just don't really use the unclaimed space of which there is plenty, in the phone, for that sort of thing and yet I can't use it to install apps. I haven't found too much on this topic outside of using App2SD. I did find a lot of talk of using parted and even gparted. But this talk is generally about partitioning your SD card. If I were to use parted or gparted to resize the /data partition at the expense of another partition's space and I did it properly, would the Android system not boot because of it? And if this is doable, is there a better, easier way to do it than using parted and adb or gparted? Also, is there a guide for resizing your /data partition? I could probably survive without one if I had to but it would really be helpful just in case there are some big DO NOT DO's that should be avoided that aren't obvious. Any help would be greatly appreciated.
Click to expand...
Click to collapse
theres around 780mb in there thats not enough?

JoelZ9614 said:
theres around 780mb in there thats not enough?
Click to expand...
Click to collapse
He's talking about /data/data/ which is like 150mb, I use the NotEnoughSpace app it lets you store data on cache, emmc, sd card, you should check it out.

Well, I messed with notenoughspace too which was my eason for posting. This was the app that made me say enough is enough, can I just resize /data/data?.
-1- So much space on the incredible is going to waste while programs such as these would have me put apps on the SD where I really do want space for my other stuff like music and movies.
-2- Unless I missed a button or option, NotEnoughSpace came off as annoying to me. I would go into apps and wait for a minute for it to scan every time I do it and then I pick an app, for example Beejive. It makes me move it ONE FILE AT A TIME. And even then, there is stuff you can't move. Can I not just move the app, all of it in one click?
But most importantly, I just want more space on /data/data. I want to resize the partition. The phone has what, 8 gigs on it and allows 150 mb for apps in there which is just crazy.
Can I resize the partition where apps are stored (/data/data) by way of parted or gparted? to avoid the annoyance of using my external storage which I want to use for movies and music? There's probably 6 or so gigs on my phone I'll never use for media that should be meant for apps.
Has anybody resized the data partition? Are there consequences to doing it if it's done properly? Is there a guide? What is the easiest way to do this? Any help would be appreciated.

enigmatl said:
Well, I messed with notenoughspace too which was my eason for posting. This was the app that made me say enough is enough, can I just resize /data/data?.
-1- So much space on the incredible is going to waste while programs such as these would have me put apps on the SD where I really do want space for my other stuff like music and movies.
-2- Unless I missed a button or option, NotEnoughSpace came off as annoying to me. I would go into apps and wait for a minute for it to scan every time I do it and then I pick an app, for example Beejive. It makes me move it ONE FILE AT A TIME. And even then, there is stuff you can't move. Can I not just move the app, all of it in one click?
But most importantly, I just want more space on /data/data. I want to resize the partition. The phone has what, 8 gigs on it and allows 150 mb for apps in there which is just crazy.
Can I resize the partition where apps are stored (/data/data) by way of parted or gparted? to avoid the annoyance of using my external storage which I want to use for movies and music? There's probably 6 or so gigs on my phone I'll never use for media that should be meant for apps.
Has anybody resized the data partition? Are there consequences to doing it if it's done properly? Is there a guide? What is the easiest way to do this? Any help would be appreciated.
Click to expand...
Click to collapse
Ask conap hes good with this type of thing

Making progress but still need help.
There's some talk on the net that you can modify the size of the .img files that nandroid makes and simply flash them back to your phone.
Problem is, I can't find a windows way to do it on the net. The closest that I've come is a program called toporesize. This program will let you open files such as data.img from your nandroid backup. But you can't resize them because you get an error box that says this appears to not be an ext* filesystem. Check size file only to resize the file or use other tools. I'm assuming that means it wants you to check a button that says resize file only no resize2fs. In the one guide I found that talks about this app, it says do not check this box. So I'm assuming if you did, it would work and then when you flashed the file back to your phone, it would either not boot or the size would not be changed properly.
I also noted that there's a thread or two that has posted some custom sized data.img files for download. I would do this as a last resort but would prefer to resize my own data.img for a more precise choice of how large I want it.
The error mentions other tools. Are there other tools or programs for Windows users?
Does anybody have any insight on resizing the /data/data partition either by this method, by using parted/gparted, or any other method that works effectively?

I would avoid trying to alter the size of the partitions on your phone. That is how you end up with a brick. There are other ways including finding out which apps are taking up all of your space. 150 MB does not sound like a lot, but it is considering what is stored there.
Go into Manage Applications and click on the All tab. Then press the menu key and sort by size. Click on the apps near the top with anything higher than 3 or 4 MB. Look at the details in the storage section for each app. You will see a Data line item. If it is really high in proportion of the size of the Application, you should clear it. That will save you a lot of space.
In the case of the Mail app or other social networking apps like Facebook or Twitter, you can go into the settings and restrict how much data is stored on the phone. They can really eat up space by downloading a month of emails, etc ...

ihtfp69 said:
I would avoid trying to alter the size of the partitions on your phone. That is how you end up with a brick. There are other ways including finding out which apps are taking up all of your space. 150 MB does not sound like a lot, but it is considering what is stored there.
Go into Manage Applications and click on the All tab. Then press the menu key and sort by size. Click on the apps near the top with anything higher than 3 or 4 MB. Look at the details in the storage section for each app. You will see a Data line item. If it is really high in proportion of the size of the Application, you should clear it. That will save you a lot of space.
In the case of the Mail app or other social networking apps like Facebook or Twitter, you can go into the settings and restrict how much data is stored on the phone. They can really eat up space by downloading a month of emails, etc ...
Click to expand...
Click to collapse
This request is meant with respect and NOT as a flame but I have to make this request so others don't follow and potentially change the thread into a debate on whether to resize or not resize the partition.
Please let's not start talking about whether this is a good idea or not nor if doing this can make our phone into a brick. Now that it's been said, those lurking and considering this for themselves can make up their own minds. But there are a lot of things talked about throughout XDA that can make your phone into a brick yet things are done in the name of making our devices better.
And yes. We can take action to reduce the amount of data that apps are taking up. To tell you the truth, I would do that even if I had a 1GB partition. I think always saving space when space can be saved is a good idea.
But just in principle, I and probably others want to reclaim that space on our phones that will never be used by anything. Maybe HTC allocated the space as it's allocated because some users won't use an SD card and will then use that space for their media and other miscellaneous stuff.
But once you have an SD card that's way bigger than the extra space on your phone, it becomes pointless to use that space on your phone for media. So I want it available for data.
So both sides of whether to do this or not have now been posed. I ask can we please get back to the topic of how to though I do thank you for your input.
That said, again, does anybody know how to resize your data partition whether by doing it live with parted or gparted or by editing the data.img file that nandroid via clockwork mod puts out? I would really appreciate it.
I tried making a nandroid backup of the phone through clockworkmod, sending the data.img file to my computer, using toporesize to resize it. And by the way, I was forced to check the resize file only no resize2fs button as not doing this generated an error. I then used md5sum to get an md5sum for the new data.img. I then inserted the md5sum in clockwork/nandroid's nandroid.md5 file (with a linux file compatable text editor). I then sent the entire backup back to the phone in a different clockworkmod/backup folder, used rom manager to restore, selected the new resized backup.
After the flashing was complete, I went into my phone only to find that the data partition still had the same amount free (give or take a few K). I wondered if that's because I had to shrink the system file? I was thinking before I started that it's probable that I would have to shrink another partition that had free space so I chose system. I attempted to repeat the above steps from the beginning this time with the plan of shrinking system.img.
No go. toporesize will not shrink it properly. Errors are reported in the process though when I reload it into toporesize, it looks like it has the size I want. Knowing it would probably fail, I tried to continue anyway. Even with the correct md5sum, nandroid won't even start the recovery of that set. You get a status bar for a second and then, the phone just reboots.
So for now, I'm at a loss but I know this can be done.
Whether using this method or another, does anybody know how to properly change the size of the data partition using WINDOWS?

Don't come crying when you brick it.

ihtfp69 said:
Don't come crying when you brick it.
Click to expand...
Click to collapse
I have no intentions of such. -1- I will quite likely never brick it as nandroid pretty much has me covered. But if I do, -2- I don't plan on having this phone forever. It's not new any more. There are already several models that are better than the droid incredible that I'm looking at. If I were to brick this phone, yay. Good excuse to buy a new phone. But, odds are, i'll never brick it and come November or December, I'll buy something else anyhow.
So please, this isn't about the risks, of course you can brick your phone trying this or many other things on XDA.
Does anyone know how to resize the data partition using any method that can be done with the help of a Windows machine?

This is a fundamental change to a very sensitive area you have
276 mb for the system rom and 748mb for user apps.Many rom devs seem to be straining to keep the rom below 200mb and it is amazingly easy to fill up 748 mb with little apps.
I would think if it were possible to do this it would have been done by the rom devs first thing. I would love to see a rom dev bump this to 500mb and 1024mb.
Chances are to re partition the partitions on the phones memory is not possible with out a hboot flash or something of a custom bootloader...
I find removing these help... Also i use handcent and gmail.app instead of the stock apps...
friendstream
peep
twitter
flicker
stocks app
facebook

748 mb? I only have 150 available in /data/data. How do you get 748?

enigmatl said:
748 mb? I only have 150 available in /data/data. How do you get 748?
Click to expand...
Click to collapse
748mb is the size of the entire /data partition what us devs are doing with the new roms is symlinking things to the /system from /data i've managed to do it without symlinking but it bring the /system to its limits and thats usually not good to do

enigmatl said:
748 mb? I only have 150 available in /data/data. How do you get 748?
Click to expand...
Click to collapse
In my /data/data i have 95.96 MB free
rom 35MB free
app space 212 MB free
internal 6.44GB free

Also /data/data is a different partition than /data so the 150 is not included as part of the 748.

Resize /data/data partition - Update?
Did you ever find a solution to resizing the HTC Incredible's partitions?
I too am fed up with having to constantly clear caches and uninstalled apps, just because the tiny 150MB partition fills up. It's been a problem since my wife and I bought our phones.
I expect it would have to be done by a custom bootloader, but thought I would check and see if you had any success.
If nandroid recreates the partition tables based on the sizes of the .img partition backups, then they could probably be resized by mounting the .IMG files directly under Linux and using Linux tools to resize each one - or - creating a new .img partition of the new size(s), mount the backups and copy everything over to the new one, unmount it and go from there?
Steve

Have you used the Ext4 mod created by Tiny and Jermaine151?
http://forum.xda-developers.com/showthread.php?t=1623038
...and the following is the original thread which has the details of what exactly the mod does:
http://forum.xda-developers.com/showthread.php?t=1315372
If I'm reading this (outdated) thread correctly, this mod is what you're looking for in regards to partitioning /data/data. The second link is provided in the OP of my first link.

SlimSnoopOS said:
Have you used the Ext4 mod created by Tiny and Jermaine151?
http://forum.xda-developers.com/showthread.php?t=1623038
...and the following is the original thread which has the details of what exactly the mod does:
http://forum.xda-developers.com/showthread.php?t=1315372
If I'm reading this (outdated) thread correctly, this mod is what you're looking for in regards to partitioning /data/data. The second link is provided in the OP of my first link.
Click to expand...
Click to collapse
What he said ^^^^
Just do it.

[Q] Can I safely resize the system partition?

I have done wonderful things to my device thanks in large part to this community. Thank you.
I see that the system partition has about 1 GB of free space yet there are only 427 MB of files in there. Do I need that much free space? If not, how can I safely resize it?

Using parted. I've tried doing it though, shrinking my data partition to give more to system but it won't stick for some reason. Either I'm doing it wrong, or it doesn't work
The parted binary for android can be found on Cyanogenmod's github in the android_bootable_recovery repo

@CNexus, thanks. I appreciate that. I'll take a peek at that. Strangely enough I'm looking to shrink my system partition. I've seen others are wanting the opposite.
I've partitioned PC drives before but this appears to be much more involved.
Does anyone know of an optimum allotment for system and cache that I should follow?

You should be fine whatever you do.
Worst case if something goes wrong, just flash the PIT file for your internal storage size in Odin and all should be good
But yes, this will be more involved since it will need to be all command-line

[REF] LVM Partition Remapping

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.

Changing Partition Sizes of internal flash memory

Hi,
after removing all the bloatware and some apps I will never use there is a little over 1G of free space in my system_root partition. Since both system a/b and userdata partitions are on sda I assume it is the same physical device. So in theory it should be possible to shrink the systems partitions and grow the userdata. Has anybody tried to do this? Does anybody know what type of encryption is used on userdata - it doesn't seem to be luks. I have a linux background and am quite surprised how much android differs from what I am used to...
Cheers
Paul

alpinista82 said:
Hi,
after removing all the bloatware and some apps I will never use there is a little over 1G of free space in my system_root partition. Since both system a/b and userdata partitions are on sda I assume it is the same physical device. So in theory it should be possible to shrink the systems partitions and grow the userdata. Has anybody tried to do this? Does anybody know what type of encryption is used on userdata - it doesn't seem to be luks. I have a linux background and am quite surprised how much android differs from what I am used to...
Cheers
Paul
Click to expand...
Click to collapse
In theory it's possible. But in practice it's extremely difficult, especially with all the partitions on todays devices. Changing a partition effects all partitions after it and they all need to be recreated. It's also extremely dangerous if you don't really know what your doing. I successfully did it on an old skyrocket just for fun. But I wouldn't want to try it on the pixel. I'm not even sure what the dual slots would entail.
Sent from my [device_name] using XDA-Developers Legacy app

alpinista82 said:
Hi,
after removing all the bloatware and some apps I will never use there is a little over 1G of free space in my system_root partition. Since both system a/b and userdata partitions are on sda I assume it is the same physical device. So in theory it should be possible to shrink the systems partitions and grow the userdata. Has anybody tried to do this? Does anybody know what type of encryption is used on userdata - it doesn't seem to be luks. I have a linux background and am quite surprised how much android differs from what I am used to...
Cheers
Paul
Click to expand...
Click to collapse
What bloatware did you remove?

airmaxx23 said:
What bloatware did you remove?
Click to expand...
Click to collapse
Everything that is not related to basic phone functionality or camera. Like two dozen apps. arcore, vrcore, all the carrier and e-sim stuff, play music/video, and a lot of other unnecessary stuff.

This is an answer to jd1609, I hit the wrong button:
Yeah, I thought so. Android has evolved quite a bit since cm14 (Android 7.1). I am just starting to understand whats going on with a/b partitions. I still don't quite understand why they had to go with sparse images instead of just raw images. Most probably to confuse me a bit more ....
But thanks a lot for sharing your experiences.
Cheers
Paul

hey xda - resize system partition?

Hey XDA, hope all is going as well as possible.
I'm hoping if you could provide some information.
So, I tried to move an app to the system partition, but, the system partition is full and , well, the attempt to move the app obviously was unsuccessful.
Is it possible to resize partitions without corrupting any data or something?
I didn't do any search just yet. I felt this was the first step being that this is the device I own and it's the question and answer sub.
Hope you're willing to help, thanks.

Which version of Android are you running? If it is 11 then you can't resize it. If you want to move a app to the system then you need to install systemizer module for magisk and install it with terminal. Though I haven't had much luck with that either.
What has worked for me 100% reliably is to make a module for magisk that will inject the app into system
Androids new Scoped storage format will not allow edit the system partition.

tha_mechanic said:
Which version of Android are you running? If it is 11 then you can't resize it. If you want to move a app to the system then you need to install systemizer module for magisk and install it with terminal. Though I haven't had much luck with that either.
What has worked for me 100% reliably is to make a module for magisk that will inject the app into system
Androids new Scoped storage format will not allow edit the system partition.
Click to expand...
Click to collapse
Thanks for the reply. I'm on 10.

I believe 10 is formatted the same way

As mentioned, it is not a space issue, the issue is that you cannot write to the system. If you want an app to act like a system app you would have to compile it that way or use a magisk module to mount it to system. You cannot directly put it in system otherwise.