I don’t want car to sync all of my 3K+ contacts whereas I only need 3 max 5 of them in the car. I remember that this was possible with J1 years ago - I don’t remember how was this achieved then. I’d rather see car only works as a headphones than syncing all of my address book.
Now I have to unpair my phone every time I hand my car either to service, my family member or a friend.
Any idea how to achieve this?
I tried https://together.jolla.com/question/49163/prevent-contacts-sync-when-connecting-to-car-kit/, but doesn’t look to be working.
3 Likes
I performed extensive test with solution provided in link above. Contacts no longer get synced to car. But on a call car no longer shows who is calling and I can’t place a call from car menus.
So the solution is not really the right one. SFOS should ask for each pared device (and remember decision) what to do with contacts: full sync, sync only number+name, sync only favourites, no sync.
SFOS is about privacy and this feature would be a step in this direction. Without obex plugin car integration is practically unusable.
1 Like
I found this old link (N900 days!)
https://wiki.maemo.org/Bluetooth_PBAP
It talks about using irMC instead/additionally to Pbap.
perhaps doing
rm /etc/obexd/noplugins/irmc
touch /etc/obexd/noplugins/pbap
can improve things for you?
Thanks for the tip. But as far as I understand, root problem is not in how obexd provides information to car kit. One or another way if supported by both sides, all of contacts will be transferred to car kit. This is where I have a problem. Other mobile OSes (some, not all) have a way to limit or block entirely the transfer. This is OS feature/function not the BT stack. Generally it does not make any use to have 3K+ contacts stored at card persistent memory as I may use less than 10 for actually calling. We have to understand that these contacts may be extracted from car by 3rd person either through some port or even remotely…
What I’d like to see in some future SFOS version is to have some aspects around contacts database access re-engineered. In a nutshell SFOS contacts API should provide a plugin to authorize access/transfer of contacts DB data. It could filter some part of schema like notes, birthdays, pictures, addresses, phone number, etc or allow access to some entries and other not. It may require contacts schema extension to achieve full functionality - we can discuss engineering aspects if somebody is wiling to invest time. Alternatively, plugin may form own database and configuration pages to achieve the goal. This functionality may significantly aid to privacy capabilities of SFOS devices. Once API is there several implementation of filtering may surface each catering its specific user needs.
SFOS did implement jail schema to protect local programs data (and APIs). But to granularly protect contacts (and call, SMS, email) databases - not much for a long time. Only all-in or all-out torad AppSupport hosted apps.
Side story: I remember how disappointed I got when learned, that AppSupport supported android version of early Viber client, initially (really and totally) copied all of data from my J1 address-book to Viber cloud. I learned so when examined through PC based web interface offered by Viber 10 or so years ago. I fought for 6 month or so with my layer help to make 2k+ entries from my contacts db at least non-discoverable to other people using Viber. Horror.
Hope this helps putting some light on the problem I’m facing.
1 Like