Drop support for app data sharing

chenxiaolong commented 8 years ago

This feature has never been reliable and has been the cause for many bugs, especially bootloops and non-writable/missing internal storage issues. The app data sharing feature works by proxying the connection between installd and the Android framework and hooking various installd commands. The interface, however, is not documented and varies wildly between Android versions and various OEM firmwares. As an example, TouchWiz and CyanogenMod (11.0) implement asynchronous commands (differently), while AOSP uses serial commands.

The various differences must be detected with 100% certainty as any incompatibilities that break installd will result in the boot process failing. I have been doing the bare minimum to keep this feature alive for the last few Android releases, but I no longer have the desire to maintain this feature for any newer Android version. As such, I will be removing the app data sharing feature.

Steps for removal:

[x] Migrate patches from appsync.cpp to init.cpp (eg. /data/.layout_version creation, /data/media SELinux label modification, and so on)
[x] Drop appsync.cpp, appsyncmanager.cpp
[x] Drop app sharing config options from romconfig.cpp
[x] Drop all appsync code and resources from the Android app

webmaster33 commented 8 years ago

I'm really sad because of removing app sharing :-( I planned to use it later, when other problems were fixed.

wazeeahmed commented 8 years ago

I tried to boot inside dirty unicorn today using switches and it went into a bootloop . There has to be a fix for that . And I think app data sharing is to be accused . So it'll be gone for good I think .

hankching commented 8 years ago

@chenxiaolong Pls write instructions how to move app data from app sharing to current app data location. (I hope you can understand what I said)

When will it be released?

chenxiaolong commented 8 years ago

@hankching The only way to move the app data is to make a backup with Titanium Backup and restore it after the feature is disabled/removed.

This will be released with 10.0.0. I will give at least 2 months notice, including a warning in the app, before this change happens.

hankching commented 8 years ago

Thanks your quick reply.

webmaster33 commented 8 years ago

@chenxiaolong: I hope, app sharing feature will be readded sometime later, when you will have more time for maintenaning it...

webmaster33 commented 7 years ago

Would be possible to simply make app data sharing simply by creating hard or soft links of app data directory?

webmaster33 commented 7 years ago

I had a question in my mind: Would be possible to simply make app data sharing simply by creating hard or soft links to the data directory of an app?

I made a few tests with symlinks. Created a symlink to the app data of Clipper app in primary rom. When I started Clipper, it crashed.

I looked into logcat and found, that the user/group id of the data dir & subdirectories of it has 10216 id (id of Clipper in primary rom) instead of 10019 (id of Clipper in current rom).

This is why Clipper gets permission denied when accessing the data dir.

One solution could be, that when changing rom, a boot script should change the ownership of the data directory & subdirectories & files to the id of app in current rom.

This means, that:

We need to retrieve the user/group id of each shared app in each rom. The ids can be retrieved from packages.xml file.
On each rom change we need to change user/group owner ids to target rom of each shared app. This can be done in the flashable dbp.zip, when the rom change is done. Also in mbtool, which handles the booting phase.

This way there would be possible to use app sharing with maximum compatibility.

One risk:

if the ownership is not restored for the target rom & shared apps, then the shared apps will be crashing in the booted rom. However if it is programmed correctly, I think this case will be not happen.

What do you think about the idea?

chenxiaolong commented 7 years ago

@webmaster33 You've exactly describe how the current code works, except that it also changes the SELinux label of the files and uses bind mounts instead of symlinks. That's actually the easiest part of app sharing.

The hard part is handling various operations related to the app, like updates, uninstallation, clearing cache or data, building dalvik-cache, etc. Those tasks are all handled by /system/bin/installd and mbtool intercepts the connection between installd and the Android framework to handle all these events. Many ROMs, most notably TouchWiz, will wipe the app data if it detects things out of the ordinary, like installd crashing, timeouts when mbtool is running it's app sharing tasks, or failures when changing the SELinux labels of the files. It's not impossible to make it perfect, but it takes too much time and frustration to debug when each new version of Android changes how installd works.

webmaster33 commented 7 years ago

Could not be possible to avoid using installd?

chenxiaolong commented 7 years ago

Unfortunately not. It's the only way to be able to unmount the shared data when uninstalling a shared app in one ROM.

webmaster33 commented 7 years ago

@chenxiaolong: 1) mount binding is less universal/compatible compared to soft/hard links, as I've readed

2) the links are supposed to be transparent to Android, so I suppose all os operations like updates, uninstalls should work without problem.

I can't imagine, why would be not the updates, uninstalls be transparent to OS, when using links.

I understand, that you are watching installd to catch uninstall event. But this could be also done by watching the packages.xml file for changes, and do unmount action only if our shared app id is missing from the file. Is it a crazy idea?

aligator commented 7 years ago

Wouldn't it be an option to create a backup of the Data when switching and load the backup on first start up after switching roms. (like Titanium but automatically when switching)

RekaKurniawan commented 7 years ago

This is my log, how to fix it?

03-18 07:44:09.087 12922 12922 E SharedPreferencesImpl: Couldn't create directory for SharedPreferences file /data/user/0/com.gbwhatsapp/shared_prefs/com.gbwhatsapp_preferences.xml

03-18 07:44:09.076 12922 12922 W com.gbwhatsapp: type=1400 audit(0.0:9351): avc: denied { search } for name="com.gbwhatsapp" dev="mmcblk0p46" ino=1523717 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_app_data_file:s0 tclass=dir permissive=0

03-18 07:44:09.087 12922 12922 W ContextImpl: Unable to create files subdir /data/user/0/com.gbwhatsapp/files

chenxiaolong / DualBootPatcher

Drop support for app data sharing #172