Oh, yes also a good way, thanks.
Only downside is that one cannot save contacts anymore from within Android.
Out of that, it is probably the safest way regarding privacy.
But there must be a way to jump over the contacts export step.
I know the existance of strace or lsof…
Are there more appropriate tools I could play with, to try understanding the AAS start process?
Unfortunately, I rebooted and saw all my contacts in Android again. So, at the moment, the trick from first post seems not to survive reboot, hence is not useable.
I’m very sorry and disappointed, having to say this also is unperfect. When I link this file to /dev/null, some Android apps fail to start and crash. I tried ‘Contacts’ and ‘Telegram FOSS’ from f-droid.
I might have completely misunderstood this whole thread, but I don’t understand how you guys manage to get your contact data automatically imported to the android side. Because I don’t. My /home/.android/data folder is totally empty!
On the other hand, I do not use to many android apps (mostly banking apps) and I use android settings to deny access for unwanted apps.
Is there any reason you can’t do the same?
As I said, I might have misunderstood the whole thing.
Try again with root permissions
1 Like
@eson are you sure that’s /home/.android and not /home/defaultuser/android_storage? And whatever tool you used, does it have permission to look at /home/.android?
I think it’s mostly the scripts in /usr/libexec/appsupport/. Some of them generate other ad-hoc scripts, iirc. Sometimes they call each other.
The created config is mostly in /tmp/aliendalvik/appsupport iirc.
But a quick grep for “contact” or “database” shows up nothing.
One would have to go through all of them to figure out where they gather configuration and instructions from.
There are also appsupport-* utilities.
BTW there’s a possibility to fill in some extra config without editing the system files: create /usr/libexec/appsupport/alien-generate-extra-config.sh and put what you want done in it. See here.
2 Likes
Thanks! And there they are…
1 Like
I’ve been thinking about it one more round, and I must say I wasn’t aware that those files was not just hidden, but hidden hidden.
Still learning, apparently…
Yes, you are right. Normally, avoiding contacts access in AAS Settings should suffice.
But I seem to remember that some apps refused to work without contacts access.
Anyhow, it’s more for me a matter of principle and prudence (well, strong word, my db is not so sensible).
As there are regularly small scandals comming out about privacy abuses from the giants,
As my knowledge in a reliable way to veryfy those things is limited,
As Microg pretends some apps can missbehave without contact access (‘find accounts on the device’),
I concluded it would be simpler just not to export contacts from SFOS to AAS and in paralell allow contacts access where needed on the Android side.
By the way, happy new year, health and love in 2024 to all members and their families!j
1 Like
Many thanks for having elaborated,
Indeed, I had a look into some of these scripts and grepped all of them for ‘contacts’, ‘address’… too, but unfortunately found nothing.
I concluded that the impirtation was perhaps made by a binary that we cannot read.
Do you know of an utility that could monitor a file acesses? That way, it’d be possible to see who is accessing the contacts db…
strace -e file <command> will list file-related syscalls.
inotify-watch can wait for open/close/… and do something when detected.
Not sure how well they work with lxc and different namespaces though.
fanotify looks useful as well, and can be compliled easily on-device. From my brief test with this tool, it’s apkd-bridge who reads the contacts db.
(Note that I’m looking at AAS on a 4.4 system, things may be different on 4.5).
Now, apkd-bridge is run from a service, so maybe systemd sandboxing can be used to restrict file access to the contacts db. E.g. by using TemporaryFileSystem for the location of the contacts db so it is hidden by a tmpfs mount.
2 Likes
Tried both InaccessiblePaths and TemporaryFileSystem for the apkd-bridge service, didn’t work. Maybe because they are user services?
What does work is masking the service.
AAS will start, and the contacts db on the aas side will still be created.
But no contact info is in the new database.
(what is there is e.g. account info, and some entries regarding contact thumbnails. I suopose those are added by something else. )
No idea what will break by masking this, didn’t test thoroughly.
2 Likes
Have you tried simply stopping & disabling it?
I did now, will see how it goes.
FWIW,these are the commands:
systemctl --user stop apkd-bridge
systemctl --user disable apkd-bridge
# or
systemctl --user mask apkd-bridge
# check status
systemctl --user status apkd-bridge
1 Like
I wouldn’t downplay it. The fact that on Android many apps (and Google itself) have complete access to all my Contacts has always horrified me and is the single biggest reason I never used Whatsapp etc. on my daily driver. I mean this is real life data of the deepest kind both personal and professional. It’s nobody’s business xcept my own.
3 Likes
That’s lovely @nephros, many thanks for having been searching, trying and explaining.
It’s progressing, even perhaps solved.
I’m going to try simply disabling the service too, and report how it goes.
Thanks @ohnonot for giving the resulting command.
I would have been confused with the mask option.
Let’s try,
I tried to disable and/or mask apkd-bridge on my side (XA2 .24).
But, SFOS contacts are still copied in AAS.
It looks like something is reactivating the service.
@nephros, @ohnonot, are contacts really not exported anymore on your sides, even when checking after some time after launching AAS?
Masking should make it impossible to start that service. So maybe something else does the copying.
Sorry if it was already mentioned, but how can I launch android’s contacts app?
Sure, you can download it in f-droid. It’s called sth like ‘simple contacts’.