There exists a higher-quality solution to this need, known as ‘Samsung Side-Sync’. But a big problem in my own desire to use this Android app, is the fact that its client-program is only available for Mac or Windows – while I mainly tend to have Linux installed on my PCs and laptops.
The capability which the app delivers, is to turn the Android device into a type of remote, VNC Host, or Server, on which a client seeks to establish a session, in which the properties and resources of the host, are displayed on the client-computer, remotely, as if the user of the client was in fact sitting in front of the host.
This is not so strange an idea, as various types of VNC / RDP already exist, by which a remote session is created on a Windows or a Linux PC as host, such that the client – even if that client exists as an Android client – can seem to have a remote session.
Because I was intrigued by making the Android device the host for a change, and by the possibility of using a Web-interface as client, I decided to give an app a try, which is called AirDroid. After all, even Linux computers have Web-browsers which would be powerful enough to run as clients.
I installed the app on my up-to-date Google Pixel C Tablet, But was initially disappointed, in the apparent observation, that AirDroid just did not seem stable enough to trust with such an objective.
(Last Updated 08/09/2017 : )
Apparently, there are two reasons for which I might not have been able to use this app, with the tablet that I had selected as my Guinea Pig:
- AirDroid is already known to have as one of its weaknesses, a potential failure to keep the remote host awake, or to wake it up, simply because the owner has requested a remote session on it. Doing so already runs counter, partially, to how up-to-date Android versions would like their apps to work. This would be in a mode where the screen of the device starts out blank and stays blank.
- For some unknown reason, this app does not understand how to operate the camera. When we are supposed to scan-in a Barcode, for LAN-access, the picture within the app, from the camera, is rotated 90⁰ with respect to whatever the camera sees in front of the device, and the app cannot scan the Barcode. Could this be, because the app has only been programmed with an awareness for Portrait-Orientation phones, not Landscape tablets? Further, I had set up the app on the tablet far enough, so that I could gain a session on it. This way, most of the icons in the Web-client window worked. But then, when I requested that my Web-client window obtain a camera-view from the supposedly-remote tablet (The tablet was sitting next to me), the tablet actually just froze!
Either of these two behaviors would be enough reason, not to use this app. Imagine that a legitimate user wanted remote access to a tablet he could not touch, and that doing so would cause the tablet just to freeze.
I suppose that there is a deeper problem in using such an app, which has to do with the tremendous security-liability that comes with installing it. I trust myself not to give my password to anybody else, which we use to access the Web-account. But there is no way to guarantee to me, that the operators of this Web-service will not grant access to themselves, even when the user-password is not given.
This problem becomes more acute, when the service is offered by a third party. As long as such a VNC-like service is just offered by Google or Samsung, the fact prevails that we’ve already trusted either company to provide the actual O/S. If they wanted to hack our devices, they would not actually need for us to install a VNC-host to do so. But a third party just might, especially since none of their software is open-source software.
This type of software would be the ideal remote-management software, by which to keep a back-door into a device lent to someone else. And as it happens, its providers plead with the user, not to install it on devices he does not own.
What I did next was to sign out the host-app, from my Android device, which required I enter my AirDroid password. Doing so gave the app its best opportunity to act honestly,
when requested by its user to uninstall. By entering my AirDroid password, I proved that I was also the person who had installed AirDroid. And then I uninstalled the app.
Now, there exists some lingering doubt, as to whether that app could still have left something on my tablet. But one advantage we have when using Android, is the fact that this O/S provides an Application Framework. What this means, among other things, is that while the list of permissions one app requests might be long, if we uninstall the app, and then reboot the tablet, we should recover a tablet that is as it was, before we installed the app.
In order to leave something behind, AirDroid would actually need to bypass the application framework, and I’m sure that Google would not appreciate that.
But, because one of the permissions the app had, was to change the settings of the host device, the probability remains high, that it changed some settings in a way meant to enhance how AirDroid itself works, but that uninstalling the app did not reset those, so that I might find it impossible in practice, to find the exact settings the app has changed, and to change those back, to my own liking. But this inconvenience does not amount to a hacked device.
(Edit 08/08/2017 : I have found out, that the best way to uninstall AirDroid, is by using the button within the app itself, suggesting that the scenario has been accounted for by its developers. )
Further, while AirDroid allows the remote client to install apps on the hosting device, we are warned by our Web-client window, that we’d actually need to change the settings physically on the host-device, to allow apps to be installed from outside Google Play, before the Web-client window will allow us to do so. This actually means that the hosting app does not go so deep on the hosting device, to make this change remotely, and that we’d physically need to be able to touch the hosting device, to make this change. Otherwise, AirDroid would presumably just plow ahead and do this for us.
After uninstalling this app, I also verified that the setting had not been activated on my tablet, to allow installing packages from outside Google Play. This had not been activated in fact.
But mainly for the two reasons cited above, I do not see how this app would be useful to me in the future.
In addition to owning the tablet, I own an up-to-date phone, and hopefully:
- AirDroid can prevent the phone from going back to sleep.
- AirDroid understands how to access the camera of that device, differently from how it was with the other device’s camera.
Further experiments have shown, that when I tried to establish a remote – i.e. WAN – connection to the sleeping phone, it, too got dropped after only a few minutes.
To follow through on this thought a little more, I next created a completely HTTP, LAN-based connection to my phone, and found that the connection was never dropped! In order to achieve this, I launched the app on the phone, and observed that there are two ways to leave the main screen of the app:
- The Back Button,
- The Home Button.
When we are setting up a standard connection, we are next supposed to use the Home Button, to leave the app running and connected, which seems to work fine. On the phone, even the camera works fine, in LAN-mode! It’s in this mode, that the “Keep Screen Awake” setting makes most sense, as the screen is alit while the session continues.
Problems with the camera function seem to take place, since a recent update, when we try to connect to the device via HTTPS and the WAN (remotely). For LAN access, this mode is typically deactivated.
But if we are asking for the type of remote, WAN-based connection that wakes up our device, then the screen never lights up, and so to set the app to keep it awake, has no effect.
I have learned, that there is a main reason fw the user would be allowed to launch AirDroid remotely, and then conduct some sort of legitimate transaction, before the device goes to sleep: As an anti-theft tool, under “Find My Phone”. But, in order to set that up, we must first enable it on the AirDroid app, on the hosting phone. To do so, we’d navigate our logged-in AirDroid app to the second screen along the bottom, named Tools. Here, the “Find Phone” icon defaults to gray.
When we tap on this icon, we’re directed to an Android settings page, from where we can set the AirDroid app as a Device Administrator, and this icon becomes yellow.
Doing so gives special permissions to the app, including to prevent users from uninstalling it, because it could be a thief who next tries to uninstall it.
(Updated 08/08/2017, 18h50 : )
After experimenting with this app extensively, I’ve come to the conclusion that, as long as I have my portable device in-hand, it will after all be a useful tool to me, allowing me to transfer files from a shared, remote computer, and keeping my device awake manually.
As a potential anti-theft tool, or for sessions initiated remotely, its usefulness is still in doubt.
Apparently, there is an easy fix to my remote (WAN-initiated) session woes! Simply: Disable the ‘Connect via HTTPS’ option, in the Web-interface. Everything works!
This approach even works, when the Apps section of the Settings Panel of each Android device, shows us that the app (AirDroid) is no longer running.
The conclusion I must reach from this, is that AirDroid must use a push-notification system built-in to Android itself, and not leave it up to its own Port Numbers, to be woken remotely. The app then responds to this push-notification, by logging in to the remote server. If the connection is a standard, unencrypted connection, then this defines the session. OTOH, if the app calls back to the server via an expected encrypted connection, then this defines the session.
There is some reason to worry, about allowing a unencrypted, remote-management app to control our devices. Two problems emerge:
- The credentials used by each linked device to call back, and to establish a WAN-based session, may be read by another party,
- The actual exchange of data can be tampered with, as it’s not encrypted, so that instructions can be received by our Android devices, that are strongly counter to our own interests as users.
So I would use the plain-text, WAN-based connection, only as a last resort, let’s say if the phone or tablet really is stolen.
I may have been the author of much of the instability that I’ve been writing about, by setting each app to use an unencrypted connection for its LAN-based sessions, and yet to ask for an encrypted session, to be WAN-initiated, from the Web-interface. Very plausibly, the two parameters need to match.
And, if it was our worry that the app could be tricked into accepting an unencrypted WAN-based session, the logical place to avoid that would be in the app settings, and not really, from the Web-interface.
As it turns out, both the Camera and the Screen-Shot features work in encrypted mode, as long as HTTPS mode has been set, from the app. And this also means, that all my technical issues with this app, have been solved.
(Edit 08/09/2017 : )
What must have been happening, since at first, I had the app set to accept LAN-based, HTTP connections, but was selecting HTTPS-sessions from the (WAN-based) Web-interface, is that some sort of security protocol run by the service providers must have detected an improper login, and terminated each session.
After all, it’s now my assumption that the app answered back to their servers, in HTTP and not in HTTPS mode.
Finally, I expect that the providers of this service keep HTTP and HTTPS, remote sessions on separate servers, so that sometimes during my experiments, I had told their HTTPS server to request a session from the app on my Android device. But then, when my settings were not correct, that session-request never seemed to arrive, presumably because the app was making the connection request to their HTTP-based server.