Multi-profiles / Work profile support #795
Comments
|
(note : I tried using Scoop for extra crash data, but Scoop does not seem to catch crashes on A13/LOS20). |
|
thanks for a complete report... currently, work profile isn't supported (yet). Maybe I contributed parts of that code. |
|
sorry, it seems like I accidentally closed the issue |
|
@hg42 Some feedback :
So, I guess it all boils down to this : |
|
well, I guess Antonios has some expertise with work profiles. Anyways, I never used work profiles and I don't know much about it, mostly that it's another user number. When I fix bugs, I may not always take work profiles into account (though not much of the code is influenced by it). I remember, I worked on the restore part of external data (also media and obb). As far as I remember, NB used a way to determine the permissions etc. from it's own external data. I changed that to use info from the app itself, I think from the apps data directory. |
|
that line in StorageFile is only used, when you have shadowRoot enabled (and the corresponding allow...). |
|
Access to the external data directory is another topic. I think, NB uses the path it gets from the PackageManager. |
Interesting : out of curiosity, I tested with both |
|
I am not an Android programmer, but the fact that NB correctly backups the data of a Work profile app (and hence has access to the data location(s)), suggests that restoration should be possible too ... |
|
this is the code where the crash happens: it first tries to get the permissions via the normal method. In this case info is gathered from the parent of the target directory (that is of the external data directory) and from the apps's data directory. NB does not decide which path to use, instead it uses the path it gets from the PackageManager. The method assumes, that if you have access to Can you try to access |
|
more exactly |
|
If I understand your request correctly, I think I already mentioned this in my original comment : |
|
Addendum (sorry for the spam) : |
|
(not with the package name...) however, if you do this in a terminal or adb it's not the same like in NB (it's user 10). |
|
the user number (0 or 10) is used to isolate those (phone) users (a different concept than linux users). |
|
two things might also play a role: which mount namespace setting do you have in Magisk? if changing one and/or the other makes it work, it might give a hint, wehere to search for a reason |
|
|
and you are really running NB from the work profile ? I would expect, that NB running in work profile only sees 10 in emulated and 0 is hidden instead. Could you test if that is the case with a terminal installed and running in the work profile? Maybe the root library (libsu and it's shell) does not run as user 10. |
; idem for the "extract" command. NB now backups and restores |
|
nice workaround :-) I always thought, one das the script will allow some tricks think Kostas also did something with it at some point...) |
|
however, I don't see substituting the path as a final solution. It's not a good thing to not use the data that Android gives us and instead assume something that is not guarantied anywhere. We already had such experiences, e.g. with shadowRoot or the external data. So, it's still a question why root access is not possible, or more why root commands seem to run in the normal profile. |
|
this is interesting... https://www.reddit.com/r/Magisk/comments/z0zp3q/help_how_to_get_root_access_in_work_profile/ I already thought that Magisk is the problem. Especially, because people want to hide root in another profile (e.g. for banking apps, or if it is managed by their employer). |
|
it basically points to this thread: stating that Magisk must be installed to the secondary user and Multiuser Mode must be User-independent |
|
Not sure about Magisk being the problem. In any case, as far as I understand |
|
please change it to "user independent" and try the ls commands again, especially if /storage/emulated then includes the 10. This might have more effects than getting the prompt or running root commands. Though, I wonder why it's not isolated. Is Magisk also installed in the work profile? Perhaps the nsenter we use to get the mount namespace working changes something. |
|
maybe we have to add some nsenter arguments currently it's lots of possibilities... that's available: I guess |
|
With Magisk Multiuser Mode set to "User Independent", and Magisk being installed in the Work profile too (required), starting NB in WP requests Superuser access, as expected. As this proves notto be the solution, I will revert my Magisk installation back to my preferred settings. |
|
I would think this kind of installation of Magisk is the correct one from a logical POV. Or in other words: Either Magisk and su is global (enabled somehow, but "only device owner" doesn't look like this), or Magisk and su is only active for the profile where it lives (but how? none of the Multiuser modes doesn't look like this, I would expect "user dependent"). |
|
at this moment I think the problem results from the nsenter command. Thinking backwards, we used it to make the Magisk setting for mount namespace irrelevant. we started with and I now wonder, why this should be different from the current
as far as I understand the help, this is only another method to say "use pid 1" in our case. It has more possibilities, e.g. taking network from another pid than mount. Or doesn't |
|
in toxbox source for nsenter we see: so either the filename is given or it is constructed from the -t argument. |
|
ok, the reasoning in #740 was:
it seems the -t 1 used 0 instead of 1, but why? maybe it is a bug in some Android toybox versions |
|
maybe adding |
A workaround like this could be implemented, but it's not a future-proof solution. Assumptions about such mount point relations are likely to fail in the long run. Some thoughts:
|
|
I still don't get, why backup seems to work and restore does not. If the directory is not visible, the backup should also fail or at least it should be empty.
that small size looks like an empty archive? Can you check if the backup contains real data? |
machiav3lli
changed the title
|
Just to add, my use case is to store backup from work profile to personal folder. Selecting a folder in work profile as the backup folder, the command Whereas, selecting a folder from main profile as the backup folder, the command shows The app can't access the user 10 folder anymore, so backups will fail. |
|
not sure what you want to say...
what is meant with anymore? compared to what? (e.g. the NB version where it worked), |
|
about #772 "Restoration of work profile backups fail silently, if the profile ids differ" e.g. backup user 11, but restore on 10 function: Below 8.3.7, the profile stored in the backup was used (from the properties file, the file/dir name should be irrelevant). visibility: the backup items now have a user attached (head icon + number), if it's not the current one So, #772 should indeed be completed. |
|
according to backups cross profile:
|
I'm sorry for the lack of details. NB Version: 8.3.8
It could be because NB can't see the folder I hope I made that clear, just to report an additional problem to this github issue. I found a workaround for this using magisk. |
This would be great too, but maybe make it advanced/experimental settings? |
|
just a quick note... the SAF provides the folder contents and file contents via it's own API. However, with shadowRoot NB tries to match the SAF folders to real files using root access (for this the ls command would matter). What you observe (user number seen being dependent on SAF folder selection) might be the system making the granted directory available. I actually do not understand why the system offers directories it cannot write to. I only had a work profile for a short time. I have nearly no experience how it should work. I remember, that the directory picker allowed to select directories that were not writable later. |
in my current implementation there is a pen symbol that allows editing the backup folder preference as text. The remaining problem is the handling on (first) startup. |
Description
NB crashes when attempting to restore External Data from a backed-up application.
Steps To Reproduce
WorkprofileExpected behavior
No crash
System Information(please complete the following information):
Additional Notes
The text was updated successfully, but these errors were encountered: