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





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

Revisiting the Android, UserLAnd app.

One of the facts which I had reported some time ago was, that a handy, easy-to-use Android app exists, which is called ‘UserLAnd‘, and, that I had installed it on my Google Pixel C Tablet. As the tooltip suggests, this is an Android app that will allow people to install a basic Linux system, without requiring ‘root’. Therefore, it mounts the apparent, local Linux file system with ‘proot’ – which is similar in how it works to ‘chroot’, except that ‘proot’ does not require root by the host system to set up – and any attempts to obtain root within this Linux system really fail to change the userid, of the app that the files belong to, or of the processes running. Yet, becoming root within this sandboxed version of Linux will convince Linux, for the purpose of installing or removing packages via ‘apt-get’.

In the meantime, I have uninstalled the ‘UserLAnd’ Linux guest system from my Pixel C Tablet, in order to free up storage. But, I have set up something like this again, on my Samsung Galaxy Tab S6 Tablet, which has 256GB of internal storage. Therefore, I have a few observations to add, about how this app runs under Android 10.

Through no fault of the developer of this Android app, the user is more restricted in what he can run, because Android 10 places new restrictions on regular processes. Specifically, none of the major LISP Interpreters that were designed to run under Debian 10 / Buster will run. (:1) What the Linux developers did was, to make the garbage collection of their LISP Interpreters more aggressive, through a strategy that changes the memory protection bits of memory-maps, to read-only if they belong to the state of the machine, and then, ~to try deleting as much of the bytecode as can still be deleted~. Pardon me, if my oversimplification gets some of it wrong.

Well, Android 10 no longer allows regular apps to change the protected memory state of any pages of RAM, for which reason none of the affected LISP Interpreters will run. And for that reason, neither “Maxima” nor anything that depends on Maxima can be made to run.

Yet, certain other Linux applications, notably “LibreOffice” and “Inkscape”, run just fine… So does “GIMP”…

Screenshot_20200912-171020_VNC Viewer

Also, the way in which files can be shared between theĀ  Android Host and the Linux Guest System has been changed, as the following two screen-shots show:

Screenshot_20200912-155032_VNC Viewer

Screenshot_20200912-155144_File Manager

Here, the file ‘Text-File.txt’ has been shared between Android and Linux. Larger files can also be shared in the same way, and the folder bookmarked under Linux. (:2)

In many ways, the Linux applications behave as described before, with the unfortunate exceptions I just named, and I intend to keep using this app.

Technically, a Host app that just sandboxes a Guest Application in this way, does not count as a Virtual Machine. A real VM allows processes to obtain root within the Guest System, without endangering the Host System. Also, ‘a real VM’ provides binary emulation, that makes no specific assumptions about the Guest System, other than, usually, what CPU is being used. Emulation that includes non-native CPU emulation is still a somewhat special type of emulation.

Therefore, the ability of Debian 10 / Buster to run under ‘UserLAnd’ depends, in this case, on the Linux package maintainers having cross-compiled the packages, to run on an ‘ARM-64′ CPU…


(Updated 9/13/2020, 21h30… )

Continue reading Revisiting the Android, UserLAnd app.

Another possible reason, why my Google Pixel C might have started crashing.

One of the facts which I posted about recently was, that My Google Pixel C Tablet had started crashing, roughly every one or two months. Because I haven’t really installed any new software on it, and because the most recent System Update took place sometime in mid-2019, I had assumed that the recent malfunctions could be due to some sort of hardware problem.

The fact that this tablet, which I only bought in 2017, was starting to become unstable, was partially also, why I have recently acquired a Samsung Galaxy Tab S6 tablet, as an eventual replacement.

But, there is in fact another possible explanation, for the crashes of the Pixel C. Until 2019, that tablet had received System Updates roughly once every month. It might just be that, due to many memory leaks, that tablet really needs to be rebooted once per month, and if nothing else, System Updates also resulted in soft reboots. The failure to perform any soft reboots, may be what’s leading to hard reboots. Only, hard reboots are dangerous, because too many of them can lead to file system corruption.

In that regard, I’m hoping that the new Tab S6, which has Android 10 installed, will offer a possible preventive measure, in the fact that it can be scheduled in advance, to reboot automatically, let’s say once per week. If that feature works out as expected, then the tablet in question may indeed last longer than the Pixel C did.

Really, I think it strange, that an Android tablet would crash – or hard-boot – because it was not soft-booted for more than a month. After all, my phones, also being Android devices, have usually been able to run for more than 2 months, without requiring any reboots, and when those finally do receive a soft-boot, it’s part of their System Update.



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:

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


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.