Samsung’s Auto Hot-Spot Feature

I own a Samsung Galaxy S9 smart-phone, and have discovered that, in its tethering settings, there is a new setting, which is named “Auto Hotspot”. What this setting aims to do if activated is, on other Samsung devices, which normally only have WiFi, when the user is roaming along with his phone, there should appear an additional access point for them to connect to. The following screen-shots show, where this can be enabled on the phone

Screenshot_20201220-072343_Settings_e

Screenshot_20201220-072354_Settings_e

Screenshot_20201220-072404_Settings_e

Screenshot_20201220-072414_Settings_e

I believe that this explains a fact which I’ve already commented on elsewhere, which is, that when I try to set up Google Instant Tethering, the negotiation between my ‘Asus Flip C213 Chromebook’ and this phone, no longer adds Instant Tethering to the list of features which are enabled. My Samsung S9 phone will now only unlock the Chromebook. What I am guessing is that, because the feature I’m showing in this posting is a Samsung feature, with which Samsung wants to compete with the other companies, Samsung probably removed to offer Instant Tethering from their phone.

Obviously, this is only a feature which I will now be able to use, between my S9 phone, and my Samsung Galaxy TAB S6 tablet.


 

 

The reader may ask what the advantages of this feature might be, over ‘regular WiFi tethering’, or ‘a WiFi hotspot’. The advantage could be, that even though it remains an option compatible with all clients, to have the phone constantly offer a WiFi hot-spot could drain the battery more. Supposedly, if Samsung’s Auto Hotspot is being used, it can be kept enabled on the phone, yet not drain the battery overly, as long as client devices do not connect. The decision could then be made directly from the client device, whether to connect or not… This is similar, to what Google’s system offers.

Also, the Samsung phones with Android 10 have as feature, that their ‘regular hotspots’ will time out, say after 20 minutes of inactivity, again, to save battery drain. Yet, if the user is carrying a tablet with him that has been configured to connect to the mobile hotspot Automatically, the phone which is serving out this hotspot will never detect inactivity.


 

Further, I’ve been able to confirm that, as long as I have Auto Hotspot turned on on my phone, indeed it does not show up as an available WiFi connection, on devices that are not joined to my Samsung account. This is as expected. But it also adds hope that, as long as I don’t connect to the phone’s Auto Hotspot from another device, the battery drain due to my leaving this feature enabled on my phone constantly, may not be very high. I will comment by the end of this day, after having left my phone with its own WiFi Off, which means that my phone will be using its Mobile Data, but, not connecting my Samsung TAB S6, whether doing this seems to incur any unusually high amount of battery drain, on the phone…

 

Continue reading Samsung’s Auto Hot-Spot Feature

ChromeOS Upgrade from Debian 9 to Debian 10 – aka Buster – Google Script crashed.

I have one of those Chromebooks, which allow a Linux subsystem to be installed, that subsystem being referred to in the Google world as “Crostini”. It takes the form of a Virtual Machine, which mounts a Container. That container provides the logical hard drive of the VM’s Guest System. What Google had done at some point in the past was, to install Debian 9 / Stretch as the Linux version, in a simplified, automated way. But, because Debian Stretch is being replaced by Debian 10 / Buster, the option also exists, to upgrade the Linux Guest System to Buster. Only, while the option to do so manually was always available to knowledgeable users, with the recent Update of ChromeOS, Google insists that the user perform the upgrade, and provides ‘an easy script’ to do so. The user is prompted to click on something in his ChromeOS settings panel.

What happened to me, and what may also happen to my readers is, that this script crashes, and leaves the user with a ChromeOS window, that has a big red symbol displayed, to indicate that the upgrade failed. I failed to take a screen-shot of what this looks like. The button to offer the upgrade again, is thankfully taken away at that point. But, if he or she reaches that point, the user will need to decide what to do next, out of essentially two options:

  • Delete the Linux Container, and set up a new one from scratch. In that case, everything that was installed to, or stored within Linux will be lost. Or,
  • Try to complete the upgrade in spite of the failed script.

I chose to do the latter. The Linux O/S has its own method of performing such an upgrade. I would estimate that the reason for which the script crashed on me, might have been Google’s Expectation that my Linux Guest System might have 200-300 packages installed, when in fact I have a much more complete Linux system, with over 1000 packages installed, including services and other packages that ask for configuration options. At some point, the Google Script hangs, because the Linux O/S is asking an unexpected question. Also, while the easy button has a check-mark checked by default, to back up the Guest System’s files before performing the upgrade, I intentionally unchecked that, simply over the knowledge that I do not have sufficient storage on the Chromebook, to back up the Guest System.

I proceeded on the assumption, that what the Google script did first was, to change the contents of the file ‘/etc/apt/sources.list’, as well as of the directory ‘/etc/apt/sources.list.d’, to specify the new software sources, associated with Debian Buster as opposed to Debian Stretch. At that point, the Google script should also have set up, whatever it is that makes Crostini different from stock Linux. Only, once in the middle of the upgrade that follows, the Google script hanged.

(Updated 10/25/2020, 22h55… )

Continue reading ChromeOS Upgrade from Debian 9 to Debian 10 – aka Buster – Google Script crashed.

It’s perfectly possible to run AppImages from within Crostini.

One of the assets which I have, is an Asus Chromebook, that has modest specifications (including mere 32GB of storage), but on which I did activate the Debian / Stretch flavour of Linux. I should also mention that this Chromebook has the Intel Celeron N3350 CPU, which runs the x86_64 instruction set. This latter detail is of some importance, as full compatibility with Linux will not be realized without it. Admittedly, the subset of Debian / Stretch packages that have been cross-compiled to ARM CPU binaries is limited, and what I’m about to describe in this posting will not work at all, on ARM CPUs (that were also the more-common CPUs for use with Android).

The virtual machine that runs Linux inside ChromeOS is also called “Crostini”.

One of the limitations which I’ve heard about Crostini is, that one cannot perform most loop-mounts in root mode. For that reason, there might be some misgivings about being able to run AppImage’s, because those require a user-space mount of a ‘SquashFS’ file system, and also require the existence of a kernel module to do so.

Therefore, I am most happy to report, that on my Linux setup, and with up-to-date Chrome 85…, I am able to run AppImage’s after all, that were meant for Linux, and for the 64-bit, Intel / AMD CPU family.

As an example, I was well-able to download the Kdenlive video editor, in the form of the Linux AppImage, and to get it to run under ChromeOS. I find that often, the video editing features available from Google Play / Android apps are way too limiting.

Thus, I am finding new ways to enjoy my Chromebook and its Linux subsystem. I would warn people though, that, before running AppImage’s, they install a somewhat complete set of Linux applications and libraries.


 

(Update 9/10/2020, 20h55: )

Continue reading It’s perfectly possible to run AppImages from within Crostini.

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’…

(Updated 12/08/2020, 10h30… )

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