Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #154381 > unrolled thread

contacts

Back to article view | Back to comp.mobile.android

Contents

  contacts "Carlos E. R." <robin_listas@es.invalid> - 2026-07-09 18:33 +0200
    Re: contacts Theo <theom+news@chiark.greenend.org.uk> - 2026-07-09 18:02 +0100
      Re: contacts "Carlos E. R." <robin_listas@es.invalid> - 2026-07-09 20:08 +0200
        Re: contacts Theo <theom+news@chiark.greenend.org.uk> - 2026-07-10 11:26 +0100
          Re: contacts "Carlos E. R." <robin_listas@es.invalid> - 2026-07-10 12:49 +0200
          Re: contacts Jörg Lorenz <hugybear@gmx.net> - 2026-07-10 15:30 +0200
    Re: contacts Jörg Lorenz <hugybear@gmx.net> - 2026-07-09 19:26 +0200
      Re: contacts Jörg Lorenz <hugybear@gmx.net> - 2026-07-09 19:30 +0200
        Re: contacts "Carlos E. R." <robin_listas@es.invalid> - 2026-07-09 20:10 +0200
          Re: contacts Jörg Lorenz <hugybear@gmx.net> - 2026-07-09 22:21 +0200
            Re: contacts "Carlos E. R." <robin_listas@es.invalid> - 2026-07-10 12:50 +0200
              Re: contacts Jörg Lorenz <hugybear@gmx.net> - 2026-07-10 15:32 +0200
          Re: contacts Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-11 08:50 +0100
            Re: contacts "Carlos E. R." <robin_listas@es.invalid> - 2026-07-11 12:25 +0200
              Re: contacts Jörg Lorenz <hugybear@gmx.net> - 2026-07-12 09:59 +0200
            Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-12 19:31 -0400
              Re: contacts Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-14 17:33 +0100
                Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-14 13:25 -0400
                  Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-14 17:01 -0400
        Re: contacts Arno Welzel <usenet@arnowelzel.de> - 2026-07-10 13:18 +0200
          Re: contacts Frank Slootweg <this@ddress.is.invalid> - 2026-07-10 13:38 +0000
            Re: contacts Arno Welzel <usenet@arnowelzel.de> - 2026-07-10 16:49 +0200
              Re: contacts Theo <theom+news@chiark.greenend.org.uk> - 2026-07-10 18:32 +0100
                Re: contacts Frank Slootweg <this@ddress.is.invalid> - 2026-07-10 18:05 +0000
                Re: contacts Dave Royal <dave@dave123royal.com> - 2026-07-10 19:12 +0100
                  Re: contacts Theo <theom+news@chiark.greenend.org.uk> - 2026-07-11 18:37 +0100
                Re: contacts Arno Welzel <usenet@arnowelzel.de> - 2026-07-12 11:58 +0200
                  Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-12 19:36 -0400
                    Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-12 19:44 -0400
      Re: contacts Arno Welzel <usenet@arnowelzel.de> - 2026-07-10 13:16 +0200
    Re: contacts "s|b" <me@privacy.invalid> - 2026-07-09 22:17 +0200
      Re: contacts Jörg Lorenz <hugybear@gmx.net> - 2026-07-09 22:22 +0200
        Re: contacts "s|b" <me@privacy.invalid> - 2026-07-10 11:12 +0200
          Re: contacts Jörg Lorenz <hugybear@gmx.net> - 2026-07-10 11:33 +0200
            Re: contacts Arno Welzel <usenet@arnowelzel.de> - 2026-07-10 13:22 +0200
              Re: contacts "s|b" <me@privacy.invalid> - 2026-07-10 17:53 +0200
        Re: contacts Arno Welzel <usenet@arnowelzel.de> - 2026-07-10 13:20 +0200
          Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-12 00:03 -0400
            Re: contacts ram@zedat.fu-berlin.de (Stefan Ram) - 2026-07-12 07:42 +0000
              Re: contacts Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-12 09:44 +0100
                Re: contacts "Carlos E. R." <robin_listas@es.invalid> - 2026-07-12 13:49 +0200
                  Re: contacts AJL <noemail@none.com> - 2026-07-12 16:18 +0000
                    Re: contacts "Carlos E. R." <robin_listas@es.invalid> - 2026-07-12 22:11 +0200
                      Re: contacts AJL <noemail@none.com> - 2026-07-12 21:31 +0000
                        Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-12 21:05 -0400
                          Re: contacts AJL <noemail@none.com> - 2026-07-13 01:52 +0000
                            Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-13 02:26 -0400
                              Re: contacts AJL <noemail@none.com> - 2026-07-13 16:50 +0000
                                Re: contacts Frank Slootweg <this@ddress.is.invalid> - 2026-07-13 20:04 +0000
                                  Re: contacts AJL <noemail@none.com> - 2026-07-13 21:17 +0000
                            Re: contacts Theo <theom+news@chiark.greenend.org.uk> - 2026-07-13 17:00 +0100
                              Re: contacts AJL <noemail@none.com> - 2026-07-13 17:00 +0000
                                Re: contacts Theo <theom+news@chiark.greenend.org.uk> - 2026-07-13 18:10 +0100
                                  Re: contacts AJL <noemail@none.com> - 2026-07-13 17:48 +0000
                        Re: contacts Frank Slootweg <this@ddress.is.invalid> - 2026-07-13 19:57 +0000
                          Re: contacts Theo <theom+news@chiark.greenend.org.uk> - 2026-07-14 12:45 +0100
                            Re: contacts Frank Slootweg <this@ddress.is.invalid> - 2026-07-14 14:07 +0000
                              Re: contacts Theo <theom+news@chiark.greenend.org.uk> - 2026-07-14 15:28 +0100
                                Re: contacts Frank Slootweg <this@ddress.is.invalid> - 2026-07-14 15:45 +0000
                          Re: contacts Arno Welzel <usenet@arnowelzel.de> - 2026-07-14 16:06 +0200
              Re: contacts Arno Welzel <usenet@arnowelzel.de> - 2026-07-12 12:04 +0200
            Re: contacts Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-12 09:53 +0100
            Re: contacts Arno Welzel <usenet@arnowelzel.de> - 2026-07-12 12:01 +0200
        Re: contacts AJL <noemail@none.com> - 2026-07-10 16:10 +0000
          Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-12 00:03 -0400
    Re: contacts Maria Sophia <mariasophia@comprehension.com> - 2026-07-11 23:53 -0400

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#154403

Arno Welzel <usenet@arnowelzel.de> wrote:
[...]

> The problem is, that Samsungs *custom* Android version cripples the
> official APIs, so that only Samsung Apps work as expected. Blame Samsung
> for that, not Android.

  I don't think there's anything wrong with the Samsung 'Contacts' app
(actually part of the 'Phone' app).

  For example the Contacts app handles WhatsApp contacts just fine. I
think it's very unlikely that the Contacts app is special-coded for
WhatsApp or vice versa, so if the Contacts app works with WhatsApp, I
don't see wwhy it wouldn't work with K-9 Mail / 'Thunderbird'.

  Having said that, it seems that Samsung is slowly moving to Google
apps instead of their own. For example the Messages app is now Google
Messages.

[toc] | [prev] | [next] | [standalone]

#154404

Frank Slootweg, 2026-07-10 15:38:

> Arno Welzel <usenet@arnowelzel.de> wrote:
> [...]
> 
>> The problem is, that Samsungs *custom* Android version cripples the
>> official APIs, so that only Samsung Apps work as expected. Blame Samsung
>> for that, not Android.
> 
>   I don't think there's anything wrong with the Samsung 'Contacts' app
> (actually part of the 'Phone' app).
> 
>   For example the Contacts app handles WhatsApp contacts just fine. I

Well - Samsung and Meta are both big companies. They will have some
agreement to get thinks working.

> think it's very unlikely that the Contacts app is special-coded for
> WhatsApp or vice versa, so if the Contacts app works with WhatsApp, I
> don't see wwhy it wouldn't work with K-9 Mail / 'Thunderbird'.

Because K-9 / Thunderbird is free software and even the Mozilla
Foundation is just a small player compared to Samsung and Meta.

>   Having said that, it seems that Samsung is slowly moving to Google
> apps instead of their own. For example the Messages app is now Google
> Messages.

Yes, because they don't want to develop and maintain their own messages
app to support RCS and propably Google also demands using this app, if
Samsung wants to get an official license for Google Play Services and
device certification.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#154407

Arno Welzel <usenet@arnowelzel.de> wrote:
> Frank Slootweg, 2026-07-10 15:38:
> 
> > Arno Welzel <usenet@arnowelzel.de> wrote:
> > [...]
> > 
> >> The problem is, that Samsungs *custom* Android version cripples the
> >> official APIs, so that only Samsung Apps work as expected. Blame Samsung
> >> for that, not Android.
> > 
> >   I don't think there's anything wrong with the Samsung 'Contacts' app
> > (actually part of the 'Phone' app).
> > 
> >   For example the Contacts app handles WhatsApp contacts just fine. I
> 
> Well - Samsung and Meta are both big companies. They will have some
> agreement to get thinks working.

Or perhaps the Samsung app uses the standard Android contacts system? 
That's how it's done on every Samsung I've had (admittedly the most recent
one - which I still use - was released 2014).

Samsung haven't done a deal with every single app provider that uses
contacts.  Apps which use contacts work normally on Samsung phones.

> > think it's very unlikely that the Contacts app is special-coded for
> > WhatsApp or vice versa, so if the Contacts app works with WhatsApp, I
> > don't see wwhy it wouldn't work with K-9 Mail / 'Thunderbird'.
> 
> Because K-9 / Thunderbird is free software and even the Mozilla
> Foundation is just a small player compared to Samsung and Meta.

K-9 uses the standard Android contacts system too.

But the standard contacts system won't sync with anything.  You need an
additional app for that, eg Google's app to sync with Google's contacts.

> >   Having said that, it seems that Samsung is slowly moving to Google
> > apps instead of their own. For example the Messages app is now Google
> > Messages.
> 
> Yes, because they don't want to develop and maintain their own messages
> app to support RCS and propably Google also demands using this app, if
> Samsung wants to get an official license for Google Play Services and
> device certification.

I think it's because they don't want to get involved with supporting RCS
across all carriers/countries/etc and would rather leave that too Google. 
They can't rely on standard Android (AOSP) functionality for RCS as they can
with SMS - Google's RCS is all locked up in their app.

There's nothing to stop them shipping Samsung Messages as well as Google
Messages, just like they do with the other apps.  Only that it would be
confusing for SMS to go the Samsung app and RCS to go to the Google app.  So
it's easier for them to just retire Samsung Messages.

[One reaosn for this dual-app strategy is that it allows them to sell phones
in markets which Google doesn't support, or where Google is banned.  I think
Google's reach has expanded such that there are few non-Google countries
now, even if some features are limited to fewer markets]

Theo

[toc] | [prev] | [next] | [standalone]

#154408

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Arno Welzel <usenet@arnowelzel.de> wrote:
> > Frank Slootweg, 2026-07-10 15:38:
> > 
> > > Arno Welzel <usenet@arnowelzel.de> wrote:
> > > [...]
> > > 
> > >> The problem is, that Samsungs *custom* Android version cripples the
> > >> official APIs, so that only Samsung Apps work as expected. Blame Samsung
> > >> for that, not Android.
> > > 
> > >   I don't think there's anything wrong with the Samsung 'Contacts' app
> > > (actually part of the 'Phone' app).
> > > 
> > >   For example the Contacts app handles WhatsApp contacts just fine. I
> > 
> > Well - Samsung and Meta are both big companies. They will have some
> > agreement to get thinks working.

[To Arno:]

  Well this Contacts <--> WhatsApp functionality already worked on old
non-Samsung phones (Huawei (with Android 4/5) in my case)) and before
Meta acquired WhatsApp, so it doesn't have anything to do with Samsung,
nor with Meta, just with standard contacts functionality.

> Or perhaps the Samsung app uses the standard Android contacts system? 
> That's how it's done on every Samsung I've had (admittedly the most recent
> one - which I still use - was released 2014).
> 
> Samsung haven't done a deal with every single app provider that uses
> contacts.  Apps which use contacts work normally on Samsung phones.

  Exactly! They would have to do that for every IM app, every email app,
etc., etc., ad infinitum.

[...]

[toc] | [prev] | [next] | [standalone]

#154409

Theo <theom+news@chiark.greenend.org.uk> Wrote in message:
> 
> But the standard contacts system won't sync with anything.  You need an
> additional app for that, eg Google's app to sync with Google's contacts.

On this Samsung tablet, Android 13, I use K9 and the default
 Contacts app plus CardDAV-sync free, which syncs to my contacts
 on NextCloud, which is also sync'd to my iPhone.

As mentioned, K9 - and presumably TB on Android - does not
 automatically collect addresses you type in.
-- 
Remove numerics from my email address.

[toc] | [prev] | [next] | [standalone]

#154414

Dave Royal <dave@dave123royal.com> wrote:
> Theo <theom+news@chiark.greenend.org.uk> Wrote in message:
> > 
> > But the standard contacts system won't sync with anything.  You need an
> > additional app for that, eg Google's app to sync with Google's contacts.
> 
> On this Samsung tablet, Android 13, I use K9 and the default
>  Contacts app plus CardDAV-sync free, which syncs to my contacts
>  on NextCloud, which is also sync'd to my iPhone.

Indeed. I think there is a actually a way you can access Google contacts via
CardDAV without needing their app - you generate a special link that you can
give to a CardDAV sync app.  I do that for Google calendars using CalDAV.

The way these sync apps work is they create a separate contacts or calendar
database on the phone, so you can tell what's a synced contact and what's a
local one.  You can use them separately without having to merge them with
your local database.

> As mentioned, K9 - and presumably TB on Android - does not
>  automatically collect addresses you type in.

I find the lack of contacts feature less annoying because email addresses
are actually remembered by my keyboard.  eg if I start typing 'bob@' then
the autocorrect offers 'bob@example.com' as a completion.  So as long as I
know the first part of the email then I'm ok.  If my contacts were things
like 45949587@qq.com then that might be more annoying, but that's not a
problem I have.

Theo

[toc] | [prev] | [next] | [standalone]

#154423

Theo, 2026-07-10 19:32:

> Arno Welzel <usenet@arnowelzel.de> wrote:
>> Frank Slootweg, 2026-07-10 15:38:
>>
>>> Arno Welzel <usenet@arnowelzel.de> wrote:
>>> [...]
>>>
>>>> The problem is, that Samsungs *custom* Android version cripples the
>>>> official APIs, so that only Samsung Apps work as expected. Blame Samsung
>>>> for that, not Android.
>>>
>>>   I don't think there's anything wrong with the Samsung 'Contacts' app
>>> (actually part of the 'Phone' app).
>>>
>>>   For example the Contacts app handles WhatsApp contacts just fine. I
>>
>> Well - Samsung and Meta are both big companies. They will have some
>> agreement to get thinks working.
> 
> Or perhaps the Samsung app uses the standard Android contacts system? 

If this is the case, the K-9 should work fine, because it also uses the
standard Android contacts system.

> That's how it's done on every Samsung I've had (admittedly the most recent
> one - which I still use - was released 2014).

Then the original post must be an error:

"And if you want Thunderbird (K-9?) to use contacts, you have to install
the google contacts app to provide the API."



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#154433

Arno Welzel wrote:
>> Or perhaps the Samsung app uses the standard Android contacts system? 
> 
> If this is the case, the K-9 should work fine, because it also uses the
> standard Android contacts system.
> 
>> That's how it's done on every Samsung I've had (admittedly the most recent
>> one - which I still use - was released 2014).
> 
> Then the original post must be an error:
> 
> "And if you want Thunderbird (K-9?) to use contacts, you have to install
> the google contacts app to provide the API."

In another post in this thread I explained what contacts provider Samsung 
uses, although I will state that I own a Samsung which drives me nuts when 
coding scripts because Samsung adds and changes much of the AOSP layer.

As just an example frustrating me at this very moment, look at the comments 
in the versions of the script below just from today's testing & debugging!

Note I have NOT cleaned up the comments yet, where the funny thing is when
they're cleaned up, all the frustration gets lost in the cleanup process. :)

  :: adbdebugtls.bat (Android 12+ ADB/TLS Diagnostic Tool)
  ::
  :: Runs a full diagnostic of ADB-over-TLS, TCP/IP mode, adbd state, 
  :: Wireless Debugging state, and scrcpy readiness for Android 12+.
  @echo off
  setlocal enabledelayedexpansion
  
  :: Version string
  set SCRIPT_VERSION=v2p0
  set SCRIPT_DATE=20260712
  
  echo ============================================
  echo Running adbdebugtls.bat %SCRIPT_VERSION% %SCRIPT_DATE%
  echo .
  echo ADB Debug Tool Android 12+ TLS Diagnostic
  echo Tested only on Samsung A32-5G Android 13 
  echo Some commands are specific to Samsung phones
  echo .
  echo ============================================
  echo.
  ::
  :: v2p0 20260712 
  ::  Added both systems for screen detection because when the screen is OFF, 
  ::  the TLS advertiser often goes to sleep, but when TLS goes to sleep,
  ::  _adb-tls-connect._tcp stops broadcasting, and the PC cannot auto-discover 
  ::  the phone, such that TLS auto-connect fails and adb mdns services shows 
  ::  nothing and adb connect fails unless TCP/IP 5555 is already active
  ::  This is not true for classic TCP/IP 5555, but it is true for Android 
  ::  12+ TLS mode (which we need to connect without knowing port assignments).
  :: v1p9 20260712 
  ::  I would never have tried to add this had I known how complex it is.
  ::  The screen state matters because TLS depends on the screen being awake.
  ::  But not only does my A32-5G have two systems for screen state, but
  ::  Android 13 screen/wake state is completely different from Android 12.
  ::  Android 13 uses a numeric system which is a permutaion combination of:
  ::   mWakefulness=awake, asleep, dozing, dreaming
  ::    adb shell dumpsys power | findstr /I "mWakefulness="
  ::   mHalInteractiveModeEnabled=true/false
  ::    adb shell dumpsys power | findstr /I "mHalInteractiveModeEnabled="
  ::   mHoldingDisplaySuspendBlocker=true/false
  ::   mHoldingWakeLockSuspendBlocker=true/false
  ::  Added Samsung-specific screen-status bitmask decoder because
  ::  Samsung complicated the simple 0/1 AOSP on/off screen status to
  ::  0   Screen OFF (fully off, not dim, not waking)
  ::  1   Screen ON (bright or dim)
  ::  2   Screen waking / brightening / transition
  ::  4   Screen locked
  ::  6   Screen OFF but locked, device idle (actually 2+4)
  ::  7   Screen ON but locked (actually 1+2+4)
  ::  8   Screen dim
  ::  16  Always-on display (AOD)
  ::  31  Screen ON + waking + locked + dim + AOD active (1+2+4+8+16)
  ::  32  Proximity sensor active
  ::  64  Brightness override
  ::  128 Dream / doze
  ::  256 Interactive
  ::  etc.
  ::  for /f "tokens=4" %N in ('adb shell dumpsys power ^| findstr /I /C:"screen on profiler"') do @set SCREEN_NUM=%N & @echo SCREEN_NUM=%SCREEN_NUM%
  :: SCREEN_NUM=21
  :: adb shell dumpsys power | findstr /I /C:"screen on profiler"
  :: screen on profiler: 31
  :: The string enums (SCREEN_STATE_ON, SCREEN_STATE_OFF) come from 
  :: WindowManager (dumpsys window).
  :: The numeric values (like 21, 7, 6, etc.) come from Samsung's 
  :: vendor-extended PowerManager  via dumpsys power  specifically from the 
  :: line containing: screen on profiler
  :: This is a Samsung-specific diagnostic hook.	 
  ::
  ::  But "dumpsys power" does not output screen-state flags anymore.
  ::  It's "dumpsys window" which works on Android 13 Samsung models.
  ::  Samsung also uses the AOSP string enums system for screen state
  ::   adb shell dumpsys window | findstr /I "screen"
  ::   adb shell dumpsys window | findstr /I "screenState"
  ::    screenState=SCREEN_STATE_OFF
  ::    screenState=SCREEN_STATE_ON
  ::  Samsung also uses a vendor-specific bitmask on my A32-5G
  ::   adb shell dumpsys power | findstr /I /C:"screen on profiler"
  ::    screen on profiler: 31
  :: v1p8 20260712 
  ::  I would never have tried to add this had I known how complex it is.
  ::  Added screen status check because wireless debugging pairing is UI-driven.
  ::  ADB itself doesn't need the screen; it's the TLS pairing that needs it.
  ::  Wireless Debugging pairing requires the screen to be ON.
  ::  Samsung suspends mdns advertiser when the screen is OFF.
  ::   For an AOSP Android, check with:
  ::     adb shell dumpsys power | findstr "Display Power"
  ::  But Samsung uses different switches and these are only two of them:
  ::    screen on profiler: 1   screen ON (whether bright or dimmed)
  ::    screen on profiler: 0   screen OFF
  :: Here's how to control the phone screen from ADB (Samsung-specific)
  :: Turn screen OFF (simulate power button)
  :: Note: On Samsung phones, this may not fully turn the screen off
  ::       if the phone is charging or has wake-locks active.
  :: adb shell input keyevent 26 (toggles the screen on or off)
  ::
  :: Turn screen ON (wake the device)
  :: adb shell input keyevent 224
  ::
  :: Force screen ON (MENU key, wakes most devices)
  ::  adb shell input keyevent 82
  ::
  :: Check screen state (Samsung A32-5G)
  ::  Values:
  ::   screen on profiler: 1   = screen ON (bright or dim)
  ::   screen on profiler: 2   = waking / brightening / transition
  ::   screen on profiler: 0   = screen OFF
  ::  adb shell dumpsys power | findstr /I /C:"screen on profiler"
  :: How to control the phone screen from ADB (Samsung A32-5G)
  ::  Turn screen OFF (simulate power button)
  ::  Note: On Samsung phones, this may NOT fully turn the screen off
  ::        if the phone is charging or has wake-locks active.
  ::        adb shell input keyevent 26
  :: Turn screen ON (wake the device)
  ::       adb shell input keyevent 224
  :: Force screen ON (MENU key, wakes most devices)
  ::       adb shell input keyevent 82
  :: Check screen state (Samsung-specific)
  ::  Values:
  ::   screen on profiler: 0   = screen OFF
  ::   screen on profiler: 1   = screen ON (bright or dim)
  ::   screen on profiler: 2   = waking / brightening / transition
  ::       adb shell dumpsys power | findstr /I /C:"screen on profiler"
  :: v1p7 20260712 
  ::  Added battery-saver check because the battery saver kills mdns.
  ::   Samsung aggressively kills the TLS advertiser when Battery Saver is ON.
  ::   This causes:
  ::     a. mdns advertiser to sleep
  ::     b. TLS pairing to fail
  ::     c. TCP/IP port 5555 to refuse connections
  ::     d. adbd to become unreachable
  ::   Check with:
  ::     adb shell settings get global low_power
  ::       1 = Battery Saver ON (TLS will fail)
  ::       0 = Battery Saver OFF (TLS can work)
  ::   If Battery Saver is ON, disable it and toggle Wireless debugging.
  ::       adb shell settings put global low_power 0
  ::
  :: v1p6 20260630
  ::  When in deep sleep, a reboot and wireless debugging toggle isn't enough.
  ::  Either we have to authenticate over USB or over Android 11 pairing so
  ::  this version will tell the user what they need to do so as to pair.
  ::
  :: v1p5 20260629
  ::  Added hard deep-sleep check & warning that the phone must be rebooted
  ::  as just toggling Wireless debugging will not wake from hard deep sleep
  ::  Note that we might have to reboot and pair using Android 11 methods.
  ::
  :: v1p4 20260628
  ::   Show TLS recovery suggestions whenever TLS advertiser is ASLEEP
  ::   Added Android 11 pairing-mode instructions (adb pair / adb connect)
  ::   Added Android 12+ Wireless Debugging toggle instructions
  ::   Kept USB fallback instructions for classic TCP/IP mode
  ::
  :: v1p3 20260627
  ::   Added recovery suggestions 
  ::   such as toggle Wireless Debugging, USB fallback, reboot
  ::
  :: v1p2 20260626
  ::   Added TLS-only mode detection
  ::   Added TCP/IP mode detection
  ::   Added USB fallback detection
  ::   Added ADB Deep Sleep Summary block
  ::   Added auto-suggestions inside summary (v1p2)
  ::  
  :: v1p1 20260625
  ::   Added script version and date output
  ::   The TLS advertiser, adbd and the Wireless Debugging service enter
  ::   a deep sleep sate when the phone has been idle for a long time.
  ::   Added comments to explain the debug results when that happens.
  ::
  :: v1p0 20260620
  ::   Diagnose the state of Android's ADB daemon on Android 12+ devices,
  ::   including TLS advertiser status, TCP/IP mode, adbd internal state,
  ::   Wireless Debugging service state and scrcpy readiness.
  ::
  ::   Android 12+ introduced ADB-over-TLS Auto-Discovery, which broadcasts
  ::   on the LAN using mDNS as:
  ::       _adb-tls-connect._tcp
  ::   The desktop ADB server auto-connects to this TLS service as:
  ::       adb-SERIAL._adb-tls-connect._tcp
  ::   This TLS system:
  ::     a. bypasses pairing
  ::     b. bypasses USB authorization
  ::     c. bypasses debug ports
  ::     d. auto-connects whenever ADB restarts
  ::   But scrcpy cannot use TLS directly. It only supports:
  ::     a. USB
  ::     b. Classic TCP/IP ADB (port 5555)
  ::   Hence, this script checks:
  ::     1. TLS advertiser status (adb mdns services)
  ::     2. TCP/IP connectivity on port 5555
  ::     3. adbd internal state via getprop
  ::     4. Wireless Debugging service state via dumpsys
  ::        Note Samsung may hide or rename the Wireless Debugging service.
  ::     5. scrcpy readiness (device state)
  ::   Note the wake attempts when the phone TLS service goes asleep.
  ::     i. Restarting the PC ADB server
  ::     ii. Restarting adbd on the phone (if reachable)
  ::     iii. Forcing TCP/IP fallback on port 5555
  ::   Note Android does not expose a command to toggle Wireless Debugging.
  ::   So the TLS advertiser cannot be automaticaly awakened from ADB.
  ::   Hence, this script reports TLS sleep but cannot force it awake.
  :: 
  :: Set your phone IP here
  set PHONE_IP=192.168.1.4
  
  :: Begin 1 
  echo.
  echo === Restart adb server and check battery-saver and screen status ===
  echo     === Restart PC adb server ===
  echo adb kill-server
  adb kill-server
  echo adb start-server
  adb start-server
  echo.
  
  echo.
  echo     === Check phone battery-saver status ===
  echo Command: adb shell settings get global low_power
  
  set LOW_POWER=
  for /f "tokens=*" %%A in ('adb shell settings get global low_power') do set LOW_POWER=%%A
  
  if "%LOW_POWER%"=="" (
      echo Battery Saver status unavailable. Phone not reachable yet.
  ) else if "%LOW_POWER%"=="1" (
      echo Battery Saver is ON.
      echo This will cause TLS advertiser sleep and TCPIP refusal.
      echo Disable Battery Saver on the phone and toggle Wireless debugging.
  ) else (
      echo Battery Saver is OFF.
      echo Keep Battery Saver off on the phone and toggle Wireless debugging.
  )
  echo.
  
  
  :: echo.
  :: echo     === Check phone screen-status (before TCP/IP mode detection) ===
  :: echo Command: adb shell dumpsys power ^| findstr /I "mScreenOn"
  :: 
  :: set SCREEN_STATE=
  :: for /f "tokens=*" %%A in ('adb shell dumpsys power ^| findstr /I "mScreenOn"') do set SCREEN_STATE=%%A
  :: 
  :: if "%SCREEN_STATE%"=="" (
      :: echo Screen state unavailable. Phone not reachable yet.
  :: ) else (
      :: echo Screen state line:
      :: echo %SCREEN_STATE%
  :: )
  :: 
  :: echo.
  
  
  :: End 1 
  
  :: Begin 2 
  echo.
  echo === 2. TLS Status mDNS Advertiser ===
  echo Command: adb mdns services
  adb mdns services | findstr /I "_adb-tls-connect._tcp"
  
  if errorlevel 1 (
      echo TLS advertiser is ASLEEP.
      echo.
      echo Meaning:
      echo  The phone is NOT broadcasting _adb-tls-connect._tcp
      echo  The Wireless Debugging mDNS service is OFF or in deep sleep
      echo  ADB-over-TLS cannot auto-discover the device
      echo  The PC cannot wake the phone via TLS
      echo.
      echo Why this happens:
      echo  Phone idle for long periods
      echo  Wi-Fi reconnected or changed access points
      echo  Wireless Debugging has not been toggled recently
      echo.
      echo Result:
      echo  TLS mode is unavailable
      echo  Only USB or manual Wireless Debugging toggle can wake adbd
  ) else (
      echo TLS advertiser is ACTIVE.
      echo The phone is broadcasting _adb-tls-connect._tcp.
  )
  
  echo.
  
  :: TLS-only mode detection
  :: This sets %TLS_STATE% for later summary logic
  if errorlevel 1 (
      set TLS_STATE=ASLEEP
  ) else (
      set TLS_STATE=ACTIVE
  )
  
  :: End 2
  
  :: Begin 3
  echo.
  echo === 3. TCP/IP Status Port 5555 ===
  echo Command: adb connect %PHONE_IP%:5555
  adb connect %PHONE_IP%:5555
  
  if errorlevel 1 (
      echo.
      echo TCP/IP mode is OFF.
      echo Port 5555 is CLOSED on the phone.
      echo.
      echo Meaning:
      echo  Classic ADB-over-TCP is disabled
      echo  scrcpy cannot connect over Wi-Fi
      echo  The phone is in TLS-only Wireless Debugging mode
      echo.
      echo Why this happens:
      echo  Android 12+ disables TCP/IP mode automatically
      echo  Happens post reboot, Wi-Fi changes, or long idle periods
      echo  Happens when Wireless Debugging is ON but not paired recently
      echo.
      echo Result:
      echo  adb connect fails with "actively refused 10061"
      echo  Only USB can re-enable TCP/IP mode via "adb tcpip 5555"
  ) else (
      echo TCP/IP mode is ACTIVE on port 5555.
      echo Classic ADB-over-TCP is available.
  )
  
  echo.
  
  echo Command: adb devices
  adb devices
  echo.
  
  :: TCP/IP mode detection
  if errorlevel 1 (
      set TCPIP_STATE=OFF
  ) else (
      set TCPIP_STATE=ON
  )
  
  echo.
  echo     === Check phone screen-status (after TCP/IP mode detection) ===
  echo (1) Command: adb shell dumpsys power ^| findstr /I /C:"screen on profiler"
  
  set SCREEN_STATE=
  echo (3) about to set the screen state
  for /f "tokens=*" %%A in ('adb shell dumpsys power ^| findstr /I /C:"screen on profiler"') do (
      set SCREEN_STATE=%%A
  )
  
  if "%SCREEN_STATE%"=="" (
      echo Screen state unavailable. Phone not reachable yet.
  ) else (
      echo Screen state line:
      echo %SCREEN_STATE%
  )
  
  :: Extract numeric value from screen-state token 4
  :: Token#1=screen,#2=on,#3=profiler,#4=<number>,#5=empty
  set SCREEN_NUM=
  for /f "tokens=4" %%N in ("%SCREEN_STATE%") do set SCREEN_NUM=%%N
  
  echo Numeric screen state: %SCREEN_NUM%
  
  :: Reset flags
  set FLAG_ON=
  set FLAG_WAKING=
  set FLAG_LOCKED=
  set FLAG_DIM=
  set FLAG_AOD=
  set FLAG_PROX=
  set FLAG_BRIGHT=
  set FLAG_DOZE=
  set FLAG_INTERACTIVE=
  
  :: Decode bitmask
  set /a TEMP=%SCREEN_NUM%
  
  if %TEMP% GEQ 256 (
      set FLAG_INTERACTIVE=interactive
      set /a TEMP-=256
  )
  
  if %TEMP% GEQ 128 (
      set FLAG_DOZE=dream/doze
      set /a TEMP-=128
  )
  
  if %TEMP% GEQ 64 (
      set FLAG_BRIGHT=brightness override
      set /a TEMP-=64
  )
  
  if %TEMP% GEQ 32 (
      set FLAG_PROX=proximity
      set /a TEMP-=32
  )
  
  if %TEMP% GEQ 16 (
      set FLAG_AOD=AOD
      set /a TEMP-=16
  )
  
  if %TEMP% GEQ 8 (
      set FLAG_DIM=dim
      set /a TEMP-=8
  )
  
  if %TEMP% GEQ 4 (
      set FLAG_LOCKED=locked
      set /a TEMP-=4
  )
  
  if %TEMP% GEQ 2 (
      set FLAG_WAKING=waking
      set /a TEMP-=2
  )
  
  if %TEMP% GEQ 1 (
      set FLAG_ON=on
      set /a TEMP-=1
  )
  
  :: Print human-readable interpretation
  echo Screen flags:
  if defined FLAG_ON echo   - %FLAG_ON%
  if defined FLAG_WAKING echo   - %FLAG_WAKING%
  if defined FLAG_LOCKED echo   - %FLAG_LOCKED%
  if defined FLAG_DIM echo   - %FLAG_DIM%
  if defined FLAG_AOD echo   - %FLAG_AOD%
  if defined FLAG_PROX echo   - %FLAG_PROX%
  if defined FLAG_BRIGHT echo   - %FLAG_BRIGHT%
  if defined FLAG_DOZE echo   - %FLAG_DOZE%
  if defined FLAG_INTERACTIVE echo   - %FLAG_INTERACTIVE%
  
  if not defined FLAG_ON if not defined FLAG_WAKING if not defined FLAG_LOCKED if not defined FLAG_DIM if not defined FLAG_AOD if not defined FLAG_PROX if not defined FLAG_BRIGHT if not defined FLAG_DOZE if not defined FLAG_INTERACTIVE (
      echo   - none (screen off)
  )
  
  :: Now also read the AOSP enum screen state from WindowManager
  echo.
  echo (2) Command: adb shell dumpsys window ^| findstr /I "screenState"
  
  set SCREEN_ENUM=
  for /f "tokens=2 delims==" %%S in ('adb shell dumpsys window ^| findstr /I "screenState"') do (
      set SCREEN_ENUM=%%S
  )
  
  if "%SCREEN_ENUM%"=="" (
      echo Enum screen state unavailable. Phone not reachable yet.
  ) else (
      echo Enum screen state: %SCREEN_ENUM%
  )
  
  echo.
  
  
  :: End 3
  
  
  :: Begin 4
  echo.
  echo === 4. Attempting to Wake adbd if reachable ===
  echo Trying: adb shell stop adbd
  adb shell stop adbd 2>nul
  echo Trying: adb shell start adbd
  adb shell start adbd 2>nul
  echo.
  :: End 4
  
  :: Begin 5
  echo.
  echo === 5. adbd Internal State ===
  echo Command: adb shell getprop init.svc.adbd
  adb shell getprop init.svc.adbd
  if errorlevel 1 (
      echo.
      echo adbd is UNREACHABLE.
      echo.
      echo Meaning:
      echo  No TLS connection
      echo  No TCP/IP connection
      echo  No USB connection
      echo.
      echo Result:
      echo  Cannot read adbd internal state
      echo  Cannot restart adbd remotely
      echo  Phone is in ADB Deep Sleep mode
  ) else (
      echo adbd internal state retrieved.
  )
  echo.
  
  echo Command: adb shell getprop service.adb.tcp.port
  adb shell getprop service.adb.tcp.port
  echo.
  
  echo Command: adb shell getprop ro.adb.secure
  adb shell getprop ro.adb.secure
  echo.
  :: End 5
  
  :: Begin 6
  echo.
  echo === 6. Wireless Debugging State ===
  echo Command: adb shell dumpsys activity service com.android.adb.adbd
  adb shell dumpsys activity service com.android.adb.adbd
  if errorlevel 1 (
      echo.
      echo Wireless Debugging service is ASLEEP.
      echo.
      echo Meaning:
      echo  The service is not running
      echo  The TLS advertiser is not active
      echo  The phone cannot accept TLS connections
      echo.
      echo Why this happens:
      echo  Android put the service into deep sleep
      echo  Happens after long idle periods or Wi-Fi changes
      echo.
      echo Result:
      echo  Wireless Debugging must be toggled OFF -> ON manually
      echo  Or USB must be used to wake adbd
  ) else (
      echo Wireless Debugging service is ACTIVE.
  )
  
  echo.
  :: End 6
  
  :: Begin 7
  echo.
  echo === 7. scrcpy Readiness Check ===
  echo If device shows as "device", scrcpy can run.
  echo If port 5555 is active, scrcpy --tcpip works.
  echo.
  
  echo Command: adb devices
  adb devices > devices.tmp
  
  :: USB fallback detection
  :: This detects whether
  ::  USB connected as device appears without an IP
  ::  TCP/IP connected as device appears with 192.168.x.x:5555
  ::  Neither, likely meaning deep sleep
  findstr /I "device" devices.tmp | findstr /V ":" >nul
  if not errorlevel 1 (
      set USB_STATE=CONNECTED
  ) else (
      set USB_STATE=DISCONNECTED
  )
  
  echo.
  echo If no devices appear:
  
  echo   ADB cannot reach the phone
  echo   TLS is asleep
  echo   TCP/IP mode is off
  echo   scrcpy cannot run
  echo.
  echo If the phone appears as "device":
  echo   scrcpy can run over USB or TCP/IP
  echo.
  echo If the phone appears as "192.168.x.x:5555 device":
  echo   scrcpy --tcpip will work
  
  echo.
  :: End 7
  
  :: Begin 8
  echo.
  echo === ADB Deep Sleep Summary ===
  
  :: Determine deep sleep state
  if "%TLS_STATE%"=="ASLEEP" (
      if "%TCPIP_STATE%"=="OFF" (
          if "%USB_STATE%"=="DISCONNECTED" (
              echo.
              echo OVERALL STATE: PHONE IS IN ADB DEEP SLEEP MODE.
              echo.
              echo Meaning:
              echo  TLS advertiser asleep
              echo  TCP/IP mode off
              echo  USB not connected
              echo.
              echo Recovery summary:
              echo  1. Toggle Wireless Debugging OFF -> ON
              echo  2. Connect USB and run: adb tcpip 5555
              echo  3. Reboot the phone to restart adbd
          )
      )
  )
  
  if "%USB_STATE%"=="CONNECTED" (
      echo.
      echo OVERALL STATE: USB CONNECTED.
      echo scrcpy can run over USB.
  )
  
  if "%TCPIP_STATE%"=="ON" (
      echo.
      echo OVERALL STATE: TCP/IP MODE ACTIVE.
      echo scrcpy --tcpip will work.
  )
  :: End 8
  
  :: Begin 9
  echo Checking for Hard Deep Sleep...
  adb mdns services | findstr /I "_adb-tls-connect._tcp" >nul
  if errorlevel 1 (
      set TLS_STATE=ASLEEP
  ) else (
      set TLS_STATE=ACTIVE
  )
  
  adb connect %PHONE_IP%:5555 >nul
  if errorlevel 1 (
      set TCPIP_STATE=ASLEEP
  ) else (
      set TCPIP_STATE=ACTIVE
  )
  
  adb devices | findstr /I "device" | findstr /V ":" >nul
  if errorlevel 1 (
      set USB_STATE=NOT_AUTH
  ) else (
      set USB_STATE=AUTHORIZED
  )
  
  echo Checking for Hard Deep Sleep...
  
  :: Hard Deep Sleep means:
  ::   TLS asleep
  ::   TCPIP refusing
  ::   adbd unreachable
  ::   scrcpy failed
  
  if "%TLS_STATE%"=="ASLEEP" (
      if "%TCPIP_STATE%"=="ASLEEP" (
          echo.
          echo Hard Deep Sleep detected.
          echo Wireless Debugging is stuck.
          echo TLS advertiser did not restart.
          echo adbd is unreachable.
          echo scrcpy cannot connect.
          echo.
          echo Fix:
          echo   Reboot the phone to restart Wireless Debugging.
          echo   After reboot, enable Wireless debugging.
          echo   Then re-run adbconnecttls.bat.
          echo.
      )
  )
  
  
  echo.
  echo Android 12+ TLS auto-connect failed.
  echo USB fallback unavailable.
  echo Android 11 Wireless Debugging pairing mode is available.
  echo.
  echo This debug tool does not perform pairing or connection steps.
  echo Use adbconnect.bat to run Android 11 pairing mode.
  echo.
  echo Steps:
  echo   1. On the phone, open Wireless debugging
  echo      Choose "Pair device with pairing code"
  echo   2. Note the IP, pairing port, pairing code, and debug port
  echo   3. Run adbconnect.bat and enter the values when prompted
  echo.
  echo After pairing, adbconnect.bat will:
  echo   Connect to the debug port
  echo   Switch the device to TCP/IP 5555
  echo   Connect to port 5555
  echo   Launch scrcpy
  echo.
  echo This diagnostic script only reports the state and suggests actions.
  
  
  :: End 9
  
  :: Begin 10
  echo.
  echo ============================================
  echo adbdebugtls.bat %SCRIPT_VERSION% %SCRIPT_DATE% Diagnostics complete
  echo ============================================
  
  echo.
  echo ============================================
  echo === Suggested Commands to Fix Wireless Debugging ===
  echo ============================================
  echo.
  echo Your phone is NOT ready for TLS auto-connect.
  echo To make adbconnecttls.bat succeed, do ONE of the following:
  echo.
  
  :: Normal Deep Sleep recommendation
  if "%TLS_STATE%"=="ASLEEP" (
      if "%TCPIP_STATE%"=="OFF" (
          if "%USB_STATE%"=="DISCONNECTED" (
              echo --- Normal Deep Sleep ---
              echo 1. Open Developer options, Wireless debugging
              echo    Toggle Wireless debugging OFF, then ON
              echo    This wakes the TLS advertiser in normal Deep Sleep
              echo.
          )
      )
  )
  
  :: Hard Deep Sleep recommendation
  if "%TLS_STATE%"=="ASLEEP" (
      if "%TCPIP_STATE%"=="ACTIVE" (
          if "%USB_STATE%"=="AUTHORIZED" (
              echo --- Hard Deep Sleep ---
              echo 2. Reboot the phone from the power menu
              echo    Wireless Debugging and TLS will restart cleanly
              echo    After reboot, enable Wireless debugging again
              echo.
          )
      )
  )
  
  echo --- Android 11 Pairing Code Mode ---
  echo 3. On the phone, open Wireless debugging and choose
  echo       Pair device with pairing code
  echo    Note the IP and port shown on the phone
  echo    Then run on the PC
  echo       adb pair ^<ip^>:^<port^>
  echo    After pairing succeeds, run
  echo       adb connect ^<ip^>:^<port^>
  echo.
  
  echo --- USB fallback if USB works ---
  echo 4. Connect USB and run on the PC
  echo       adb devices
  echo       adb tcpip 5555
  echo       adb connect %PHONE_IP%:5555
  echo    This wakes adbd and enables classic TCP/IP mode
  echo.
  
  echo After doing one of these, re-run adbconnecttls.bat
  echo It should now be able to connect successfully
  echo.
  
  :: End 10
  
  echo Running adbdebugtls.bat %SCRIPT_VERSION% %SCRIPT_DATE%
  endlocal
  exit /b
  
  :: end of adbdebugtls.bat
  
-- 
This is my current debugging script which works but only on my Samsung.

[toc] | [prev] | [next] | [standalone]

#154434

Maria Sophia wrote:
> As just an example frustrating me at this very moment, look at the comments 
> in the versions of the script below just from today's testing & debugging!

Notice you'd never know how much frustration the fact Samsung is completely
different than AOSP caused me, from my cleanup of the comments from today.

  :: v2p0 - Added dual screen-state system detection (Samsung + AOSP)
  :: v1p9 - Added numeric bitmask decoder for Samsung Android 13
  :: v1p8 - Added screen-state checks for TLS pairing behavior
  :: v1p7 - Added battery-saver detection (kills TLS advertiser)
  :: v1p6 - Added deep-sleep detection and pairing fallback guidance
  :: v1p5 - Added hard deep-sleep reboot requirement
  :: v1p4 - Added TLS recovery suggestions
  :: v1p3 - Added Wireless Debugging toggle guidance
  :: v1p2 - Added TLS-only mode detection and summary block
  :: v1p1 - Added script version/date output
  :: v1p0 - Initial ADB/TLS diagnostic for Android 12+

But, with respect to screen state, which is off topic in terms of screen
state but very much on topic in terms of how much Samsung changes AOSP...

  :: Android 12+ Wireless Debugging (TLS mode) uses an mDNS advertiser
  :: that broadcasts:
  ::     _adb-tls-connect._tcp
  ::
  :: When the phone screen is OFF, Samsung devices often suspend this
  :: advertiser. When suspended:
  ::   - TLS auto-discovery fails
  ::   - adb mdns services shows nothing
  ::   - adb connect (TLS) fails
  ::
  :: Classic TCP/IP ADB on port 5555 does NOT depend on screen state.
  :: TLS mode DOES depend on screen state. Therefore this script checks
  :: whether the screen is awake before diagnosing TLS failures.
  ::
  :: ------------------------------------------------------------
  :: Two independent screen-state systems on Samsung Android 13
  ::
  :: 1. WindowManager (AOSP)
  ::    adb shell dumpsys window | findstr /I "screenState"
  ::      SCREEN_STATE_ON
  ::      SCREEN_STATE_OFF
  ::
  :: 2. Samsung vendor PowerManager extension
  ::    adb shell dumpsys power | findstr /I /C:"screen on profiler"
  ::
  ::    This numeric value is a bitmask combining multiple flags:
  ::      0   Screen OFF
  ::      1   Screen ON (bright or dim)
  ::      2   Waking / brightening
  ::      4   Locked
  ::      6   OFF + locked
  ::      7   ON + waking + locked
  ::      8   Dim
  ::      16  Always-on display (AOD)
  ::      31  ON + waking + locked + dim + AOD
  ::      32  Proximity sensor active
  ::      64  Brightness override
  ::      128 Dream / doze
  ::      256 Interactive
  ::      etc.
  ::
  :: Samsung removed the old AOSP screen-state flags from dumpsys power
  :: and replaced them with this vendor-specific bitmask. Therefore this
  :: script reads BOTH systems:
  ::   - Numeric bitmask (Samsung)
  ::   - Enum state (AOSP)
  ::
  :: ------------------------------------------------------------
  :: Why both systems matter
  ::
  :: TLS advertiser sleep/wake behavior depends on the phone¢s actual
  :: interactive state, not just whether the display is logically ON.
  ::
  :: Example:
  ::   Numeric = 32 (proximity override)
  ::   Enum    = SCREEN_STATE_ON
  ::
  :: This mismatch indicates the screen is ON but the device may not be
  :: fully interactive. TLS advertiser may remain suspended in this state.
  ::
  :: ------------------------------------------------------------
  :: Additional checks
  ::
  :: Battery Saver:
  ::   adb shell settings get global low_power
  ::     1 = ON (Samsung aggressively suspends TLS advertiser)
  ::     0 = OFF
  ::
  :: Wireless Debugging service:
  ::   adb shell dumpsys activity service com.android.adb.adbd
  ::
  :: adbd internal state:
  ::   adb shell getprop init.svc.adbd
  ::   adb shell getprop service.adb.tcp.port
  ::
  :: TCP/IP mode:
  ::   adb connect <ip>:5555
  ::
  :: TLS advertiser:
  ::   adb mdns services

Samsung drives me nuts. If it wasn't for the sd card, I'd buy a Pixel.
-- 
I don't worship brands; I run experiments that worship the truthful output.

[toc] | [prev] | [next] | [standalone]

#154397

Jörg Lorenz, 2026-07-09 19:26:

> On 09.07.26 18:33, Carlos E. R. wrote:
>> Ji,
>> Just found out that Samsung has its own contacts app.
>>
>> And if you want Thunderbird (K-9?) to use contacts, you have to install 
>> the google contacts app to provide the API.
>>
>> Curious!
> 
> Not at all!
> Typical Android-chaos.

No, vendor chaos! Samsung always behave different like they where Apple
just with Android instead if iOS. Their smartwatches also do not provide
all features with non-Samsung smartphones.

Android itself has a well defined API which is also used bei
K-9/Thunderbird and of course you can use your contacts there as well.
It is just Samsung which use a broken custom version of Android which
does not allow this by default.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#154389

On Thu, 9 Jul 2026 18:33:59 +0200, Carlos E. R. wrote:

> Ji,
> Just found out that Samsung has its own contacts app.
> 
> And if you want Thunderbird (K-9?) to use contacts, you have to install 
> the google contacts app to provide the API.

This is why I detest Samsung: their need to use their own apps. In
Belgium we use an app called Itsme to access government sites and
netbanking. It simply doesn't work on a Samsung with Samsung Internet as
default browser, but it works just fine on Firefox and Chrome (and
probably every other browser besides Samsung Internet).

-- 
s|b

[toc] | [prev] | [next] | [standalone]

#154391

On 09.07.26 22:17, s|b wrote:
> On Thu, 9 Jul 2026 18:33:59 +0200, Carlos E. R. wrote:
> 
>> Ji,
>> Just found out that Samsung has its own contacts app.
>>
>> And if you want Thunderbird (K-9?) to use contacts, you have to install 
>> the google contacts app to provide the API.
> 
> This is why I detest Samsung: their need to use their own apps. In
> Belgium we use an app called Itsme to access government sites and
> netbanking. It simply doesn't work on a Samsung with Samsung Internet as
> default browser, but it works just fine on Firefox and Chrome (and
> probably every other browser besides Samsung Internet).

WTF should anyone buy a Samsung?

-- 
"Roma locuta, causa finita" (Augustinus)

[toc] | [prev] | [next] | [standalone]

#154392

On Thu, 9 Jul 2026 22:22:52 +0200, Jörg Lorenz wrote:

> WTF should anyone buy a Samsung?

I wonder that myself. I once had a Samsung Galaxy Mini and at times I
just wanted to throw it against the wall. I switched to Nexus 5X and
then Pixel (I know). Nexus was cheap at that time, but with the Pixel
available Google upped their price. I know I can install Graphene OS,
but I just cannot be bothered. I've turned off as much settings as I
can, but I'm not 100% convinced it makes any difference to my privacy.

-- 
s|b

[toc] | [prev] | [next] | [standalone]

#154393

Am 10.07.26 um 11:12 schrieb s|b:
> On Thu, 9 Jul 2026 22:22:52 +0200, Jörg Lorenz wrote:
> 
>> WTF should anyone buy a Samsung?
> 
> I wonder that myself. I once had a Samsung Galaxy Mini and at times I
> just wanted to throw it against the wall. I switched to Nexus 5X and
> then Pixel (I know). Nexus was cheap at that time, but with the Pixel
> available Google upped their price. I know I can install Graphene OS,
> but I just cannot be bothered. I've turned off as much settings as I
> can, but I'm not 100% convinced it makes any difference to my privacy.

Sounds very much like my own "Android-career".
Started 2016 with a Nexus 5X and switched then to a Pixel 4 and later to
a Pixel 7 which is still doing its job satisfactorily. Today I would
only buy a Pixel and ignore the rest of the crowd. My primary smartphone
is a iPhone 17 which explains perhaps my hardware strategy.

-- 
"Roma locuta, causa finita."

[toc] | [prev] | [next] | [standalone]

#154400

Jörg Lorenz, 2026-07-10 11:33:

> Am 10.07.26 um 11:12 schrieb s|b:
>> On Thu, 9 Jul 2026 22:22:52 +0200, Jörg Lorenz wrote:
>>
>>> WTF should anyone buy a Samsung?
>>
>> I wonder that myself. I once had a Samsung Galaxy Mini and at times I
>> just wanted to throw it against the wall. I switched to Nexus 5X and
>> then Pixel (I know). Nexus was cheap at that time, but with the Pixel
>> available Google upped their price. I know I can install Graphene OS,
>> but I just cannot be bothered. I've turned off as much settings as I
>> can, but I'm not 100% convinced it makes any difference to my privacy.
> 
> Sounds very much like my own "Android-career".
> Started 2016 with a Nexus 5X and switched then to a Pixel 4 and later to
> a Pixel 7 which is still doing its job satisfactorily. Today I would
> only buy a Pixel and ignore the rest of the crowd. My primary smartphone
> is a iPhone 17 which explains perhaps my hardware strategy.

And my primary smartphone is a Google Pixel 6a (which will once vy
replaced by a Pixel 10 or whatever is the current version when the
software supports ends for the 6a in 1-2 years). I don't need Apple
devices at all.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#154405

On Fri, 10 Jul 2026 13:22:18 +0200, Arno Welzel wrote:

> And my primary smartphone is a Google Pixel 6a (which will once vy
> replaced by a Pixel 10 or whatever is the current version when the
> software supports ends for the 6a in 1-2 years). I don't need Apple
> devices at all.

Nexus 5X > Pixel 3 > Pixel 6 > Pixel 10

10 has 7 years support, but I still use 6 which has gone from A12 to A17
and still running fine.

-- 
s|b

[toc] | [prev] | [next] | [standalone]

#154399

Jörg Lorenz, 2026-07-09 22:22:

> On 09.07.26 22:17, s|b wrote:
>> On Thu, 9 Jul 2026 18:33:59 +0200, Carlos E. R. wrote:
>>
>>> Ji,
>>> Just found out that Samsung has its own contacts app.
>>>
>>> And if you want Thunderbird (K-9?) to use contacts, you have to install 
>>> the google contacts app to provide the API.
>>
>> This is why I detest Samsung: their need to use their own apps. In
>> Belgium we use an app called Itsme to access government sites and
>> netbanking. It simply doesn't work on a Samsung with Samsung Internet as
>> default browser, but it works just fine on Firefox and Chrome (and
>> probably every other browser besides Samsung Internet).
> 
> WTF should anyone buy a Samsung?

Because Samsung has a big marketing department and people realize such
problems only *after* they bought the phone.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#154417

Arno Welzel wrote:
>> WTF should anyone buy a Samsung?
> 
> Because Samsung has a big marketing department and people realize such
> problems only *after* they bought the phone.

For some of us, the only Android brands to choose from are Pixel or Galaxy.

As you know, when I was thinking of replacing my Samsung, I only looked at
Pixel and Galaxy because there's a ton of customization documentation for
both.

The debilitating drawback of the Pixel, for me, is the lack of sd card but
I understand that if I buy way too much storage, that isn't then an issue.

Otherwise the answer to "Why buy a Samsung" is that many still have sd
slots, which means you get portable storage for about 30 bucks a pop.

[toc] | [prev] | [next] | [standalone]

#154418

Maria Sophia <mariasophia@comprehension.com> wrote or quoted:
>The debilitating drawback of the Pixel, for me, is the lack of sd card but
>I understand that if I buy way too much storage, that isn't then an issue.

  I want an SD slot, too, but for a different reason: The SD
  card is my data storage. I buy a new phone, plug in the SD
  card from the old phone, and have all my data again!

[toc] | [prev] | [next] | [standalone]

#154420

On 2026-07-12, Stefan Ram wrote:

> Maria Sophia <mariasophia@comprehension.com> wrote or quoted:
>>The debilitating drawback of the Pixel, for me, is the lack of sd card but
>>I understand that if I buy way too much storage, that isn't then an issue.
>
>   I want an SD slot, too, but for a different reason: The SD
>   card is my data storage. I buy a new phone, plug in the SD
>   card from the old phone, and have all my data again!

Yeah, that touches on the same thing that occurred to me: it's not
merely another storage device and an upgradeable one (also one that can
be replaced in case of wear, although I'd expect the internal one to
meet much higher levels of resiliency for that to be an issue), it's
also a way to move/copy files when needed.

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.mobile.android

csiph-web