# An observation about the new Chrome OS Smart-Lock and Instant Tethering features.

I own a Samsung Galaxy S9 smart-phone, and an Asus Flip C213 Chromebook. And, two relatively new features which Google rolled out are:

• Smart-Lock: The ability to unlock the Chromebook, using the presence of the phone, and
• Instant Tethering: It has always been possible to activate the Mobile Hot-Spot feature of the phone, assuming that a user has a plan that includes tethering, and then to connect the Chromebook (or other device) to it, in the form of a mobile, Wi-Fi Access Point. But, with Instant Tethering, the availability of the phone as a tether is supposed to be more quickly visible from the Chromebook, and theoretically, accessible with a single click.

What some people have reported is, that this feature does not always work 100%, even though the procedure was followed, which my readers can find in many other places on the Web, to set up the feature. I recently experienced as well that, on my first try, these two features were not working at all, when the Chrome OS version on my Chromebook was ’80.x’. Yet, even during the interval of my trials, an update to the Chrome OS version had presented itself, to version ’81.y’. And since the update, the features seem to work 50% of the time.

There was an additional step which can be taken, but should not be 100% necessary in this case, and which I took, which is outlined in this article:

https://www.howtogeek.com/fyi/chrome-os-instant-tethering-comes-to-more-android-phones-heres-how-to-do-it/

I will explain below, Why I changed the flag under:

chrome://flags/#instant-tethering

From ‘Default’, to ‘Enabled’. A reboot was required…

One reason these features may still not work 100% for me, could be the possibility of the phone going into ‘Deep Sleep’…

Deep sleep is a state which Android phones go in to, when they are not being used in a way apparent from their touch-screens, and after the Upgrade of my phone to Android 10, which is also referred to as Android ‘Q’, deep sleep is applied more aggressively than it was under Android 9, which was also referred to as Android ‘Pie’. In this state, the phone still has some processing power connected to its Wi-Fi and its Bluetooth chip, but that processing power does not:

• Respond to (Wi-Fi) UDP network broadcasts, or
• Wake up the main CPU, in response to some incoming Bluetooth requests.

Simply double-tapping on the ‘Always On Display’, to bring up the Lock Screen of the phone, is enough at least, to make it visible to these features of the Chromebook, even if the phone has not yet been unlocked (:1).

If the Chromebook is able to communicate with the phone, but the phone is locked, then, in the Chromebook’s lock screen, the corresponding icon will read “Your phone is locked. Unlock it to enter.”

But my main concern was, whether the phone would be available as an Instant Tether, even if it was kept in my pocket and not touched. And the answer could become No, due to being in Deep Sleep.

When the option is clicked on the Chromebook, actually to initiate the Instant Tether for the first time, a Samsung S9 phone will display a notification(, and play any notification sound), which the user must tap, before mobile data is granted to the Chromebook. At that point, my phone also displays briefly, that it is verifying with my provider, whether tethering is included in my plan. And then, seconds later, my Chromebook is using my mobile data.

I think that the main reason a Samsung S9 phone does this, is the additional fact that this phone does not have an explicit setting, to ‘Enable Instant Tether‘. A Google phone would have such an additional setting.

If the user has granted this permission once, then he does not need to grant it again, and subsequent requests from the same Chromebook for Instant Tethering simply cause a notification to display (on the Samsung S9), that its Mobile Data is in the process of being Shared.

Thus, the most-efficient sequence which I could go through, if actually on-the-go and to use the feature, would be:

1. Unlock my Chromebook using its password,
2. Observe that the Chromebook is capable of detecting the phone,
3. On the Chromebook, select to use the phone’s Mobile Data.

Before this feature was made available, what I needed to do was:

1. Unlock my phone,
2. On the phone, activate my Mobile Hot-Spot,
3. Put the phone back in my pocket, locking it first – The phone stays awake,
4. Unlock the Chromebook using its password,
5. Wait for a few seconds, before the Chromebook connects to the Mobile Hot-Spot, because that is a known Wi-Fi Access Point.

I suppose that there are more potential advantages, in actually using Instant Tether:

• The Chromebook will display the phone’s battery status,
• The connection will be discontinued by itself, after ’10 minutes of disuse’,
• Possibly: The Chromebook may reduce the amount of data being communicated, in a way that takes into account, the fact that it’s on a tether. After all, when simply connected to a Wi-Fi Access Point, the Chromebook has no inherent distinction between ‘data due to conscious use’, and ‘data being communicated in the background’.
• Because I set the Chrome OS flag mentioned above to its non-default setting, I get to see the battery status of the phone in the ‘Mobile data’ section of the Chromebook’s Networks List, even when having activated the phone’s Mobile Hot-Spot instead. However, this ability owes to the fact that the feature was added.

I should also point out that it would be a mistake, ever to try to Bluetooth-Pair the phone with the Chromebook manually. Luckily, I never made this mistake, because from the first moment of the activation of the Chromebook, it guided me into Connecting my phone, under the Connected Devices section in its settings, and, following the instructions given by the Chromebook, also averted any danger that I might try to pair it under the Bluetooth settings section. From what I read, trying to do that can mess up the Chromebook, to the point where a factory reset is required to straighten it out again.

Also, when I first activated my Chromebook, the Smart-Lock feature worked.

Yet, staying within the Connected Devices settings section, it is possible to ‘Forget’ the smart-phone, and then connect it again, apparently with no net effect. Of course, the user will be prompted to re-enter his password.

The reason for which I chose to change the flag in the Chrome OS Settings was, When this flag is set to ‘Enabled’, the section is always visible, after one has clicked on the Time-Icon in the bottom right, and, after one has clicked on the Text, below the Wi-Fi icon, of ‘Mobile data’, above the ‘Wi-Fi Networks’ section, regardless of whether a mobile device appears there or not. The little white rectangle that appears to the right of each displayed device is its Battery Status, revealed when hovering over, with the mouse-pointer. Also, just clicking on the Wi-Fi icon itself, only turns Wi-Fi on and off, which is not what I’d want next.

But, the way in which Instant Tethering was meant to work was, that the Chromebook would display a notification, under the logical conditions when this feature would be useful, which is:

• When no known Wi-Fi Access Points are available to the Chromebook, and
• When the phone is on Mobile Data, not on Wi-Fi.

Keeping this section always visible, gave me a more accurate idea, of whether my phone is being detected at any moment, even during moments when it would not make sense to use Instant Tethering.

BTW, the phone itself will be visible due to its Bluetooth feature, which must be turned on, even though no attempt must be made, to try to Bluetooth-pair the phone to the Chromebook.

In my own experiences, features do not work 100%, just because a first attempt is being made to use them, on any given device. This attempt causes settings to be initialized by the device’s O/S, which can often throw hurdles in the way of the user, which will no longer be noticeable, during a second attempt to use the feature. For that reason, all such capabilities should be rehearsed by the user, before he or she actually needs them.

1:)

It’s a standard part of how any modern Android phone works, that it possesses a ‘base-band CPU’, that serves its networking chips, including any chips used for mobile data, plus a ‘performance CPU’, only the latter of which will actually go into Deep Sleep.

What makes the Samsung line of smart-phones somewhat better than that, including the ‘Galaxy S9′, is the presence of 2, quad-core CPUs, one of which is the ‘low-power CPU’, and the other of which is the ‘variable-speed CPU’. In Canada (where I live) and the USA, that would be a ‘Snapdragon 845 SoC’, while in many other countries, that would be a similar ‘Exynos 9810 SoC’.

Because it would have been somewhat awkward to design a phone that has 3 CPUs – at least, according to the present state of the technology – These types of Samsung phones use their constant-speed, low-power CPU to serve the networking chips, so that only their variable-speed CPU ever goes to sleep. It might be somewhat questionable, whether a platform which has been put to sleep in this way, is in fact in ~Deep Sleep~.

But the way that works out for me right now is, that I’m listening to music on my Bluetooth headphones (using the “Google Play Music” app), yet, that the phone is ‘asleep’ – meaning that its variable-speed CPU is in standby mode. The way I can be certain of this is in the fact that the ‘KDE Connect’ desktop widget on my main PC, frequently displays “No paired devices available”, despite being fully set up. This is factually caused by a failure of certain Android devices to respond to (Wi-Fi) UDP Broadcasts, when in Deep Sleep. Therefore, the Samsung S9’s low-power CPU has enough power, already being a quad-core, to support music playback…

Whether the phone will be visible to the Chromebook (as a “Device” – not under the “Bluetooth” settings section), when being used in this way, depends on which processes have been scheduled by the phone’s O/S to be running on the low-power CPU. That may not be the case, when the user is first setting up the feature. And it may also not be the case after an overnight period of inactivity….

Dirk