USB OTG support for sd-ext

[Speeddymon]

Hi. I'm running CM 10.1 on a Galaxy Nexus (doesn't have SDcard). I have a USB OTG cable and USB stick plugged in. Stick is formatted as recommended for SD-ext (1st partition is FAT32, 2nd is ext4) but your program (and all others I have tried) do not find it.

USB stick shows up as /dev/block/sda, with /dev/block/sda1 and /dev/block/sda2 as partitions. /dev/block/sda2 is the sd-ext partition.

Would you mind fixing your tool to check for that partition setup also?

If it helps for other nexus devices running CM10.x, I think the block devices are handled through /dev/block/vold directory. In my case there are 3 files: 8:0, 8:1, and 8:2 in there that also reference the USB stick. It seems vold it still used even in nexus with JB4.2 (at least for CM10.x)

[dbergloev]

Sd-ext scripts is not designed for OTG Plugged USB devices. They are
designed to act as internal storage, which means that no developer would
ever make support for OTG as those are not attached to the device
itself. The device would not work if those was unplugged. And no person
would want a device with an OTG Attached that they can't remove, because
it would break the ROM, so sorry no. It would make no sense to add
support this.

On 11/03/2013 05:32 AM, Speeddymon wrote:

Hi. I'm running CM 10.1 on a Galaxy Nexus (doesn't have SDcard). I
have a USB OTG cable and USB stick plugged in. Stick is formatted as
recommended for SD-ext (1st partition is FAT32, 2nd is ext4) but your
program (and all others I have tried) do not find it.

USB stick shows up as /dev/block/sda, with /dev/block/sda1 and
/dev/block/sda2 as partitions. /dev/block/sda2 is the sd-ext partition.

Would you mind fixing your tool to check for that partition setup also?

If it helps for other nexus devices running CM10.x, I think the block
devices are handled through /dev/block/vold directory. In my case
there are 3 files: 8:0, 8:1, and 8:2 in there that also reference the
USB stick. It seems vold it still used even in nexus with JB4.2 (at
least for CM10.x)

—
Reply to this email directly or view it on GitHub
#21.

[Speeddymon]

I think I misunderstood the intent of your app then. I was looking for
something that would allow me to mount and umount at will without having to
go into a terminal.

If your app would not allow me to do that simple thing (even with an SD)
then your app is useless to me).

The reason for this by the way should be obvious. I'm out of space on my
phone and want to archive some infrequently used apps such that I don't
need to uninstall and reinstall them later by uninstalling other apps.

See, when you umount the USB stick, the launcher would automatically remove
those apps from the list while leaving the links from /data (created by
link2sd) in place. Then later when I need them, I plug it in, the links
start working again and boom they reappear in the launcher.

Additionally, I could also have certain apps able to be transferred between
devices, say a game that I want to play between my nexus 10 and my galaxy
nexus, which I want to start on my galaxy nexus at a doctor apt and then
continue on my nexus 10 later at home.

Guess if that makes no sense then so be it, you'd never add support, but it
would be handy for me.

Just because nobody else has asked for it doesn't mean it wouldn't be
something people would use... Maybe nobody has thought of it before?

Thanks anyways I guess, unless you have a sudden change of heart.
On Nov 3, 2013 4:50 AM, "Daniel Bergløv" notifications@github.com wrote:

Sd-ext scripts is not designed for OTG Plugged USB devices. They are
designed to act as internal storage, which means that no developer would
ever make support for OTG as those are not attached to the device
itself. The device would not work if those was unplugged. And no person
would want a device with an OTG Attached that they can't remove, because
it would break the ROM, so sorry no. It would make no sense to add
support this.

On 11/03/2013 05:32 AM, Speeddymon wrote:

Hi. I'm running CM 10.1 on a Galaxy Nexus (doesn't have SDcard). I
have a USB OTG cable and USB stick plugged in. Stick is formatted as
recommended for SD-ext (1st partition is FAT32, 2nd is ext4) but your
program (and all others I have tried) do not find it.

USB stick shows up as /dev/block/sda, with /dev/block/sda1 and
/dev/block/sda2 as partitions. /dev/block/sda2 is the sd-ext partition.

Would you mind fixing your tool to check for that partition setup also?

If it helps for other nexus devices running CM10.x, I think the block
devices are handled through /dev/block/vold directory. In my case
there are 3 files: 8:0, 8:1, and 8:2 in there that also reference the
USB stick. It seems vold it still used even in nexus with JB4.2 (at
least for CM10.x)

—
Reply to this email directly or view it on GitHub
#21.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-27642358
.

[dbergloev]

This is not Link2SD, this one acts a bit differently and you would not be able to just remove the stick. You are looking at the wrong applications for this, and you have completely misunderstood the purpose of this one.

What you need, does not exist and for good reason. Developers know how Android Package Management work and therefore no one would ever attempt this. This is now Windows where you can just put apps in different folders, desktop etc and launch them from anywhere. Android has strict rules.

First of all, the Applications is not the once using most space. You have App Data which cannot just be moved around like that, because they require specific permissions that needs to be registered on the system. These permissions are auto generated. If you plug your stick into another device, those permissions (UID, GID) will not exist and your App Data will not work. Also, if you unplug, Android will properly see this as an uninstall and remove the GID and UID from the first device as well.

Second you have the Dex Cache. Same rules apply here.

[Speeddymon]

Regarding the transferring between devices you're right, and I hadn't
thought about that. Also, I never said I wanted to move just the
application, the intent had been to move the data too, same as how titanium
backup allows you to keep apps between stock and cyanogen for example.

As far as removing the permissions when you unplug, I'm skeptical of this
because you can unmount an sdcard with the stock OS (plug the phone into
the computer and it unmounts) on phones that have them, and apps that were
moved there by the native apps to sd functions don't lose their
permissions. Granted the cards are formatted as fat32 so the OS must be
storing the permissions elsewhere.

Thoughts?
On Nov 4, 2013 12:08 AM, "Daniel Bergløv" notifications@github.com wrote:

This is not Link2SD, this one acts a bit differently and you would not be
able to just remove the stick. You are looking at the wrong applications
for this, and you have completely misunderstood the purpose of this one.

What you need, does not exist and for good reason. Developers know how
Android Package Management work and therefore no one would ever attempt
this. This is now Windows where you can just put apps in different folders,
desktop etc and launch them from anywhere. Android has strict rules.

First of all, the Applications is not the once using most space. You have
App Data which cannot just be moved around like that, because they require
specific permissions that needs to be registered on the system. These
permissions are auto generated. If you plug your stick into another device,
those permissions (UID, GID) will not exist and your App Data will not
work. Also, if you unplug, Android will properly see this as an uninstall
and remove the GID and UID from the first device as well.

Second you have the Dex Cache. Same rules apply here.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-27665900
.

[dbergloev]

You cannot compare the internal to sdcard function. It is a strange hack that Google came up with in a hurry because of complaints about storage space issues. That part is handled differently than regular app management.

Anyways, Mounts2SD has a different purpose, and it is not build to handle a request like this. Both the app and script would require some serious work in order to meet your demands, and it would be easier to just make a new separate app that was build with this intent to begin with. But I don't think that the requirement for this is high enough to interest any developer.