(2015-01-14, 17:49)germank Wrote: [ -> ]...
OK. My question was directed more towards the following point: if I replace a file with a link to the file, on any normal linux system, everything depending on that file should keep on working exactly as it was before. I guess that this claim holds pretty much consistently. Therefore, if I move the apk and link it, it should keep on working. But it doesn't. I guess that goes in the direction of what you were pointing out: for some reason the loader looks at whether the apk is a symbolic link or not.
...
Indeed, you got my point right. This was actually the case with JB, all working precisely as it should, the only flaw being that you could link the app moved onto a fat filesystem.
Now I know for sure it is not limited to leagoo or mijue as I also have some mediaboxes and tablets having the same problem.
Hi Mirandam !
I recommend you Gparted Live CD instead Win tools to create the partitions FAT32 & EXT4 on your microSD.
And I suggest you Link2sd. To good use of Link2sd, take a look here :
[Only registered and activated users can see links Click here to register]
Bye
(2015-01-14, 18:49)mirandam Wrote: [ -> ] (2015-01-14, 17:49)germank Wrote: [ -> ]...
OK. My question was directed more towards the following point: if I replace a file with a link to the file, on any normal linux system, everything depending on that file should keep on working exactly as it was before. I guess that this claim holds pretty much consistently. Therefore, if I move the apk and link it, it should keep on working. But it doesn't. I guess that goes in the direction of what you were pointing out: for some reason the loader looks at whether the apk is a symbolic link or not.
...
Indeed, you got my point right. This was actually the case with JB, all working precisely as it should, the only flaw being that you could link the app moved onto a fat filesystem.
Now I know for sure it is not limited to leagoo or mijue as I also have some mediaboxes and tablets having the same problem.
I have resolved this issue on my Mijue at long last!!!
I am using SuperSU. There is an setting in there "Mount namespace separation" which seemed to be causing all the problems.
When I unchecked this (and rebooted) I was able to use Link2SD to create symlinks.
Double check this if you are a SuperSU user!
Ok, good suggestion, I will try this.
Tremendous find, works like a charm.
This is indeed the solution to the problem and it actually makes sense because link2sd is indeed using root to change the app & data's location and when root uses a different namespace it will not be seen in a user namespace, which in turn makes sense with respect to the enhanced security of kitkat.
Now why the link2sd developer never mentioned this is beyond me, he should have bumped into this long time ago I would think.
Just a question to @davidg : How on earth did you get to find this?
(2015-05-23, 19:15)mirandam Wrote: [ -> ]Ok, good suggestion, I will try this.
Tremendous find, works like a charm.
This is indeed the solution to the problem and it actually makes sense because link2sd is indeed using root to change the app & data's location and when root uses a different namespace it will not be seen in a user namespace, which in turn makes sense with respect to the enhanced security of kitkat.
Now why the link2sd developer never mentioned this is beyond me, he should have bumped into this long time ago I would think.
Just a question to @davidg : How on earth did you get to find this?
It is exactly as you say - I only really discovered it as it was stopping Titanium Backup creating a backup directory, but the TiBU app actually flagged up a warning about this precise option - and I thought to myself "I wonder if..."
Would love to claim more credit for working it out, but once I seen it mentioned by TiBU it made perfect sense!!
Have not got round to mailing the Link2SD guy yet - I will do though because a simple warning would have saved the likes of you and I months of
Its not as if SuperSU is an obscure program or anything (and this is a default option) - surely it affected a lot of users?
Word of warning - the "Data" linking feature of Link2SD Pro still causes me problems, so I'd advise against using it with Kitkat.
Glad it has solved it for you too!
(2015-05-23, 22:52)davidg Wrote: [Only registered and activated users can see links Click here to register] Wrote:...
3.5. Mount namespaces
When SuperSU versions 1.50 and up run in daemon mode (Android 4.3+, and rare older Android OEM versions with SELinux set to enforcing), each process' su shell receives an isolated mount namespace. This means that mounts applied in one su shell may not be visible to other processes, except (most) other su shells started by the same parent process (your app). SuperSU in this case also tries to make the sdcards mounts and user-specific mounts available to the su shell, which hopefully makes your job easier.
One of the features of this mount namespace isolation is that it prevents apps from interfering with eachother's mounts so that race conditions between two apps trying to manipulate the same mount (switching /system between read-only and read-write repeatedly, for example) cannot occur, and all works as the app developer expects.
Android itself has offered similar mount namespace isolation for apps from version 4.2. SuperSU versions 1.93 and up support the --mount-master option which (if running in daemon mode) connects your app to a special su shell, which' mount commands are applied to all processes. If you need to 'publicly' apply a mount, use this option.
...
This is precisely what it going on, link2sd mounts it 2nd partition during the boot process, while later on the ui is supposed to use the link to the app located in that mount. As I stated earlier on, the link exists but isn't followed which is exactly as happens in the case of seperated namespaces.
(2015-05-23, 22:52)davidg Wrote: [ -> ]...
Have not got round to mailing the Link2SD guy yet - I will do though because a simple warning would have saved the likes of you and I months of
Its not as if SuperSU is an obscure program or anything (and this is a default option) - surely it affected a lot of users?
...
Exactly.
(2015-05-23, 22:52)davidg Wrote: [ -> ]...
Word of warning - the "Data" linking feature of Link2SD Pro still causes me problems, so I'd advise against using it with Kitkat.
...
I did use the data option but most probably with a relatively small app that has no real "own" data, I'll see if I can try a nice big app to test it.
Just completed a test with a dlna client using vlc, both apps located with data in the 2nd partition. No problems, working flawlessly. All other items where also linked.
I don't know when you created your mounting scripts, but maybe there could be your problem. I checked the link2sd history file and on two occasions there is a reference to linked data not working with the advice to recreate the mounting scripts.
Recreating them doesn't do any harm so maybe you should try it.
(2015-05-25, 00:42)mirandam Wrote: [ -> ]Just completed a test with a dlna client using vlc, both apps located with data in the 2nd partition. No problems, working flawlessly. All other items where also linked.
I don't know when you created your mounting scripts, but maybe there could be your problem. I checked the link2sd history file and on two occasions there is a reference to linked data not working with the advice to recreate the mounting scripts.
Recreating them doesn't do any harm so maybe you should try it.
Thanks. Tried that, before I recreated the mount scripts I would just get app crashes - now I get an I/O error. It wants to store the data in
/data/sdext2/data, but it doesn't exist and can't seem to create it, even though it has full access to
/data/sdext2/ and the rest of the app files get successfully moved there and linked to.
Thank you, i changed the SuperSU option as you suggested.
I created ext4 second partition and using link2sd i linked all apps to the "internal" and now it works (on leagoo lead 1 )