The writing of this text has three phases: An original 2012 draft that went unpublished, a January 2024 revision and publication, and, much later in 2024, an extension with subsequent 2024 experiences with a newly purchased smartphone.
With these new experiences, I have broken the text into two major portions, one (“2012”) containing the text that resulted from the first two phases and one (“2024”) for the third. I have made no attempt to unify them or to re-edit the first portion in light of the second. References to 2024 in the first portion are, unless otherwise stated, with regard to January, the smartphone that I had in January, etc.
As a general observation, going from 2012 to 2024, smartphones have grown more powerful and have a much bigger screen—but precious few of the 2012 problems have been resolved by 2024. (Something that irks me doubly, as a software user and developer.)
This text was originally written in 2012, but only published in 2024. By 2024, there have been many changes, including that smartphone hardware is on a completely different level, that the many specific comments on user interfaces need no longer apply, and that the degree of e.g. manufacturer customization makes it harder to make general statements.
Nevertheless, there are many lessons that can be drawn, as it matters more what approaches work well or poorly in general than how Android looked in the days of yore. Moreover, chances are that the more general problems still apply, including the poor attitude of e.g. Google. It is certainly still true that life is made unnecessarily hard for users.
Even today, I only make minimal use of smartphones, except for the purpose of tethering my computer for Internet access—and a regular computer is still a far superior alternative outside situations where bringing or using a computer would be cumbersome.
To make a more direct comparison between my current Smartphone and/or “user experience” with their respective 2012 counterparts is hard, as my memory of 2012 is vague and as I have worked so little with the current version. However, I see enabling the developer options, installing F-Droid and using this as the main source of apps, and learning the basics of the ADB-command (to access the smartphone from a computer) as near-mandatory today (I am uncertain what the availability was in 2012). I also strongly suspect that installing some Bash-like command line and/or similar tools would be a very good idea for less casual users with a background in the Unix-verse, but have not explored this area beyond learning that some apps exist.
Hardware-wise, my current Smartphone is far more powerful and has a far larger screen than the device discussed below, but it lacks a keyboard, which hampers input and would make e.g. the use of Bash much more cumbersome. (External keyboards are almost certainly available, but I have not looked into this and they would reduce portability.)
In terms of changes to the below, I have written a 2024 addendum here and there (and made some minor language changes), but not all are from 2024 (or later). Newer will (I hope, consistently) contain the year of writing; older do not. An addendum without a mention of year should be seen as “2012 or thereabouts”.
In mid-2012, I had decided to try a smartphone based on Android—my first cell-phone since around 2007 (and the telephone features, unlike e.g. the Internet access, do not really interest me even now). The choice fell on an xPeria mini pro, which seemed to be a good beginners model. Below I will discuss some of my impressions during the first two weeks of use, with some amendments based on later experiences.
Bottom-line: To root and install better (non-standard) apps, possibly even an alternate image, is a necessity for anyone who wishes to be a serious user. The default setup is so user-hostile, bloatware infested, and limiting that it could easily have come from Microsoft—despite being derived from Linux...
It might be that some of the below problems are solvable through tricks that I have not yet learned; however, if so, these tricks are highly non-obvious and the user does not get any help in learning to do better. Further, the overall sum is too depressingly large for this to be a likely explanation for more than a minority.
To my 2024 recollection, I never did learn such tricks, but this might be because I did not truly push forward and soon re-focused on regular computer use. Similar remarks can apply elsewhere without explicit mention.
I am not at this stage always able to tell what problems pertain to Android, what to the phone used, and what to the service provider (O2). For simplicity, I will rarely attempt to differentiate below and will use “Android” as catch-all; however, the reader should keep in mind that statements made might vary depending on these factors—and that not all problems will be Android’s fault.
All statements refer to the phone in its original installation state, unless otherwise stated. Many problems can be solved by installing better software, rooting, switching to an independent image, whatnot—this, however, is a discussion of what Google/O2/Sony want the user to use. In analogy: Windows does not become a good OS, or Microsoft a good company, because a pre-installed Windows can be replaced with another OS.
My first impressions were very favorable: Except for difficulties due the paradigm change and the time needed to find and start many apps that I could have started in a fraction of the time on a “real” computer, things ran smoothly and impressively.
Unfortunately, this impression did not last long—but soon turned into frustration with the near crippling user-unfriendliness and lack of functionality. Indeed, in retrospect, my original misperception resulted from the extremely limited functionality available. By analogy, a car that only has one control/switch/button/whatnot “drive forward” would be easy for even a child to handle; however, it would also be infinitely inferior to an ordinary car with a steering wheel, gears, breaks, ...
But is not a reduction in functionality needed due to the lesser amount of working memory and long-term storage?
It is, but not to the degree exhibited here. Consider that ordinary computers of yore managed to do more with the corresponding hardware. Further, that the default installation wastes, positively wastes, resources on pure bull-shit apps (cf. below).
By 2024, the smartphones are sufficiently powerful relative 2012 computers that this argumentation would not hold in the first place. Nevertheless, software-wise, smartphones have not caught up with 2012 computers. If anything, it is the software of 2024 computers that have approached the level of smartphone apps, through the limiting attitude of the makers of e.g. MS-Windows and various browsers.
In the end, I can only call this a user-interface disaster: The unfortunate tendencies of UI design that have long been exemplified by e.g. Microsoft are taken to a new extreme and the strengths of e.g. Unix (which by right should dominate UI and software design) are almost entirely ignored.
The by far most used app by me (at the time of writing) is the built-in browser. Unfortunately, it has so many quirks and inefficiencies that I could write an article on that topic alone. To give a few examples:
Tabbed browsing is cumbersome and with no good way to move quickly from tab to tab—and no indication what tabs are currently open. Effectively, the user has to press the menu button, choose “Windows”, and make a choice in the new menu (possibly after having scrolled to even see the relevant entry).
Opening a link in a new tab is not as bad, but still worse than in a regular browser: Instead of the simple middle-click, the user has to keep his finger on the link for several seconds, after which a menu appears with the option to open the link in a new window (with several other choices). This is particularly annoying on pages with a link/article/whatnot overview, where an experienced user will often want to skim through the entire list and open the entries that seem interesting in new tabs. Here a very noticeably slow-down occurs.
As a further annoyance, the number of tabs that might be open at a time is artificially limited: Suddenly, half-way through such a link list, the entry to open in a new window is gone... Yes, mobile devices have less memory available, but the limit is hit unrealistically soon, which makes me believe that the implementation uses an arbitrary, fix cut-off—even when the device actually could handle more tabs. To make matters worse, the corresponding menu entry is not disabled, but removed entirely, which leaves the user surprised as the exact same tap as earlier suddenly leads to a query for adding a bookmark...
All in all, it might technically be more correct to speak of “windowed browsing”, seeing that the word “window” is used over “tab” and that there are no tabs to be seen.
However, on the desktop, tabbed browsing is usually superior and the main way to have more than one webpage open at once. Further, since there does not appear to be any windows (in a conventional sense) at all in Android (but just a series of screen-filling apps), “tabbed” is the more natural word.
Unlike in ordinary browsers, there is no indication of where on the page the reader is, e.g. through a scrollbar. This information, however, can be highly interesting. Notably, it is possible to include this information without losing screen space—as is proved by the mini-indicator that is shown during scrolling. Why not just keep this mini-indicator visible at all times?
Making a very small scroll to activate the indicator is, obviously, an acceptable work-around—but a work-around for a problem that should not exist in the first place, had the UI designers actually thought the situation through.
The menu options are far too few, leaving the user crippled.
Easy navigation to the top or bottom of the page is not present.
It is not obvious when a link has actually been called, the progress bar sometimes not appearing at all or needing in excess of ten seconds to do so—but appearing immediately after a second tap on the same link.
I would speculate that the progress bar only appears after the server has started to reply (or possibly been contacted with a “get” request), but is not shown during DNS and “head” requests. From a technical point of view, this would not necessarily be unsound; however, for a user it is a confusing hindrance.
Worse: If the user briefly switches to another tab and then returns, the old URL is displayed—with the obvious, but faulty, interpretation that the new URL has been forgotten by the browser and has to be re-entered/-selected.
The bookmark view does not contain a way to remove bookmarks... Instead the user has to counter-intuitively go to “most visited” and unbookmark links there. What happens when a bookmark is not among the most visited links (which is quite common—despite Microsoft’s idiotic fiction of “favorites”) is not clear to me.
Partial correction: It is possible to delete bookmarks directly; however, not in the typical manner of clicking e.g. a delete button or in the manner used for “most visited” (tapping a bookmark symbol next to the entry): A prolonged tap on a bookmark brings up a menu with (among others) a “delete bookmark” entry.
While this is some improvement in that it is now possible to delete even rarely visited bookmarks, it is also unnecessarily slow and is very, very sub-optimal for the initial step of throwing out the many (often) utterly useless bookmarks that come pre-installed. (Which I recommend even with ordinary browsers; however, positively urge in this case: The smaller screen and the Android paradigms make the list of bookmarks cumbersome when it contains more than a handful of entries. Further, cf. below, the pre-installed bookmarks on my phone where routed over O2 in an unconscionable manner.)
When the user scrolls, an idiotic and unrelated zoom button appears: There is no reason to assume that a scrolling user wants to alter the zoom; and zooming is better done by other means in the first place.
To make matters worse, this zoom button appears to block scrolling (!), when the user tries to scroll with his finger in the general area of the button. Further, it has happened quite often that there has been a link that I wanted to click immediately beneath the button.
Idiotically, the FTP protocol is not supported—something regular browsers have managed since at least the mid-1990s. Further, there is no indication in the browser that something is amiss when the user attempts an FTP download. The problem is only clear when manually visiting “downloads”—and even here there is no indication what caused the problem.
Equally idiotically, file-system access does not seem to be possible, attempts being met with the error message that a particular directory is a ... directory. In contrast, Fennec (discussed below) does allow access—as does any and all ordinary browsers with even a sliver of self-esteem.
Entirely and utterly inexcusably, activating images does not merely lead to new tabs having images—but retroactively loads images in any already present tabs! (I have images deactivated by default for several reasons, including saving bandwidth, minimizing annoyances in website appearance, and reducing the risk of unethical tracking of my activities.) Obviously, this is contrary to both what a user expects and what he will plausibly want in this situation. I note that there is no good workaround for this misbehavior, while the opposite behavior (if unwanted) is quite easy to workaround through a reload.
Repeated crashes, with no warning, no error message, and no possibility to recover the pre-crash state. The more annoying as these typically occur when they do the maximum amount of damage—when many yet unread tabs are open.
When the last window is closed, simple reason and standard behavior elsewhere would dictate that the app is either terminated or remains running without any open windows. Here, however, a new window is automatically opened with the default page—a behavior so contrary to reason that I would not believe it, had I not seen it myself.
Of course, the possibly single largest annoyance is the problems that arise through the many scroll movements that inadvertently cause a link to be pseudo-tapped—however, this is a general conceptual problem not specific to this app. Further, it is possible that this is more a problem with the touch-display of the phone than with the software (I lack comparisons).
Had the same problem occurred in 2024, I would have been remiss not to discuss a training effect that might have resolved the issue. Back in 2012, my screen (and the typical screen, in general) was so small that at least the main blame must fall on the makers of phone and/or software. (Similar remarks might apply elsewhere.)
Frustrated with the user-unfriendly “browser” application, I decided to try a few alternative browser—and at the end of this experiment, I was so angered by the horrifying, mind-defying user-hostility of the two alternatives that I actually considered throwing my phone at the wall and be done with it...
Opera Mini (or was it Mobile?) lasted no more than five minutes: It had nothing (in particular no extension to the minimal settings of the default app) new to offer, but endlessly harassed the user with useless and annoying animation after useless and annoying animation. (Unsurprisingly, a setting to disable the animations was not present...)
Fennec (the Mozilla/Firefox counter-part) initially gave a far better impression, including having very extensive settings available under “about:config” (while Opera had only minimal alternatives under “opera:config”). Indeed, Fennec might yet be my ultimate choice, especially if the add-ons available prove able to compensate for some weaknesses.
However, there were several major annoyances, including: The arrow keys rarely worked in various text-fields and they sometimes seemed to work (cursor was re-positioned) but did not (pressing any key afterwards restored the cursor to its original position); in effect, the only way to edit a field was to delete every single character and write something from scratch—and seeing that I was constantly using Google to find various work-arounds for Fennec annoyances, this soon became a vicious circle of never-ending frustration. A near unusable overview of the tabs available (with reservations for the existence of some unknown tricks; however, if such are present, major points must still be removed for a counter-intuitive interface). The address bar inexcusably did not show the address of the current page, but its title—something of no use and of great hindrance, and something entirely illogical for an address bar that violates almost twenty years of well-functioning convention.
The latter is a good example of a problem with the mentality of both Opera and Firefox in their standard/desktop versions: They are hell-bent on making “improvements” that in reality make their products worse—and shove these down the throat of the user. (A remedy is either not present or requires research and unnecessary leg-work.) Opera’s idiotic alteration of the standard behavior of a number of keys to include the “fast forward” feature is another excellent example—the feature it self might or might not have brought benefit to the users, but the decision to alter the key-mappings made it highly user-unfriendly—and forcing users to alter each and every key-mapping by hand, instead of just toggling a singe checkbox, made it directly user-hostile. In fact, being exposed to this idiocy for the umpteenth time with a new user account (and therefore the need to make the corrections for the umpteenth time) was what made me finally abandon Opera.
A tangentially related annoyance is that, after the installation of the other browsers, “browser” now insisted on querying with which browser links should be opened—despite itself being a browser and despite it being absolutely clear-cut that if someone clicks on a link (to a HTML page) in a browser, the browser should handle it itself. Not respecting this, is not only illogical—it is a usability disaster, making “browser” unusable when any other browser is installed. This is the more absurd, seeing that installation of an FTP-client (AndFtp) to compensate for the lack of FTP support in “browser” went unnoticed: Every time an FTP link is called in “browser”, it still tries to handle it itself—despite being entirely unable to do so...
A minor, but entirely unnecessary, cause of confusion and a few early mistakes were the idiotic checkboxes: Instead of using the established way to display a checkbox used in most modern UIs (including non-mobile browsers), Android has gone its own way, where a checkbox always contains a “check”. What changes when (de-)activating it, is that the check becomes (de-)high-lighted.
This is particularly idiotic as the new user already has to do a considerable amount of re-learning due to the new concepts forced by touch-screens, limited screen space, and so on.
Further, I strongly suspect that situations arise where e.g. unfortunate light conditions make even experienced users confuse the checked and unchecked versions.
By 2024, homebrewed checkboxes (and other UI elements) have become more common everywhere, including in regular browsers, which makes for similar confusion. The use of colors to indicate the state of a checkbox is a particularly common problem—and different colors on different websites and whatnots, at that. This despite the obviousness of having a checkbox being empty when unchecked and showing a check mark when checked.
(By analogy, would anyone replace the left-/right-turn indicators on a car with a central indicator that used one color to indicate left and another to indicate right? With different car makers using different colors?)
Scrolling is done in what amounts to the wrong direction for someone used to a normal computer. For these, scrolling implies dragging a part of the scroll bar corresponding to the current view port upwards or downwards (with scrolling through page-up/page-down following the same directional convention); in Android scrolling implies moving the document relative the view port—a movement in the opposite direction. While the latter is intuitive in context, it introduces a very unfortunate inconsistency. Indeed, I strongly suspect that the user would be better of with an ordinary scrollbar (or some sort of “scroll handle” which would take up less place than a full scrollbar.
A further disadvantage of the missing scrollbar is that the information it would have provided is also missing: How far into the document is the user? How large is the document relative the view port?
Many of the app names are downright idiotic. Consider e.g. a browser which is simply called “browser”... Such names make it hard to search for support, make informed decisions about alternatives, etc. This is by no means a help for, but a hindrance to, the unskilled user, who is prevented from learning and remains unskilled.
My own experiences with users (not to mention as a user) are crystal clear:
Users benefit from learning concepts, understanding what goes on, seeing the difference between different applications and applications/OS, etc. “Protecting” them from such “complexities” is a bear service. A user should not need to know true complexities, but he should be required to learn the barest basics—and under no circumstances should software makers make life hard for those who want to learn. In an analogy, the driver of a car should not need to learn how the motor functions—but he bloody well should learn when to use what gear, the difference between the brake and the accelerator, etc.
A major annoyance, a clear disadvantage, and a potential danger is formed by the many, many apps that come pre-installed. A few bring value, but most must be written off as some form of “bloatware”—possibly, even de facto malware: No benefit for the average user, no documentation what they do, automatic autostarts, far too excessive rights that potentially make the user an easy victim (and often are not needed for the alleged functionality), ... Notably, these apps are not de-installable without rooting, the autostarts cannot be turned off, and the excessive rights cannot be limited.
Absolutely and utterly inexcusably: Whoever is responsible for this user-hostile outrage should be taken out and shot.
By 2024, the situation has improved in so far as users have somewhat more control and that some built-in sandboxing is present—likely, because the abuse went to such extremes that Google could not ignore user protests. While I have never myself been a victim, I have, for instance, heard of apps that immediately went to the user’s address book and sent recommendations to use the self-same app to all persons listed—in the name of the user.
Note: Working my way downwards, I am surprised to find references to sandboxes even in the 2012 text. I do not remember the scope of these (frankly, had forgotten that they existed), but modern versions have certainly grown stronger.
The first hour or so, was filled with very annoying sounds and buzzes that brought no or only a marginal benefit. Turning these off made life far more enjoyable—and the better decision would have been to have them disabled out-of-the-box. (Or to provide some very obvious and fast way to disable them, say a one-time pop-up querying whether such effects should be allowed.)
For a number of hours, I was frustrated by the attempts of Android to guess what I wanted to write. Its guesses were usually incorrect, often considerably so, and the net-worth was decidedly negative.
While the value and quality of this feature can be discussed in general (others, in particular those who type slower, might see things differently), one aspect is not defensible: Instead of merely suggesting extensions based on what had already been typed, the suggestions quite often altered the already entered text (!)—and did so without giving appropriate notice.
This too is a feature that might be best disabled out-of-the-box. If not, the option to disable must actively be given to the user at an early stage.
At some point between the original writing and 2024, the discussed “market” was re-branded as “Play Store”.
Being strongly deterred by the outrageous conditions for Google accounts, I had to make the tricky choice between foregoing the standard app market and taking the risk of accepting conditions that were not conscionable.
In order to make that choice, I tried to search the market—only to find that even a search was not possible without an account. User-hostile, absurd, and violating a general principle of web development: Restrictions on what a user is allowed to do should only be placed where the restrictions make sense. Cf. a blog entry on the problem of message boards that are afraid of spam block Tor users from reading the boards—where they should obviously only (if at all...) be blocked from posting.
From one POV, this could also be seen as a general principle of software development; however, such a statement would need to be more carefully formulated. Most notably, when it comes to situations involving multiple users, secret data, abilities distributed among certain users or user roles, and similar, the opposite principle should usually apply: That which is not explicitly permitted is forbidden, information is on a need-to-know basis, and so on.
Additionally, this does not make sense from a business POV: What if a regular store would prevent prospective customers from entering the store before they had agreed to provide their billing information? Obviously, there would be many customers who did not even bother to enter the store...
A plague of my work with “browser” (I am uncertain whether this is app specific or a global issue), is how the zoom function is tied to double taps. In my case, these double taps are invariably not intentional—indeed, they occur even when no reasonable algorithm would see a double tap.
A very common scenario is that I change the zoom by pulling out a piece of text with my fingers—and the zoom immediately snaps back to the original position when I remove my fingers from the screen...
It is possible that I misinterpret what happens: Another possibility is that the normal “zoom with fingers” function considers the zoom temporary under some set of conditions, e.g. some timing in the removal of the respective finger from the screen. However, if so, corresponding points have to be deducted for a counter-intuitive and poorly documented interface.
It is unclear when a process is ended, what processes are currently running, and there is no good way to swiftly move from app to app. The built-in “wannabe manager” is near useless.
So far, barring individual exceptions, I have not found any way to terminate an app from the app it self (e.g. through a “close window” button or an “exit” menu entry). The consequence is that apps not currently needed keep on running, wasting resources that could have been better used.
(2024-09-12)
During my recent new experiments, I have searched for a 2024 solution—none appear to be present. (Instead, even now, the user is relegated to alternatives outside the app.)
The above “wannabe manager” presumably used scare quotes, and was not an attempt to indicate the name of the corresponding app or whatnot. That is: there is something that, by whatever name, pretends to be a process manager, but which is so useless that it does not deserve to be so considered.
Android has a crippling lack of file access—turning the possibly greatest strength of Unix (the ease with which generic applications can cooperate and interact through files, pipes, and text) into the greatest weakness of Android. Even backups and the like require rooting (or, possibly, some non-default app that I am not yet aware of—but this would be odd in the light of the extreme usefulness of such an app and the many entirely useless apps that are installed; cf. the corresponding section).
To some degree, this can be justified by the “sandbox” concept used to prevent applications from overreaching themselves. However, at a minimum, there should be some privileged, user-only tool with full access to facilitate the user’s work (e.g. a small CLI or a file manager). Further, the sandbox could remain unthreatened, if the user was given the ability to selective grant apps the right to access specific directories.
Further, considering the number of pre-installed bloatware apps with insane rights that are present to begin with, the benefits of the sandbox seem limited—like having a steel door with three locks next to an open window, easily reachable from the ground and large enough to let a grown man through.
More generally, the user has too few rights and possibilities. Among the most glaring and hard to defend left-outs are the rights to de-install the pre-installed applications, to limit the rights of apps, to decide what apps are started automatically, and (as discussed above) to access the file system in an appropriate manner.
This state is not conscionable: The phone belongs to the user and he must have the right to do whatever he likes. This is my phone—not Google’s phone, not O2’s phone, and not Sony’s phone.
Indeed, I would strongly encourage legislation that the owner of any hardware (including smartphones and game consoles) has a non-negotiable right to do whatever he likes with the hardware, without any artificial restrictions, be they legal, contractual, or technical. (Where “legal” refers to regulations directly relating to hardware, use, ownership, whatnot, but not including cases where the use would be illegal through other mechanisms, e.g. as a murder weapon.) This would, in particular, include full administrator rights (not with the default account, however) and the right and opportunity to install any alternative system on the hardware.
The trend between 2012 and 2024 has, unfortunately, gone in the other direction, with commercial operating systems and whatnots trying harder and harder to limit the users. If it was up to e.g. Microsoft, users would never change settings, install “unapproved” applications, whatnot. This while some application softwares, including Firefox, seem set on removing the flexibility that they once had.
My experiments with the email client have been short but very dissatisfying: The UI is severely lacking (but my memories too vague for more specific statements—apart from the thoroughly idiotic placing of the button to load more messages at the end of the message list, forcing the user to scroll down the entire list, click on the button, and then scroll all the way back to actually see the messages). The configuration is uncooperative and insists on making ridiculously poor guesses as to what servers, ports, whatnot, should be used—better leave this to the user, who actually knows what they should be. (Or, if he does not, will only be more confused and unknowing after the attempts to “help”.)
It is not clear to the beginning user when a setting has been saved and when not. Based on later experiences, it appears that Android follows the inferior every-change-takes-effect-at-once paradigm, instead of the superior OK/apply/cancel paradigm.
Having a phone with a physical keyboard is a definite benefit; however, this benefit is not used like it could: Most apps do not appear to have any support for e.g. short-cuts. The layout deviates unnecessarily far from a standard computer keyboard. Even after switching (my German phone) to the international layout, the y- and z-keys follow the German convention (they are switched relative their positions on a English/US keyboard)—which makes life tricky for someone used to typing blindly and to mentally make the adjustments y->z and z->y whenever looking at his keyboard.
I use a US keyboard mapping on regular computers, but all keyboards to be normally found in Germany have a German (physical) layout. In those odd situations where I do look at the keyboard, e.g. when typing a new password, a mental adjustment of the keys is necessary.
The pre-installed bookmarks are all routed over an O2 server, implying both increased waiting times and a danger of O2 spying on its users in an unconscionable manner.
Some functions for (at least) input, e.g. marking of words, are local to the current app, when they should be global. There is no sense in app after app re-inventing the wheel in slightly different manners.
On the top of the phone, there is a status/notification bar/dropdown with several weaknesses, including: Always remaining in sight, wasting screen space. Opening on drag instead of tap, implying that a scroll in a browser window can easily lead to the status bar suddenly filling the window, while the scroll is lost. (Generally, there are many “drag” actions that might have been better implemented as “tap” actions; however, there might be circumstances that legitimize some of them—e.g., hypothetically, that a tap-to-unlock would risk too many involuntary activations compared to a drag-to-unlock.) The “clear” functionality does not clear all notifications, but leaves some (at least update notifications), in place.
I note that while updating has some obvious advantages, it also takes an unspecified (but likely large) number of MBs out of my reduced-speed-after-300MB pseudo-flatrate and risks reducing my later ability to root or use an alternate image. This not to mention the risk that functionality is reduced, that alterations to my data take place, whatnot—as has already happened to those allowing updates to iPhones, xBoxes, and similar. Correspondingly, it is user-hostile to pollute the status bar with an update notification after a “clear”—either the user wants to update or he does not.
Due to severe problems with the USB-socket (or some other USB issue) with my then smartphone, I bought a new one at some point of 2024. (In the hope of improvements from a new socket, in general, and an upgrade to USB-C, in particular).
Some remarks, accumulated over a month or two of setup and use follow. In many cases, the text has been written weeks later based on keywords. Corresponding reservations for details apply.
As already remarked, most big-picture problems of old still remain, including that some of my first actions with the new smartphone involved disabling unnecessary buzzing and whatnot. (For more detailed problems of old, including the misbehaviors of some individual app, I can usually only speculate. This, in part, because I have not necessarily used these apps with my new phone; in part, because there is no guarantee that an app with some given, hyper-generic, name actually is the same app with a higher version—it might be an entirely different app given the same hyper-generic name because it fulfills a sufficiently similar purpose.)
First and foremost, of course: there are still tons of useless/bloatware/malware apps that have to be manually disabled/removed—and this is not always possible through standard mechanisms.
On the upside, ADB and commands (issued from a connected computer) like adb uninstall [package name]
give some flexibility even without rooting. (This might or might not have been possible in 2012. There might
or might not be some similar command-line access/means on the phone it self.) A severe issue, however, is that
the package names needed are obscure and do not necessarily have anything to do
with the names displayed in the GUI of the phone. Effectively, the user needs to do an Internet search to
figure out or confirm the package name before attempting the deinstallation.
Below, formulations like “cannot be deinstalled” refer to the obvious and phone-internal means. With the corresponding additional effort, ADB can likely override these; however, I have not yet performed deinstallations beyond a single test, and can make no guarantees. (I have lacked the time/energy and have some fear of accidental deinstalling something which breaks the phone, because there appears to be fewer checks for dependencies and whatnot with ADB.) Likewise, claims about what cannot be done in other regards refer to pre-installed and phone-internal means, without ruling out that third-party apps, ADB, or some other means yet might provide a solution.
Apart from the unethical and user-hostile practice of bloatware, systems can easily become overloaded with too much of even (more or less) legitimate software. Likewise, it is not a given that the default preferences for apps of the one matches those of the other, and default installations bring a risk of pushing certain apps into near monopoly positions, as has been the case with (once upon a time) Internet Explorer and (more recently) Chrome on regular computers. A better approach is exemplified by some (regular) Linux distributions, which begin with a minimal system and are then extended, by and by, from official repositories, with the software, and only the software, that the user actually wishes to have.
The (built-in) list of apps contains no information about what any given app does, from where the app comes (Google, phone maker, whatnot), and other information that could help in deciding whether apps serve a legitimate purpose. Mostly, they do not have a legitimate purpose, but the “Gboard” is an interesting counter-example. This near-central app, which provides a virtual keyboard, could be disabled and there was no indication that doing so might be harmful (beyond the blanket panic-mongering message that comes when attempting to stop any app), nor that it might be a good idea to install an alternate virtual keyboard first, nor, of course, that “Gboard” was a keyboard and not some random pointless bullshit.
I disabled it—and later, when first trying to enter text, found that I had no means of doing so. There was a mechanism for voice input; however, to use voice input, I would have needed (at least, with pre-installed tools) to perform various Google activations and registrations, which I am certainly not willing to do. (And might not have been able to do, absent the prior ability to enter text.) Moreover, chances are that whatever I said would automatically have been exposed to Google, with a horrifying privacy breach as a result.
The aforementioned voice-input app (“Google Voice Typing”), which I likely will never use, in contrast, could not be disabled—the exact opposite of a reasonable expectation. (And why was there no means of choosing/enabling/disabling these two apps from the input dialogue/whatnot that opens when entering an input field?!?)
I am tempted to say that this is the more absurd, as voice input is so obviously less central; however, I strongly suspect that Google (and/or some other party/ies) are deliberately pushing voice input as the future main or, even, sole option.
Indeed, my first suspicion upon encountering only the voice input, and having no option to activate other alternatives from the input fields, was that Google had simply killed the keyboard app and/or not installed one per default in order to force users to switch to voice input. Fortunately, this suspicion was incorrect.
(Here we see another argument for physical keyboards, as with my 2012 phone.)
More generally, various displays and lists are often nothing more than entries without additional data and explanations, which severely limits the users. For instance, why is such basic information as the size of a file rarely included in a file listing? (Be it per default or at all.)
Other quirks include that the app selector allows filtering by all/installed/disabled—but not enabled. This despite the potentially great interest and, especially, how helpful this would be when going through the enabled apps to find out which should be disabled.
Another enforced-but-pointless-to-me app is “Digital Wellbeing”, which has no core functionality. In as far as it brings a benefit, it would be better solved by some third-party add-on. I would never use it, even where I an intense smartphone user. As is, I use my smartphone mostly to provide my computer with a cheap Internet connection—for which this bullshit is pointless.
What does it do? Well, with some reservations for lack of information, it seems to aim at telling the user that “You have used your screen for 30 minutes today! Stop now—or you will die a horrible death!”.
This lack of information, however, is telling in it self: Why is there an app on my phone for which I cannot even find out what it does without searching the Internet? For which even the Internet hits that I found were very vague? And why is it the same shit with app after app after app?
Many apps, including the aforementioned “Digital Wellbeing”, come with a plethora of rights, over which the user has only a limited overview and which are hard to influence. For instance, there is no central switch to revoke all rights for notification or data use (to be re-granted where actually wanted)—instead, each individual app must be individually re-configured.
To make matters worse, not all rights seem to be fully available for the user to reconfigure.
A particular absurdity is the number of apps that are allowed to access the Internet, control WiFi, and similar—most apps simply do not have any legitimate reason to perform such actions. A further that there seems to be a standard setting to prevent background access of the Internet by apps, but the support for at all and foreground is much scarcer.
The previous entry is a special case of the phone having too many weaknesses, with very little ability for the user to know which exist and when they have been effectively removed or deactivated. For instance, even after spending significant time going through various settings, I do know whether my privacy will be respected or data pushed to Google or some other party behind my back or when/whether some app will suddenly decide to download data (e.g. an update) that brings me no value, but which cuts into my monthly data contingent.
While I have little reason to actually add personal information to my phone, such questions make me even less likely to do so—and it could severely limit the use of a smartphone as a notebook replacement during travel.
Right at the beginning, I was met by a series of “choice pages” (for want of a better word) to set up this-and-that and to agree to overly long, unreadable user-agreements only available long after purchase. Unacceptable: Firstly, pushing such agreements after purchase is unethical. Secondly, there are no impositions on me that can reasonably be demanded, no concessions (e.g. “Yes!!! You may steal all my data, profile me, and spam me on a daily basis!!!”) that I could reasonably be expected to give, etc. (On the outside, some limited restriction in manufacturer liability might be acceptable.) Thirdly, this is my phone—period. I have bought it, it is mine, I should be able to do whatever I want with it, and the maker of the phone, the OS, the whatnot, has nothing further to say or do.
As to what the EULAs and whatnots did contain, I do not know, because they were simply too long to read in a conscionable time frame. (An ever-growing problem in today’s world, more generally.)
In the overlap between the above issues and the “too long to read”, I simply consider them null and void, and will, in the unlikely event that it becomes necessary, defend that position in court.
A particular (but by no means sole) point is that such post-purchase EULAs put the user in an entirely unconscionable situation. If he does not “agree”, he cannot use the phone, which implies that he has either wasted his money or is forced to jump through hoops to return it and get his money back from the seller. Alternatively, he could root the phone and install another operating system from scratch, but this takes non-trivial knowledge, can fail because the phone at hand is not supported, and risks a “bricking” of the phone. (While this would be the best approach, as it gets rid of most bullshit in one stroke, it is one resisted by the phone-industry. Cf. a below side-note.)
While I do not remember the exact dialogues to answer, I do remember that they took a chunk of time, despite my, mostly, picking a “later” option over the Android-intent that I laboriously go through all details in one go. I also remember that sensible options like “block any and all phone-home functionality”, “only allow Internet access upon individual permission”, and “do not allow any automatic updates” were not present. (And do not appear to have any corresponding entry in the settings either.)
At some point, a “T-Com App Selector” appeared, seemingly out of nowhere, trying to force me to do something or other (due to time passed, I do not remember what), and left a notification behind that could not be removed until I force-stopped the app.
There are a number of question marks around this, including from where the app came in the first place. At the time, I assumed that somehow, in some highly unethical and should-not-be-technologically-allowed manner, T-Com had pushed this app onto my phone, as I use the German T-Com network. (If so, it would be one of the greatest horrors that I have ever encountered, absolutely and utterly unconscionable, inexcusable, and indefensible.) After some subsequent reflection, it seems more likely that the app had been pre-installed and somehow merely activated based on network, which, while bad enough, is not the same disaster. It also raises questions like why specifically T-Com and what other similar apps might be hidden somewhere out of sight for other networks.
While I do use the T-Com network, this is coincidental. The phone was bought stand-alone, with no noticeable connection to T-Com, and without any type of tie between me and T-Com by, say, a sign-up-for-an-excessive-24-months-and-we-knock-a-trifle-off-the-price contract. (In fact, I use a prepaid SIM—and the same one with both the new phone and its predecessor.)
I might equally well have been, or at some point in the future be, with one of the other networks.
Notifications are notoriously hard to get rid of. Even going through and disabling the right to notify, notifications appear. Even after clearing the list of notifications, notifications remain. Even when in “do not disturb mode” notifications are made. Etc.
As I have subsequently discovered, some notifications not removed by clearing can be removed by “swiping” them to the side. (While a more intuitive means, like a close button, is absent.) Whether this applies to all or just some notifications (in particular, the aforementioned, already removed, notification from the “T-Com App Selector”) I do not know.
Making a comparison with a regular computer (Linux or otherwise), there are some types of notifications that can be justified, including for missed calls and incoming SMS, that do not apply to a regular computer, and some, e.g. for an incoming email, that apply to both. (In all cases, assuming a corresponding configuration.) Beyond these and, maybe, some similar cases, there really is no justification for notifications. Nevertheless, notifications abound, likely because Android provides an easy mechanism and app writers jump at the opportunity to abuse this mechanism.
For the sake of precision: I use “notification” to imply those (mostly) pointless and annoying messages that appear in the top drop-down. That a dialogue opens to e.g. give the user the option to grant or deny a certain right can be more acceptable, provided that the user is interacting with the app at hand, and with reservations for the exact nature of the dialogue. (A hypothetical dialogue to “Please click here to register online!” would almost always be unacceptable. A background application would only have a legitimate reason to request a right under exceptional circumstances.)
Making backups is unnecessarily hard, complicated, and error prone. There is no on-board equivalent to
e.g. rsync-ing portions of a file system to a backup drive. (Yes, an rsync can
be installed, but this is beyond most users and comes with the complication of
figuring out what needs to be backed up in the confusion that is Android. To boot, I suspect that I
will, when I get around to it, also need a SSH-demon for reasonable use. To boot, there might be
issues if a restore-from-backup is needed, as, cf. below, idiocies might apply.)
The backup command of ADB is marked as deprecated, is slow, lacks transparency, and
does not allow later individual file access in the backup (without considerable hoop jumping). To boot,
I have heard reports of vital information being left out and/or not being restored when a restore-from-backup
is attempted. (According to other reports, apps might have some means of refusing inclusion in backups, which
is both insane and user-hostile.) This while the push and pull commands do not even support
wildcards and proper recursion; and while the ability to properly mount the phone on a computer has been
lost ages ago (likely, even before my 2012 adventures).
Chances are that user should, in the long term, be forced to do only cloud backups under the control of Google, and, thereby, become even more power- and helpless, lose control over his data and privacy entirely, etc.
Greater flexibility can be found by activating the “developer options”. (But note that “greater” does not imply “great”.) I did this as a matter of course, but found a considerable worsening in the interface relative my old phone: There was now an over-large button floating around, positively begging to be accidentally clicked, to deactivate the developer options. Early on, I actually did accidentally click it—and found that half of the developer options that I had already set had (a) been re-set with the deactivation, (b) were not restored to my preferred values upon reactivation. Inexcusable!
Many pages seem to continually load, without apparent end and without an indication of what might remain of the page, when the user scrolls down. Even in an Internet-setting, this is user-unfriendly and highly sub-optimal compared to a reasonable paging (if need be, combined with tabbed browsing); however, with the Internet, and the potential delays and bandwidth waste from a premature loading, I can at least see the idea behind it. Outside the Internet (and similar networking/whatnot scenarios), it has no justification.
I repeatedly found myself unable to (explicitly) disable some things, because they were already disabled for some indirect reason. I failed to make note of a specific example, but say, for illustration of principle, that it would be impossible to turn off a lamp after a fuse has blown. The switch is there, but when the user tries to operate it, it is stuck and a pop-up comes to complain that “Cannot disable lamp, because lamp is disabled by a blown fuse.”—and never mind that the user might legitimate want to explicitly disable the lamp so that it does not turn on again, if and when the fuse is fixed, or because the off-state is preferred more generally.
During installs with F-Droid (see an excursion for basic information), a virus scan takes place, which might or might not be acceptable as such. (At a minimum, the user has too little control over what happens when and how.) However, after the virus scan, the user is given some option to “return to whatnot”—and picking this option moves him to some other app installer than F-Droid!!! (Presumably, one preferred by Google or the phone maker, as opposed to the one actually in use.)
As with older versions, it is often too easy to click on something. I particularly have the problem that when I have a list of some sort, e.g. in the settings, and just put the phone down, some accidental touching at the very border of the touchscreen causes one of the entries to be selected. Often, it is not clear what portion of the screen is connected with some choice/action/whatnot and which is just a passive display.
I have reason to suspect instances of illegal data access, as my “data balance” dropped much faster in the first week of ownership than it normally does, and without (to my recollection) any other actions that could have brought on such a drop. Later, the same drop has not repeated, but an installed surveillance tool (“Data Monitor”) alleges some unwarranted uses, including by VLC (a media player that I, on a normal day, only use to play background noise on a soundbar)—clearly, VLC has no legitimate reason to access the Internet without explicit prompting by the user. (I have some hope that Data Monitor is over-ambitious and includes Bluetooth traffic, which would be legitimate to send data to the soundbar, but, with my current tools, there is no way to tell.)
On several occasions, the “Browser” application has been started without permission and prompting, without indication of what application was running, and with no obvious means of closing it. Likely, this is because some other app decided that I should view some web-page or other, and just proceeded in an attempt to open it (unethical and user-hostile—any such attempt should be entirely transparent and left to the users wishes). The first thing that “Browser” wants to do, however, is to perform various configuration steps, which I have not performed, because I have no intention of ever using it. Worse, since such attempts to call web-pages are disproportionately likely to occur during early setup a great many others, who might be open to using “Browser” at a later date, might still be caught in this setup dialogue while actually trying to something entirely unrelated.
A common problem, exemplified by the previous item, is that is often hard to tell where one is, what tool/app/whatnot one is currently interacting with, etc. Consider the aforementioned virus scanner issue: I click on something in F-Droid, suddenly find myself in a virus scanner of unknown provenance, click on and suddenly find myself in the wrong app installer—and with no way of telling that this is the case except from a change in look and feel. (There is much good to be said about the traditional window bars of a regular computer—which, of course and in yet another misdevelopment, are in the process of disappearing.)
I have to some degree looked into alternatives (both in 2024 and 2012), but have not pushed it very far, as, again, my main use of the smartphone is to access the Internet from my computer. Moreover, the true solution is unlikely to ever happen, barring an unlikely legal intervention—that phones are sold pre-rooted and set up for easy installation of the OS or whatnot of the user’s choice.
Apart from the pragmatic benefits for the user, this is the only ethical approach to selling hardware.
However:
Various parties prefer to keep control with them instead of the users, no matter how user hostile and unethical this is, and are unlikely to voluntarily surrender this control.
On the contrary, even with regular computers, the situation has worsened, in that e.g. a user of MS-Windows on a computer is increasingly left at the whims of Microsoft. (And, in an inexcusable scandal, the year is 2024 and it is still hard to find a computer that is not pre-infected with MS-Windows, MacOS, or some other user-limiting bullshit—for which the user, then, must pay, even should he immediately proceed to install a sane OS.)
Apparently, there is a great deficiency in standardization of hardware interfaces and whatnots, which makes it much harder to provide third-party system software than with a regular computer.)
However, the F-Droide app-for-installing-apps is a must for those who stick with Android, in order to allow the installation of more user-friendly, less invasive, whatnot, apps—and apps that do not meet the often user-hostile limitations of Google.
I have installed several helpers from the F-Droid repositories, including Termux, which gives a reasonable command line on the phone, it self, and AnLinux, which allows the running of actual Linux distributions on the phone (but I have yet to actually test this).
Full Android replacements exist, notably LinearOS, but I cannot speak in detail about what it brings and what is necessary to consider. A particular complication is that not all phones are supported, implying that this option is not open to everyone and/or is an option that should be considered before the purchase.
(CyanogenMod used to be the go-to replacement, but did not last. LinearOS, IIRC, is one of its descendants. Back around 2012, I tried to install CyanogenMod on my then phone, but failed.)
As with many modern computer issues, the help or “help” found on the Internet is usually useless. I have, e.g., had countless scenarios where I go through all the obvious menus without finding any, or only finding a partial, solution; turn to the Internet for help; and find instructions on how to go through the exact menus that I have already tried. (The authors, apparently, consider their readers too stupid to go through menus on their own; and/or, themselves, have no ability/knowledge/whatnot that goes beyond the menus.) What might then be found is a non-solution that I have already tried, a partial solution that I have already implemented, or references to settings that are simply not available (maybe, due to version differences) but which I, of course, would already have tried had they actually been there.
To make matters worse, the search result might give an endless list of pages that promise to solve the problem—all of which appear to go through the same steps that all the other pages also give, thereby rendering the vast majority of the pages redundant. More generally, restricted neither to Android nor to computers, there appears to be a hundred redundant pages/tutorials/introductions/whatnot that describe the same elementary matter for every one that goes into some depth, tries to explain concepts, gives tips that are actually useful for the non-beginner, or are otherwise not just another pointless and redundant waste of the reader’s time.
While this, to some degree, speaks in favor of menu quality, the greater explanation is likely that software has become too limited in what settings are available, what users are allowed to do, etc. Here, we can even have a negative influence from menus, in that options and actions might be artificially limited in order to keep menus small enough. God forbid that a user would actually edit, or even have, a config file—despite the decades of positive experiences of Unix-verse users, before the extreme focus on GUIs began to kill the config file.
But those within the Unix-verse who stick to older tools or tools in an older tradition can do quite well with command-line use, config files, problems that actually have a solution, etc. At least privately, it is very rare for me to need to engage with user-hostile GUI-bullshit in the “Yay, desktop!!!” vein.
For the time being, I do not foresee non-trivial updates on the smartphone under discussion. (While any later smartphones are likely to receive an own heading.) However, I open this excursion for what minor remarks might be beneficial.
January, 2025: The Internet connection of my phone spontaneously failed, with no discernible error message or error cause. No options to restore the connection appeared to be present, forcing an otherwise unnecessary reboot. After the reboot, the connection worked again, but the tethering with my computer did not. This even when the corresponding (minimal) status information indicated that tethering was active and, almost needless to say, even while no error message was presented. Only after I turned off ADB debugging did tethering work again. (Android appears to maintain the fiction that ADB and tethering cannot be used at the same time, which is belied by the fact that I have them active at the same time as a matter of course. An artificial block when ADB is activated before tethering might be a symptom of this fiction—while activating tethering first and ADB second works perfectly.)
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.