New issue with unlocking my Samsung phone via phone link app on PC

i'd be tickled to death to once again see a black screen where i could poke the unlock code into to resume the phone screen on the pc.

it seems your "MS Phone Link ... get around this and stay alive when the phone is asleep" is no longer true with android 13 (seems like that's when functionality got nuked, per MS quote below)

your "("project_media" permission, which can be given through ADB to any remote control app so you can connect remotely without the idiotic "start casting" dialog)." may be just the ticket to restore my ability to control screen from "different floor in house" .

i'd tried to connect to the s22 a while back via ADB, but couldn't get connection to work. guess i'll have to go back after it again.

if you please, what version of the PC and 'link to windows' were used?

for some time i was able to get by with the phone-link-1-22102-202-0.appxbundle on PC with samsung standard 'link to windows' .

didn't seem to ever realize any success with reverting to previous phone 'link to windows'.

and, the ms response on this issue is "Hi, thank you for your feedback. Please note that this change was made due to the security requirement update with Android 13 OS release. Thanks for letting us know about your dissatisfaction with the update. We've shared it with our development team to look into it further. Thank you."

translation: suck it up!

so sad when a great tool goes bad!

Getting remote control to work on modern Android is a huge rabbit hole. No remote control software (Anydes, Rustdesk, Teamviewer) works in unattended mode anymore because their host service gets killed once the phone is locked (no, it's not a power saving issue, it's probably some permission policy and/or a Samsung thing), but MS Phone Link and MyPhoneExplorer get around this and stay alive when the phone is asleep. The reason that PIN entry doesn't work over the remote is that at some point the PIN entry screen became a "secure" screen which can't be captured by screen grabbers ("project_media" permission, which can be given through ADB to any remote control app so you can connect remotely without the idiotic "start casting" dialog). So the best it gets is a remote control app (like Rustdesk) which shows a black screen where you can try to enter the PIN blindly by clicking where you expect the number buttons to be (because input is still working in this high-security model).

I'm pretty sure the PIN entry GUI in MS Phone Link just emulated clicks at the location of the number buttons (guessed from the screen size and maybe some hard-coded database of common GUI layouts). This method of blind clicking still should work - heck, you can overlay a screenshot of the PIN entry screen over the black screen in a remote control program and click yourself. MS most likely removed the function because Apple threatened to ban the app otherwise. I hope Tim trips and falls into a meat grinder after selling all the 0days to the NSO group.

There's no single app which can restore convenience after MS Phone Link removed the GUI emulation for PIN input (thanks to Tim Apple), I guess nobody cares about the niche of a dozen people who want to remote into their own phone. Rustdesk or Teamviewer can get to the blind PIN screen quite easily, but not when the phone was locked for a minute. Phone Link actually stays awake even when the phone is asleep (latest version on the phone and on Windows 11 as of today, S22 Ultra, Android 14, One UI 6.0) because you can always access messages, photos etc. without waking it up. But it can't nudge the phone out of the sleep mode - however MyPhoneExplorer can (that's a better version of Phone Link which supports file transfer over Wifi). So you can wake the phone up with MPE and hope the remote control's service comes back top life...

A more viable method is remote unlock over ADB - you can send some simple commands to wake up the phone and send the PIN as key inputs. If your phone supports wireless debugging, you don't need a USB connection and just run a simple batch script to unlock the phone and then connect with Phone Link or any other remote software. I think it has to be reenabled after reboot though. Of course you have to give your remote app projecting permissions (for Phone Link: ./adb shell appops set com.microsoft.appmanager PROJECT_MEDIA allow) but that's trivial. Teamviewer paid Samsung an ungodly amount of money to circumvent the projection permission via Knox (there's some trivia for you), but it still can't show a "secure" screen or keep the host service alive when the phone goes to sleep.

Getting ADB to work should be very simple - enable developer options and USB debugging and use the latest platform_tools from google. On first connect you'll get a popup on the phone where you have to whitelist your PC. What does it say when you type in "adb devices"?

Ok, I found a very convenient 1-(double)click workaround for me (S22 Ultra, Android 14): unlock the phone remotely with a batch file! Afterwards screen sharing works normally with Phone Link or any other remote software.

It's at the edge of being viable for normies, but it's not utterly complicated once you understood the required tools. It's simply using ADB to send the PIN as key inputs to the phone, which unlocks it: "adb shell input text XXXX" (where XXXX is your PIN). By far the easiest way is to have the phone connected over USB - you just have to enable USB debugging in the developer options once and then you can send ADB commands all day long.

It's more complicated to do it over Wifi. All modern phones support Wifi debugging but it has to be enabled once every reboot. Modern Samsung phones also have a convenient quick-settings button for it. Once it's running, you have to connect once from your PC to pair it ("adb connect IP:PORT") and then you can make a simple batch script like:

@echo offpushd "Z:\platform-tools"adb connect IP:PORTadb shell input text XXXXadb disconnectpopd

If your phone requires pressing OK after entering the PIN, add "adb shell input keyevent 66". For patterns or passwords the input sequence is different, you have to do your own research..

A big inconvenience on modern Android (11+) is that the port number for ADB over Wifi randomly changes each time you turn it on, so you'd have to modify your batch file each time. At least the IP address can be fixed if you give it a fixed IP in your router settings (or a DNS name). To avoid that, you have to enable legacy Wifi ADB which uses a fixed port (5555), and the easiest way is to run the LADB app on the phone once per reboot with a startup command to enable the legacy mode (see here for more details). The rabbit hole is probably too deep for nearly everyone, but it can be done...

I have the same issue

An option to fully trust a PC is essential as the current requirement to keep the phone screen on at all times is impractical. Moreover, the need to grant permission from the phone for each new application launch from the PC contradicts the purpose of using PC applications if the phone is constantly required for authorization. In such cases, it would be more efficient to simply use the phone itself.

A recent update to Windows (specifically Windows 11, not sure about other versions) has changed behavior regarding the Microsoft Store setting that prevents automatic download and install of Store-app updates.

The new behavior is that on every PC restart, Microsoft Store will update any Store-app that is not at the latest version -- even if the Microsoft Store setting "Automatically download and install app updates" has been explicitly set to Off.

This means that if you've been running Phone Link version 1.22102-202-0 to eliminate the constant need to physically unlock your phone when you wish to access a phone-app via the PC, that version will be replaced with a newer Phone Link version every time you restart your PC.

After the PC restart/Phone Link update, you can manually re-install 1.22102-202-0 to get the desired behavior back -- but this extra step on every PC reboot is a hassle.

So far, I haven't found anything online that discusses the new behavior regarding "Automatically download and install app updates". Hope someone else can shed light on this new annoyance.

-Steve