[android] Improve CFKnownLocations.

[drodriguez]

The usage of CFKnownLocations from Swift Foundation seems to be reduced
to both _kCFKnownLocationUserAny and _kCFKnownLocationUserCurrent. From
the public API of Swift Foundation there's no way to get to
_kCFKnownLocationUserByName. Supporting UserAny is, therefore,
necessary.

There are some ways of accessing _kCFKnownLocationUserByName from the CF
API, but it seems that the API only allows Current or Any, even if they
are not enforced. In any case, Android do not have Unix usernames, so
ByName doesn't make sense, and should be always the same as UserCurrent.

The change in code makes every code path fall back to the current user
(which should be also any user, and any user by name, because the
platforms limitations).

Additionally, instead of picking up a CFFIXEDUSE_HOME, request the home
directory from CFUtilities, since it deals with HOME, HOMEDIR and
CFFIXED_HOME appropiedly, since HOME is necessary for many other things.

The current code will have aborted the test suite, while the modified
code, passes the test suite for UserDefaults.

[compnerd]

I think that this should still abort. CFCopyHomeDirectoryURL will give you the current user's home directory.

[drodriguez]

Please, read the explanation in the commit message. There's no users in Android. The sandboxing only allows the app to write to their sandbox. Any User, Current User, and User By Name are effectively the same. The app should set a HOME (or CFFIXED_USER_HOME) to point at some point in their sandbox. There's no going to be preferences for “any user” beside the current user, so trying to choose different directories is not worth it.

Besides, the abort in the previous code was making the test suite abort, because the test suite uses Any (through UserPreferences), and it is not possible to avoid so.

[compnerd]

I did read the explanation, but that wasn't particularly clear from the commit message.

[drodriguez]

Do you want me to rewrite the commit message/PR description and resubmit? Or should I change something else?

We need at least Any and UserCurrent to work for the test suite to pass without Android-specific changes.

[compnerd]

This seems wrong for any user right? It is the current user's home directory.

[finagolfin]

I can confirm this fixes the test abort and gets the suite to finish again when natively compiling Foundation on Android.

[millenomi]

What is the test that is failing? In what way is this failing?

As I've noted several times: I'm not going to make an option mean something else without good reason. This applies to …Any and …UserByName as well.

[drodriguez]

TestUserDefaults was the one aborting. I don’t remember the exact test, but I think it was almost all of them. UserDefaults uses the code from CFApplicationPreferences. That code registers several domains for the app, some with the app name, some with AnyApp; some with CurrentUser, and some with AnyUser; and some with CurrentHost and AnyHost. Since the AnyUser is a fallback of CurrentUser, if a query wasn't finding the key for the CurrentUser, it was looking into AnyUser, which was aborting trying to find the path. I don’t know if that's a perfect description, but it is close to what was happening.

About making options mean something different, the point that I'm trying to make is that in a system with no user accounts (like Android), the meaning of “any user” and “current user” do not make sense, and at the same time, they mean the same. It is a mono-user OS, so the “current user” is “The User”, and “any user” can only be “The User”. I can remove the code for “by name”, since I don’t think it is hit (at least by the test suite) but I extended my concept of mono-user to “every named user” should be “The User”.

[millenomi]

We, however, inherit those concepts from Foundation needing to interop on all platforms. Note that iOS too has Any… and named users as API even if it's a single-user system.

Hmmm. Can we just fall back to the iOS behavior with the understanding that the home directory must be set with CFFIXED_USER_HOME?

[millenomi]

(The home directory function already returns it.)

[drodriguez]

I agree that we are not doing the same as iOS, which has been built with Foundation in mind, and have the right “holes” poked in the right places to allow sandboxed applications to work correctly with global preferences. However we don't have the same opportunity with Android. There's no global path for preferences in Android. The global preferences that one can read in Android have their physical representation hidden from apps, so there's no way we can simulate such thing (not even for read-only preferences, which I suppose are the only ones that work in iOS).

I completely understand the desire of making every enumeration to be the same meaning in every platform, but I also think that we should be pragmatic and adapt to each platform the best we can. Android doesn't have the concept of a global path for global preferences, but redirecting to an app local directory is the best we can do. Notice that even if iOS uses the concept of UserCurrent, the truth is that it is app local, not user local, like in macOS. One app cannot access the preferences of another app (and one need the concept of app containers to allow extensions to read the same preferences from even the same app).

About your question, the version I propose uses CFCopyHomeDirectoryURL which should do the right thing with CFFIXED_USER_HOME and HOME, while the existing version introduced its own code to deal with CFFIXED_USER_HOME, which I think duplicates efforts that should be de-duplicated. The only differences from the MACOS branch is that the Any case uses a Darwin-specific path, while Android tries to work around the fact that a global path will not be possible.

Personally I would prefer something that works, even if it doesn’t work the same as in other platforms, to something that doesn't work at all. Specially if the current implementation will simply abort for any usage of the UserDefaults.

[millenomi]

iOS doesn't really open holes. (It's a lot more complex than that — but the only thing that needs it is reading specific systemwide preferences, which aren't a thing that happens on Android.)

The problem with this patch is as much as that we are conflating a platform concept with the availability of symbols, and also that we are making every CurrentUser domain overlap with every Any domain overlap with any named user domain.

Here's a proposal that mirrors the way ByHost preferences work on Darwin:

• Any: Home + '/Apple/Library/Preferences/AnyUser'
• Current: Home + '/Apple/Library/Preferences'
• Named user: abort. (The issue is specifically with Any, right?)

[millenomi]

(In general, I want to sequester stuff under $HOME/Apple so that we do not pollute paths that can be assumed free for use by third-party code. I think that we should do so in FileManager as well, making the user domain rooted at $HOME/Apple rather than $HOME.)

[millenomi]

Proposal otherwise:

Named user: Home + '/Apple/Library/Preferences/ByUser/$USERNAME'

[drodriguez]

I was about to change this to have support for Any and Current and remove support the named users. I think the named users are not really used in the code (I think it is impossible to hit those code paths from Foundation).

I will explore the usage of different folders for Any and Current (and for the named users).

[drodriguez]

Changed the paths to include the /Apple prefix and the AnyUser and ByUser for the cases they make sense. TestUserDefaults pass on Android and doesn't abort.

@swift-ci please test Linux platform

[drodriguez]

Failures in LLDB are unrelated.

@swift-ci please test Linux platform

[millenomi]

Thank you!