Smartphone Newbie’s Extensive Guide to TracFone Samsung Galaxy Core Prime S820

I was looking for an entry-level, pay-as-you-go smartphone. This post describes the process I went through in choosing and setting up the Samsung Galaxy Core Prime S820L smartphone from Walmart.

This post includes some descriptions of my own learning and experiences, from the process of acquiring and learning to use this phone. That can make the story a bit longer in spots, but also more relevant to some users. Some of my steps contradicted each other, as I learned more about different options. For example, improved functionality could mean reduced battery life.

For purposes of simple setup and use, Geek Squad UK appeared to offer a good guide. This post was focused more on complications and possibilities beyond basic usage. It is a long post — but, of course, the list of Contents (below) and the usual finding options (e.g., Ctrl-F in Windows) still work.

I have organized this account into topical sections, and those sections do roughly reflect the order in which I did things. But in some instances I had to go back and revisit or expand a topic that I thought I had already taken care of; and in other instances, there was enough confusion in the process that I opted to just write it up where I was, even if the new insight or experience would arguably have been better handled by building it into some other section. These episodes have doubtless added some discontinuity into the writeup. Hopefully the account does seem relatively clear regardless. But I should emphasize that, in some places, useful and even important tweaks or adjustments can be buried in a section that seems to be about something else. If I ever did a reinstall, I would probably go back through the whole process in a more streamlined manner, as I had done in previous blog posts regarding Windows and Linux installations on the PC.


Background & Terminology

Choice of Phone and Initial Setup

Operating System Upgrade


Basic Phone Functionality

Tweaks and Tools


App Selection

App Installation & Uninstallation

Hardware & Accessories


Background & Terminology

I had an existing TracFone subscription and wanted to carry over my existing minutes from that to my new phone. I discovered that TracFone’s online chat operators would be able to walk me through that transition and make the necessary changes, once I had the phone. TracFone listed a variety of phones compatible with AT&T, T-Mobile, Verizon, and others, and also offered the option of buying “an AT&T or T-mobile-compatible SIM card from TracFone” for an “unlocked” cellphone.

I liked the idea of an unlocked smartphone. “Unlocked” meant that the phone would not be tied to a specific company. Blinq explained that this was different from a “no contract” phone. No contract meant that you could buy the phone without committing yourself to a (typically) two-year contract requiring monthly payments for continued phone service. You would buy the unlocked phone; you would choose which cell service company you wanted to use; then you would buy a contract or, in the case of a company like TracFone, you would just buy minutes. For an unlocked phone, TracFone provided a warning:

In order to connect to the TracFone 4G LTE network, your device must operate on Band II, IV, or in certain areas, Band 12. For 3G or other 4G service, your device must operate on Band II (1900 MHz) or IV (1700/2100 MHz). GSM devices that do not support these bands may operate at 2G (EDGE) speeds.

I was not especially familiar with this terminology. It turned out that GSM was the principal alternative to CDMA, “the two major radio systems used in cellphones” according to PCMag, which also said that CDMA was used mostly just in the U.S., and there primarily by Sprint, Verizon, and U.S. Cellular. So here, again, it seemed that TracFone leaned more toward AT&T and T-Mobile. But Wikipedia said that TracFone actually had agreements with all of the above — and also that TracFone was the owner of other brands I had heard of (e.g., Net10, Straight Talk, Page Plus, Walmart Family, GoSmart), and was actually owned by TelMex (i.e., Teléfonos de México), chaired by Carlos Slim, presently 7th richest in the world.

As for that language about Band II and 4G LTE, Wikipedia explained that 4G is rather obtusely obvious shorthand for “fourth generation,” referring to the current generation of mobile telecommunications technology. 4G has peak speeds of 100 Mbit/s (megabits per second) for high mobility (i.e., from trains and cars) and 1 Gbit/s (gigabit) for low mobility communications (e.g., pedestrians). LTE, commonly marketed as “4G LTE,” does not actually meet 4G standards; that terminology is apparently allowed partly due to political pressure on the International Telecommunication Union (ITU) and partly because LTE is a significant advancement from other 3G technology. Either way, TechAdvisor said that consumers don’t actually get 4G speeds, even if they have 4G phones, because other links in the telecommunications chain are subpar. The more realistic benchmark is just that 4G tends to be significantly faster than 3G.

The “bands” in that TracFone quote were just radio frequencies. PrepaidPhoneNews offered a list of which bands were used by which mobile operator (e.g., T-Mobile, AT&T). Evidently the Roman numerals were unnecessary; Radio-Electronics and Wikipedia listed LTE bands 1 through 44, specifying frequencies for each. Band 2 was in the range of 1850 to 1910 MHz for uplink and 1930-1990 for downlink; Band 4 was 1710-1755 and 2110-2155; and Band 12 was 698-716 and 728-746. It seemed the TracFone quote was written rather confusingly in these regards. The point seemed to be that, regardless of whether you wanted to use TracFone 4G LTE or some other 3G or 4G service, in most places you would want a cellphone that used band 2 or band 4.

So it seemed I could buy a phone from TracFone, and carry my old minutes over to it, or I could buy a phone from someone else, and TracFone would help me set it up. The phone would need a subscriber identification (or identity) module (SIM) card. My old TracFone had one, of course. I wasn’t sure whether I would have to use it, in order to carry over my minutes and any remaining voice mail messages from the old account. It turned out I didn’t: the new TracFone that I bought from Walmart had one, and the minutes came over without it. Wikipedia said that the data contained on my old SIM card would have included certain identification numbers, as well as location and authentication information necessary for interaction with cellphone towers and networks — and may also have included SMS (text) messages and contact information. A TracFone representative had assured me that my old voice mail messages would be preserved, as long as I bought the new phone and transferred the service by a certain deadline; but now another TracFone representative told me that there was no way to preserve those old messages, and that they were gone.

If I had wanted or needed to use the old SIM card, or for that matter any alternative SIM card, there were a couple of things to consider. The new phone needed a microSIM, which was smaller than the standard-sized SIM from my old phone. Apparently everyone knew that you could just trim away that extra plastic (or buy a SIM card cutter) so that the standard SIM would fit into a microSIM slot. Another option was to buy a microSIM (or standard, or nano SIM) card from TracFone. When I looked into that, I saw that TracFone had run out of microSIMs. But apparently that was only temporary: they had them back in stock, and were selling them for $1 each, when I looked again, a few days later. At that price, I’d have been tempted to buy a spare one. I saw a number of remarks by travelers who said they had to swap SIMs whenever they traveled, to connect with cell networks in other places (abroad, especially), or else buy a phone that would hold two SIMs. Forbes said the second SIM would also come in handy if, say, you had problems on your primary account and kept that second account (using something like TracFone) as a backup. CNet considered other scenarios (e.g., keeping work and personal lives separate).

I wouldn’t have minded having a second SIM card, though I didn’t really need it. The alternative of just swapping SIM cards did not seem feasible for the Samsung phone that I will be discussing in more detail below. At first, I didn’t even know where the SIM was. I had to take a closer look to see that bit of white plastic underneath the separate slot for the Micro SD (memory) card. Once I found it, I couldn’t slide it out. It seemed to be stuck. It appeared many others had this problem. One source recommended using a sewing needle to pry it out, very carefully so as not to damage anything. Other suggestions were to use a pencil eraser or opened paperclip to push it out, or to stick some tape on it and pull. Some actually speared it with the point of a sharp knife, so as to get enough traction to pry it out. Anyway, someone said that using the old SIM could cause problems. I decided to just toss it into a bag for possible future use.

Choice of Phone and Initial Setup

I searched and read a bunch of material on the advantages of different phones. Someone recommended PhoneScoop as a particularly good tool for choosing a phone. By whatever process, I wound up focusing on the Samsung Galaxy Core Prime. I read through many reviews and other materials for this phone and others. Prices varied: for example, $129 through Amazon, $69 at Walmart. That was a little puzzling. If I had been buying a TV or a computer, I would have assumed that, by the time you’ve used three increasingly specific names for it (i.e., Galaxy Core Prime), you have probably reached the point of talking about a specific model. But for smartphones (or at least Samsung smartphones), that is not necessarily the situation.

A search for “Samsung Galaxy Core Prime” actually turned up a number of different models at Amazon and in Google Shopping. It now seems that a used one at eBay, unlocked, would cost about as much as the new one from Walmart. And then, to confuse things a bit more, what I ordered from the Walmart website was model S820C, but according to the box what I actually got was a S820L. Samsung’s own specifications page gave no hint as to any of this. It just said that this was a “Prepaid/No Contract” phone. From comments by users at Amazon and elsewhere, I had thought this was also an unlocked phone, but that was not the case. Here’s what I read on the actual box I received from Walmart:

TRACFONE PHONES ARE SOLD BY TRACFONE EXCLUSIVELY FOR USE WITH TRACFONE WIRELESS SERVICE. By purchasing this package or by purchasing any TracFone phone, you agree to the latest Terms and Conditions of Service available at which, among other things, specifically prohibit reselling this phone; tampering with, unlocking (except in accordance with the TracFone Unlocking Policy), reflashing or altering the software or hardware in the phone; exporting this phone . . . . TracFone will prosecute violators to the full extent of the law. . . . IF YOU DO NOT AGREE TO THESE TERMS, DO NOT PURCHASE THIS PHONE OR RETURN IT UNOPENED TO THE PLACE OF PURCHASE, PURSUANT TO THE RETAILER’S RETURN POLICY.

I didn’t have the option of returning it unopened: mine had already been opened before it arrived on my doorstep. Possibly Walmart saw this online purchase as an opportunity to unload one that someone had opened and returned to one of its stores.

I did not investigate this in detail, but a Federal Communications Commission (FCC) webpage seemed to say that federal negotiators had compelled TracFone to offer an unlocking option. That page provided a link to a page, not located on the main TracFone website, that offered unlocking only if the device had been activated on TracFone for less than 12 months (among other conditions). That page was also available through an “Unlocking Policy” link on a TracFone FAQs page. There seemed to be other ways to unlock such a phone. I did not know whether use of those other means would work, or were still subject to prosecution, or how likely such prosecution would be. In any event, I was not entirely sure what the differences might be, between the model S820C that I purchased and the model S820L that I got.

When the phone arrived, it came with a mildly confusing selection of printed guides. There was a Services Guide and a Quick Reference Manual — and also, from the Samsung webpage, there was a downloadable PDF version of the User Manual — which, according to its front cover, was actually for the model SM-G360F. (Again, no clue as to how that model might have differed from these others that I had bought or received.) I made a start in these various manuals and guides. The first step, it seemed, was to assemble and charge the phone. So I inserted a Micro SD card as auxiliary memory and inserted the battery. The advice was to fully charge the battery before using the phone, so I connected the included white cable to a USB port on my laptop computer. The battery charge light at the top front side of Samsung was red. It stayed there for hours, and then turned green.

At that point, the printed manuals ceased to be relevant, at least for a while. As soon as I turned the phone on, it started taking me through various setup steps. I didn’t log those. My recollection was that they included an opportunity to link this phone to Google and Samsung accounts. I already had both. I hadn’t logged into the latter for years. It still showed that I owned an old printer. I deleted that and added the smartphone. So now it seemed that my phone and the webpages (accessed through my desktop computer) were aware of each other, at least in those two accounts. The Google link brought over the contacts that I had set up in Gmail, so now I did have some contacts on this phone. It seemed this also set Chrome as my default web browser, so I didn’t have to go through the steps recommended by PhoneArena. (Later, I would find that I could add and/or verify these and other accounts by going to Home > Settings > Accounts. Note that, with Google synced, deleting contacts from the phone would also delete them from Google Contacts. It was advisable to have a backup of Google Contacts on the computer before proceeding on the phone.)

I went back to the TracFone chat feature, on my computer. (I found that their chat usually warned me they were experiencing high contact volume, and told me to try again later, even if my actual hold time turned out to be less than a minute.) On chat, I told TracFone that I now had my new cellphone and wanted to transfer my minutes. They took care of that. The website said that I had those minutes, or maybe a hundred more. It seemed like the balance was somewhat higher than before. I hadn’t noticed any specific indication that the phone came with extra minutes, so I wasn’t sure about that. I did see that the website was telling me that my old minutes were still about to expire. Apparently I was going to have to buy some more minutes in order to keep those old minutes alive. But this was confusing, because the webpage seemed to be listing at least a half-dozen different accounts. Were the old minutes in the same account as the new phone?

Generally, I’d had fairly good experiences with the TracFone chat people, and had reviewed them accordingly. But at this point, it seemed that I had drawn a bad card. The guy said that nobody else had had reported any problems with the TracFone website. That was possible, but it seemed unlikely. Two different browsers encountering problems with the same website: this was not happening, for me, with any other website. A half-dozen different accounts, plainly displayed on the webpage, and he’s telling me they aren’t there. It didn’t add up. When I tried again, another TracFone tech support person frankly said, “I do not have a clue about your situation.” After speaking with a supervisor, my impression was that TracFone had not bothered to spend the money necessary to let its agents see what I was seeing on my screen — and, worse, that they were not even allowed to tell me that I could post a screenshot on their Facebook page and request assistance there. I sent it as a message attachment, so that other FB users wouldn’t see it.

This was the image I attached to that first FB message. It shows that I did have a bunch of minutes, but it didn’t call them that, and it also shows multiple “MYAC” and “RDSG” numbers, among others. In her reply, the TracFone representative didn’t get it. She must not have even looked at this image, which I had attached to that first message. I sent her another message. I got her reply the next day. She said I was seeing that crap because their website was having problems. Apparently they didn’t bother telling their chat support people about this.

It seemed I was going to have to just buy some minutes, and hope they would go into the right account. The TracFone website offered Smartphone-Only Plans, Pay As You Go Plans, and Service Add-Ons. I could have saved money with a plan, but I already had a boatload of extra minutes I was not sure I would ever use — and I was also mindful that I had just buried a TracFone that had died shortly after its one-year warranty expired. Likewise, in the Pay As You Go section, I could have saved 10% by signing up for Auto-Refill. For now, I just wanted to make a one-time purchase. The website said my options, in that case, were to buy a plan with 30, 90, or 365 service days. Assuming TracFone had not changed its style in the year since I had last purchased any minutes, this meant that those minutes (and any other accrued minutes, such as the ones I had just brought over from my old phone) would die unless I bought more minutes within that specified period of 30, 90, or 365 days. The best deal, in terms of price per minute, was for 1,500 minutes for $200. They said my phone qualified for a 3x increase, so I would actually be getting 4,500 minutes, 4,500 texts, and 4,500MB of data (which, I assumed, would be counted when I used the phone to access the Internet). So, for calls, that would be only about 4.5 cents per minute. But since I wasn’t sure I would ever use all those minutes, or even the total of 1,200 minutes that I could get for $100, it seemed I would have to choose between 30- and 90-day options. The only 30-day card was $10 for 30 minutes (i.e., $0.33 per minute). That was not appealing. So it came down to a choice among the three 90-day plans: $20 for 180 minutes ($0.11/min.), $30 for 360 minutes ($0.08/min.), or $40 for 600 minutes ($0.07/min.), with equal numbers for texts and MB of data. I went with the $20 card. As I was about to buy that, a pop-up offered a $50 card that would give me no additional minutes, but would provide 365 additional service days. So then I wouldn’t have to mess with this for another year. Apparently that was only available with another purchase; I didn’t see it in the Service Add-Ons section. So, no thanks on that.

Just to be sure, I went back to TracFone chat. And, well, what do you know. The chat agent said that, actually, yes, TracFone did have a “customer care line,” not viewable on the website, where I could buy a plan that would extend my service. He mentioned $5 for a 30-day extension. He said there were no other extension options. It seemed to make more sense to spend $20 for a 90-day card and get, in effect, three of those 30-day extensions plus 180 minutes.

Operating System Upgrade

At this point, I had worked through the stuff that seemed most pressing. The phone was working; I was all set for airtime; I had synced some accounts. But I still really didn’t know much about using the phone, and I knew there were some basic things that still needed to be set up.

It seemed the first thing would be to upgrade the operating system (OS). This wasn’t essential, except in the sense that any decent OS upgrade would change and, usually, improve many aspects of a system’s functioning. On a computer, at least, I would want to do this before installing programs (usually called “application software” or, more simply, “apps” on a smartphone). An older OS would tend to mean older programs and, usually, more problems and less functionality across the board.

The phone itself mentioned Android when I powered it up. Samsung’s specifications page confirmed that the phone used the Android OS, but did not say which version. I found no additional information in the printed material referred to above, including the User’s Manual. Other sites (e.g., TracFoneReviewer) said that the phone came with Android version 4. At first, I thought version 4 had a “code name” (in effect, a popular name) of KitKat, and version 5 was known as Lollipop. Android 6 was Marshmallow, and Android 7 was Nougat. Wikipedia said, “Android code names are confectionery-themed and have been in alphabetical order since 2009’s Android 1.5 Cupcake, with the most recent major version being Android 7.0 Nougat, released in August 2016.”

Samsung informed me that I could identify the SGCP’s “software version” by going to its Home screen > Apps > Settings (second page of Apps, available by swiping my finger across the screen from right to left) > scroll down to About Phone (on the very bottom line). At that location, I became acquainted with two distinct concepts. I was interested in the Android OS, but now I saw a reference to Baseband Version. A search for information on that term led to sources (e.g., Quora) indicating that Android phones had two distinct primary processor chips, each running its own OS. The communication processor (CP) was like a modem. This was what Baseband referred to. I wasn’t interested in upgrading that. Indeed, as I read on, I concluded that it was like any kind of firmware upgrade: do it wrong, and you brick the device (i.e., convert it into a useless paperweight). So I would upgrade the CP firmware only when someone or something indicated that I needed to.

Back to the OS. I was still in the About Phone menu. I saw that it said Android version 4.4.4. The SGCP itself was released in June 2013, and KitKat was released in October 2013. I was sure that a lot had happened in phone technology since then. So yes, if possible, an upgrade would seem to be in order.

But was an upgrade possible? The general answer appeared to be yes: for example, an answer on Quora pointed to a Samsung Updates Live! page where I could plainly see what appeared to be a Lollipop 5.1.1 upgrade for the SGCP, or at least for model SM-G360G. Wikipedia‘s underwhelming page on the SGCP said, “Some variants [of this phone] can be upgraded to Lollipop 5.0.2 or Lollipop 5.1.1.” But which ones, and how could I tell? Tech Times confirmed that Verizon’s version of the SGCP was shipping with Lollipop as of sometime around yearend 2015, and other remarks seemed to confirm that it depended upon when and whether the carrier would decide to make it available. I saw that T-Mobile, like Verizon, seemed to be using Android 5 in its version of the SGCP. But I wasn’t seeing any indications that TracFone was following that path. A search led back to this comment by a reader of that TracFoneReviewer article:

Most Tracfone customers are probably unaware that Google releases MONTHLY security patches to the Android OS. Across every phone ever sold by Tracfone, how many of these regular security updates have Tracfone’s devices received? ZERO. NONE. They never will get the updates EVER. Tracfone support has stated they do not support the OS. So its clear they do not have any concern whatsoever for their customers once the phone is sold. They wipe their hands and are preying on the fact that most customers do not understand the risks of not having a patched OS.

That comment seemed to be confirmed by a TracFoneForum discussion thread, apparently sponsored by the company, in which someone asked about the Lollipop upgrade and “TracFone Katie,” evidently a TracFone employee, replied, “Our TracFone branded android smart phones does [sic] not support software update as of the moment.” That was in June 2016. Someone else in that same thread, following up in November 2016, was told that there was still no such upgrade.

As far as I could tell, there was not presently an official TracFone upgrade to Lollipop for the SGCP, and there probably would not be one. The next question was whether users could easily upgrade the OS themselves. I was not sure whether such a move would void the warranty, nor whether it would complicate or defeat upgrades of other software (e.g., apps). There did appear to be instructions on how to perform such an OS upgrade. I did not explore them in detail, much less attempt them, so I was not sure whether or how well they would succeed on the TracFone SGCP. Briefly, I noticed that AndroidWorld provided some brief instructions and pointed toward a separate Samsung page, which pointed in turn to a page focused on the SGCP. That page seemed to provide instructions only for SGCP models SM-S820L, SM-G360T1, and SM-G360P. Did I have any of those? At least I now had a way to find out. That About Phone menu on my SGCP said, Hardware Version S820L.05. So the box was right, the Walmart ad and the User’s Manual were wrong, and what I really had was an S820L. So, yes, it appeared that those AndroidWorld instructions could conceivably work for my device.

Finally, there was the question of whether an upgrade from KitKat to Lollipop would represent progress. Having moved from Windows XP to Windows 7, and having considered Windows 8 and 10, I was prepared to believe that an OS upgrade would not always be a great idea. A neutral search for simple information led to a number of sources contending that KitKat was actually the better of the two — which, of course, would make TracFone’s absence of support more defensible in this case, even if it was true TracFone just never upgraded its software, period.

Later, I would find there was the alternative of upgrading from KitKat to Nougat (i.e., the current version 7 of Android). It was apparently possible. But was it advisable? An AndroidCentral discussion presented the view that many users who upgraded from KitKat to Lollipop wound up reverting back to KitKat, and asked whether Nougat would be a different matter. My impression, from that source among others, was that an upgrade to 7.1 might be a net improvement. It would also be an orientation to the state of the art, in the sense that a Windows 7 lover might still realize that a cave man, never before seeing a computer, would probably best be introduced to the computing world via Windows 10.

Altogether, the practical conclusions appeared to be that I might be able to upgrade from KitKat; that doing so might yield superior battery life and features (though I suspected I would have to identify processes and apps designed for a more powerful phone); and that attempting a manual upgrade could result in hardware and software complexities, and potentially real problems, far outweighing any benefit on a device I did not expect to use that often. Based on these impressions, I decided to skip any attempt to upgrade the OS.


In the first several days of owning this SGCP phone, I spent a lot of time dealing with several problems. To some degree, these issues suggested a lack of a quality orientation at TracFone and/or Samsung.

TracFone Website

I found that I had to use the Chrome web browser, on my desktop PC running Windows 7, to access some aspects of the TracFone website (e.g., chat); but I also found that, for some reason, Chrome was not able to access my personal account information. For that, I had to use Firefox. As shown above, when I did use FF to view my account information, I was seeing weird numbers instead of a simple account statement. As mentioned above, TracFone representatives on TracFone’s Facebook page were not immediately helpful and were also apparently not updating their colleagues in chat about website problems. Later, they fixed that problem, but now the website wouldn’t show me my account balances. It just showed dashed lines where the numbers (e.g., 1258 minutes) appear in the image shown above. Sometimes, over the next day or two, that would eventually fix itself; sometimes it wouldn’t.

TracFone MyAccount App – Internet Access Failed

As noted above, when I first turned on the phone, some apps were installed automatically, or seemed to be a part of setup (from e.g., Samsung and Google). Later, I made my first deliberate attempt to install apps, starting with the TracFone “My Account Downloader” whose icon appeared on the phone’s Home screen (see below). When I tried to install that, I got a message: “Alert: Internet Access Failed – Try Again Later.” The User Guide PDF did not seem to have anything on this. A search produced only a few hits. Comment in one discussion thread included these remarks:

The “MyAccount Downloader” app is intended to be used to download the MyAccount app from Google Play to your phone. But, in typical TF fashion, the Downloader app itself does not work. Just go to Google Play via Wifi (or data if you don’t have Wifi) and download/install the MyAccount app directly.

After installing the MyAccount app, run it (with Wifi or data) and you’ll see an option to add a time card to your smartphone. Some people said that function sometimes will accept the card but doesn’t add the time/days to the phone and they had to call TF to get it straightened out.

The surest way is to log into your Tracfone account online with your computer, select the Add Time option for the phone you want and go through the process. You can also use Tracfone site to add time to a phone without logging in/creating an account. It’ll ask you for the phone number that you want to apply the time card to. . . .

Whomever you spoke with at Tracfone fed you a bunch of misinformation. If you ever feel unsure of what they are telling you next time, find a way to get of the phone with that CSR and call a different rep or post here.

I still needed to install the app on my phone, because the website wasn’t reliably showing me how many minutes I had left. I wasn’t sure what caused the “Internet Access Failed” message in this case, but after a while, it did go away, and I was able to install the TracFone MyAccount app from the Home screen icon. I didn’t plan to save payment information on the phone, but at least I would have account information. But then — no, as it turned out, the account information wasn’t available on the phone either. Here, again, though, the information did turn up later.

After I installed that app, I saw that its icon was still on the Home screen. There didn’t seem to be any need for it. The User Guide (p. 35) said the way to remove an item was to put your finger on an item and drag it to the “Remove” word that would suddenly appear onscreen. That worked. But then I saw that it was still in Home > Apps. To delete it from there, I had to go to the menu icon (i.e., the three vertical dots in the upper-right corner) > Edit and then do the drag-to-delete thing. (Note on terminology: three short parallel lines, used as a menu icon, were sometimes referred to as a “hamburger” icon.)

Battery Charging

Initially, I charged the phone via USB cable connected to my laptop. Then I turned off the laptop. Apparently that USB port on the laptop was powered only when the laptop was on; the light (green, I think) that had been glowing at the top front of the phone was now off. I moved the USB cable to a port on my desktop computer. It stayed there for a couple of days. For some laptops, I had been told, it was a bad idea to leave it connected to an external power source; doing so could eventually reduce the battery’s capacity. A search led to an informative Quora contribution that said this:

[In the most likely method of charging,]  the charger is designed to stop charging after full . . . . But, a new charge cycle could start at any time if the charger has an automatic recharge feature. . . . Leaving it plugged in could continue to charge intermittently.

Incidentally . . . the charger is in the phone, not the brick that goes to the wall. This is why you can take a USB cable and plug it into anything and get some charge out of it without regards to how well the power is regulated at the wall.

AndroidPit added, “Don’t charge the battery overnight . . . don’t charge [it] to 100 percent. Unfortunately, there is no app that stops charging at, say, 80 percent so you must make sure yourself that your smartphone is not overcharged.” Failing to do this, they said, could significantly shorten battery life. So, OK, I needed to disconnect the USB cable — ideally, they said, before the battery is fully charged: “[W]hen you regularly charge your battery to only 70 percent, you can still get more than 1000 cycles from it.”

I couldn’t disconnect the cable at the time when I was writing these words, however, because something else had happened. I was sitting at the keyboard, the night before, when I heard a noise from the phone. As I recalled the next day, I heard a popping noise, possibly signaling battery self-destruction; but on later reflection I thought maybe that wasn’t true; maybe it was just a warning sound from the phone’s speaker. Whatever the reason, when I looked over, I saw that the phone’s battery — which had been previously fully charged — was now at 0%. That was bad because, according to AndroidPit, a study found that “regular, to-the-limit discharging led to an overall lifespan of only 300 to 500 charge cycles, while batteries which had been discharged to only 25 to 50 percent could reach 1,000 to 2,500 cycles.” I feared that even this one complete discharge could reduce the amount of charge that the battery could hold.

But what had caused the phone’s battery to become completely discharged, when it was still connected to the desktop computer’s USB port? Here, we had yet another no-no. AndroidPit said, “Charging via the USB port of your PC not only takes longer, it is also harmful. Tensions of USB ports often vary and create greater heat generation. This has an [e]ffect on the service life of batteries. . . . [Instead,] use the original charger and connect it to an electrical outlet.” ExtremeTech added another wrinkle: “PCs can have two kinds of USB port — standard downstream or charging downstream . . . . As a result, you might have a device that charges from one port on your laptop, but not from the other.” Kaspersky observed that, sometimes, people who have tried to use aftermarket or non-original chargers have not merely bricked their phones; they have actually been injured and even killed — by electrocution, it seems, as distinct from explosion.

I believed that what happened, in my case, was that, for whatever reason, the USB port on the desktop was not capable of charging the phone. It seemed that, instead, it was draining it, and I didn’t notice until it hit zero and the phone made that sound. (Not sure if I was in the room to hear any previous warnings it may have given.) This conclusion seemed to be confirmed when I used the wall plug to charge the phone. As with the laptop, this method of charging resulted in a direct, uninterrupted climb upwards from 0% until I finally unplugged it. (Later, however, it seemed that the same USB cable, connected to the same USB port on the computer, did charge the phone. I guessed that this may have been due to some other change I had made to the system in the meantime. My first guess, in that case, would be that this improvement was due to turning on the USB debugging option in Debugging Options (below).) Eventually, I would notice that the phone would display a message, “Connect your charger,” if it dropped below 20%.

There was another potential problem with charging the phone through a computer’s USB port. According to Kaspersky,

[W]henever a mobile device is connected to a USB port, it attempts a handshake, during which it transmits some data. The most data-wasteful are phones based on Android platform 4.x and earlier — they connect in MTP (Media Transfer Protocol) mode by default, exposing all of the device’s files. . . . Locking the phone will save you from such exposure — but, honestly, do you abstain from using the phone while it’s charging? . . . [This] data transmission . . . [involves] AT commands [that could] enable an attacker to get your phone number and download the contacts which are stored in the SIM card . . . [and also] can also open access to install any type of application — including malicious ones . . . even if your smartphone remains locked! . . . You simply cannot know before you plug in your device — so don’t.

As an option, Kaspersky attempted a Kickstarter project for a USB device — plug the cable into it, plug it into the computer — that would “block the data transfer and control the [charging] current.” There probably were other devices of similar concept. I could see the need for something like that: when I had first plugged the phone into the desktop computer, it looked like some software on the phone interacted with something on the desktop. It happened quickly — I just happened to glance over and it was already done, whatever it was.

As this project went on, I would be looking into other battery-related issues, described in more detail below. These included the question of which apps were consuming the most power, and what options I had to supplement the stock battery.

USB Device Driver Not Installed

When I plugged in the USB cable that came with the phone, connecting the phone on one end with the computer on the other end, I got an error message:

Device driver software was not successfully installed.
Click here for details.

When I clicked there, I got a message with “No driver found” indications for CDC Serial and ADB Interface. (I may have already installed ADB (below) when I got this message.) In that message, I clicked on “What can I do if my device did not install properly?” The key suggestion there was that, if I didn’t have automatic updating on in Windows 7 (which I didn’t), I should connect the device and try running Windows Update, to see if it had any optional updates for this device. I took that advice, and it produced something: Windows Update had two optional updates, both from Samsung. I installed those. I got a message, “The updates were successfully installed. More updates are available.” With the SGCP still connected to the PC, I clicked “Review optional updates.” But that just showed me some other stuff that I had decided not to install. To make sure, I tried “Check for updates” again. But there didn’t seem to be anything else. The original message box had changed: it still said no driver was found for CDC Serial and ADB Interface, but it did indicate that Samsung Galaxy, SAMSUNG Mobile USB Modem, and SAMSUNG Android ADB Interface were all “Ready to use.” So now I unplugged and replugged the SGCP. No more bad messages; no problems in Device Manager. The problem appeared to be fixed.

For posterity: to tell the truth, I didn’t immediately follow all those steps. At first, when I saw that message indicating that drivers were not successfully installed, I tried the usual response: Control Panel > View by Small Icons > Device Manager. There, I looked for listed devices that were indented, not smoothly aligned at the left margin — particularly those that had an exclamation mark inside a yellow circle. I saw two of those: one for CDC Serial, and one for SAMSUNG_Android. Sources suggested two responses. One was to right-click on the two exclamation-marked devices > Uninstall > reboot the computer > replug the phone. The other was to right-clicked on those two devices > Update driver software > Search automatically for updated driver software. Both of those steps failed. If I hadn’t found the successful solution described above, I would have retried, choosing the option to search manually for drivers. The Samsung product webpage for my specific phone did not offer any driver downloads that I could have told Device Manager to search in, and it was risky to download drivers from third-party sources that might offer drivers. But Hoffman (2012) gave a location for Samsung drivers; alternately, I found a Samsung page for the Sprint (not TracFone) version of the prepaid phone and an AndroidHost download page.

Basic Phone Functionality

Some aspects of phone usage were fairly obvious. Some were not. This section presents notes about various aspects of SGCP usage that I found surprising, confusing, or otherwise not self-evident.


A “hard key” or “hard button” is a button, typically physical, with one fixed purpose. An example: the letter G on a typewriter keyboard. This SGCP phone came with three seemingly “hard” buttons: Volume on the left edge, Power on the right edge, and Home at the bottom center of the front. The SGCP also came with two soft keys, using the PCMag Encyclopedia’s definition of “soft key” as “a simulated button or keyboard key that is displayed on a touchscreen.” Those two were the Recent Apps (or just “Recent”) button at the bottom left corner of the front, and the Back button at the bottom right. It was evidently possible to remap those two — and also, apparently, the Home button, if not Volume or Power. It seemed that remapping would require rooting (below).

In addition to these spots on the phone that were actually designated as buttons, it was possible to tap, to press and hold, or to swipe one’s finger, at various places and in various ways around the screen, in order to send other signals to the phone. Some of these options are discussed below.

According to the User Manual (p. 8), the Recent Apps button was useful only to open the list of recently used apps; the Back button was useful only to return to the previous screen; and the Volume button was useful only to adjust audio volume.

The Power button had two different functions: press to turn the screen on or off, or press and hold to power the device up or down. On the SGCP, a single press on the Power button only put the phone to sleep. To completely power it down, the User’s Manual (p. 16) said I had to press and hold the Power button. (Sometimes, it seemed, I had to try twice.) That brought a Device Options menu onscreen. The top item on that menu was Power Off. So I had to tap that to truly shut off the power. Some sources conveyed the impression that the Power button would often go bad on the SGCP. There seemed to be many apps (below) designed at least to turn off the screen without using the Power button. For someone used to Windows 7, there did not seem to be any equivalent to the Control Panel option that would let me choose what the Power button did.

The Home button had three functions: to turn the screen on or, if already on, to return to the Home screen; or, if held, to launch Google.

Evidently the power and/or volume buttons on Samsung phones frequently failed. There were various ways of continuing to use the phone nonetheless. To reduce wear and tear, I wanted to try Gravity Screen (4.2 stars) and an onscreen power button, among which Turn Off Screen Free seemed to be among the best of a mixed lot (see GadgetHacks, 2014).

Buttons could be used in conjunction with one another. For example, pressing Power plus Home for a second or two, at exactly the same time, would produce a screenshot (signaled by a white frame momentarily appearing around the screen) of whatever was visible onscreen. The resulting screenshot would be saved in My Files > Images. The User’s Manual (p. 30) said that screenshots were not possible in some apps.

The Status Bar, at the top of the screen (with little icons for the wireless connection, battery charge, and so forth), contained no buttons. But dragging a finger down from the top of the screen would open up Quick Settings, with a list of notifications and convenient access to some settings. Within that newly opened screen, tapping on the date and time would lead to date and time setting options, and there were also options to turn various items on or off (e.g., WiFi, mute).


  • General Functionality. There did not appear to be a way to turn on the keyboard. Instead, the keyboard would come up automatically when a text app appeared onscreen (e.g., Messages, Gmail Compose, Memo). The caps key would stay on if tapped twice. The 123Sym button toggled with the ABC button to offer symbols or the alphabet. In 123Sym, the 1/2 key toggled to provide two sets of number and symbol keys.
  • Keyboard Rotation. There was not a keyboard size option on the SGCP. As an alternative, for my relatively large fingers, it was helpful to use the keyboard in landscape mode. Making this happen required me to hold the phone up (i.e., not flat on the tabletop) and rotate it 90 degrees to the desired position. Doing that would rotate the screen display 90 degrees on most screens, provided I had set Settings > Display > Auto Rotate Screen. Annoyingly, rotation would not happen on the initial lock screen. There, I would have to use the narrow Portrait display keyboard.
  • Alternative Key Choices. For most keys, a tap would produce the large key shown, but holding the key would bring up several alternatives.
  • Samsung Keyboard Settings. A key at the lower left corner offered a large voice icon and, in its upper right corner, a tiny Settings (i.e., gear) icon. Pressing and choosing the gear icon was a shortcut to Settings > Language and Input > Samsung Keyboard Settings.
  • MirrorGo Keyboard. At Settings > Language and Input, I saw an option to use a MirrorGo Keyboard. Neither the User’s Manual nor 1 2 searches turned up any information on this. When I tapped it, to select it, I got a message:


This method can collect all of the text you enter, except passwords, including personal data and credit card numbers. it comes from the app MobileGo. Use anyway?

  • Keyboard Swipe. Settings > Language and Input > Samsung Keyboard > options (i.e., gear icon) > Keyboard Swipe (turned on by default) gave me the option of typing words by swiping between letters. But it didn’t seem to work. It seemed some keyboard apps would offer this and other features.
  • Text Expansion. Lifehacker (Ravenscraft, 2013) said that Android supported text expansion (e.g., enter “lh” and watch it expand to be “LifeHacker” or whatever you’ve defined it as). Unfortunately, my search did not lead to instructions on where I might find that. On the SGCP, it appeared I would need to use an app for this. Zapier (Stych, 2016) discussed text expansion tools in detail. A search led to several options, but it seemed the only well-rated one that would work on the SGCP was SwiftKey Keyboard (4.5 stars). I decided to start there.


I had already learned a few “gestures” (i.e., things to do with my fingers on the SGCP). Now a search led to various sources suggesting other gestures I might want to use. Some recommended gestures seemed limited to newer versions of Android. The gestures that seemed to work on this phone, in at least some of the pre-installed apps and tools (especially Google Maps, Chrome, and/or the keyboard), included the following:

  • Use two-finger pinch or spread to zoom in or out; double-tap to zoom in; tap once, then hold on the second app, to use one-finger dragging to zoom in or out.
  • Slide one finger downscreen to refresh a Chrome webpage.
  • Settings > Accessibility > Magnification Gestures > On: enables triple-tap-and-hold to zoom in temporarily; also supposedly enables panning by dragging two or more fingers.
  • Hold on a word to open handles that you can drag to select more text and to open other options (e.g., sharing, select all, search).
  • Double-tap on a word to open the Touch to Search option at bottom of screen.
  • Select, drag, and drop text into another window.
  • Long press on notifications to access app settings.
  • Rapid text delete: press backspace key and slide to the left.

PCMag offered gestures for other apps (e.g., Twitter, Gmail, Facebook, Spotify) that I did not test at this point.

Connecting with Other Devices

Connecting with a PC. I ran the USB cable included with the SGCP from the phone to my Windows 7 PC. This brought up an AutoPlay dialog on the PC. I selected Always Do This for the Device: Open Device to View Files Using Windows Explorer. The resulting WinEx session showed me the Samsung Galaxy with subfolders for Card and Phone. Using Windows Explorer, I tried copying a text file from the PC to the Card subfolder, and then moving it from there to the Phone subfolder. On the phone, I went into My Files (folder icon on Home screen) > Device Storage. The text file was there. There did not appear to be an app capable of reading it. Using Windows Explorer on the PC, I moved that file back to the PC and viewed it there. Its contents appeared unchanged. So it did seem that Windows Explorer, running in Windows 7 on the PC, would provide one way of moving files around, within and between these computing devices. This was the approach that Vodafone recommended. ADB (below) would provide another method, as would file manager apps on the phone (below).

Quick ConnectSamsung said the Quick Connect Feature enabled quick detection of, and sharing between, Bluetooth and Wi-Fi devices. Samsung said this feature would be visible by swiping down from the top of the screen. I didn’t see it. Possibly it would be visible only if there were another Wi-Fi or Bluetooth device nearby. Or perhaps the SGCP did not have it. I found no reference to it in the User’s Manual.

Connecting with a TV. I did not have a TV. If I had, possibly Quick Connect would work with it. Alternately, Samsung said I could use an HDMI cable and adapter to fit the phone’s micro USB port. Screen mirroring would be another possibility on some devices, but evidently not on this SGCP: I did not see the Settings > More Networks > Screen Mirroring option that Verizon mentioned. It was possible that an app would provide screen mirroring. The User’s Manual did not mention the Smart View option available in some Samsung devices. Samsung offered some troubleshooting assistance.

Phone Calls and Voicemail

I knew that, if I screwed around with this phone long enough, eventually I would run into someone trying to tell me how to use it for phone calls. It seemed there were actually several things to know in that regard.

  • Calls. The User Guide (p. 82) told me to go into Apps > Settings > Call. There, I was able to choose from among a few call rejection messages (e.g., “I’m in a meeting”) or click the + button and add my own. I added “Get lost” (kidding). The phone did not seem to offer any confirmation that it had registered the message I set up. It offered options to answer calls by pressing Home, and to end calls by pressing Power. Otherwise, I went with the default settings.
  • Call Forwarding etc. Several features listed in the User Guide did not seem to be available in my Call Settings options (e.g., call forwarding, call waiting, call blocking). To access these, a search led to a Vodafone page inspiring me to try Apps > Phone > Keypad (upper left corner, visible by default) > menu (upper right corner) > Settings > Call > Additional Settings. Samsung agreed: this was where those other features were supposed to appear. They weren’t there. My SGCP did have Settings > Call > Set Up Call Rejection Messages, but it was odd: there did not seem to be any way to designate which calls would be rejected. Evidently these messages would play only when I swiped the wrong way in response to an incoming call. That is, apparently there was no automatic call rejection feature on the TracFone version of the SGCP. There would still be the option of registering the phone on the national Do Not Call registry. To do that in the U.S., the Federal Trade Commission (FTC) said I would have to call 1-888-382-1222 from the phone I wanted to register. There were various exceptions and loopholes in the relevant federal law. According to Slate (Olen, 2016), these had essentially defeated the purpose of the law. The National Association of Attorneys General (2015) seemed to agree, with Olen, that the major telephone carriers bore primary responsibility for offering better call blocking services to consumers, to prevent unwanted calls from telemarketers and robocallers, many of whom were based abroad, beyond the reach of American law.
  • Voicemail. The User Guide did not seem to have any instructions on how to set up and use voicemail on the SGCP. A search led to a WikiHow explanation that said I should go to Apps > Phone > hold 1. That brought up the mailbox management system. Speaker volume was low, even when set to max; I probably should have done this wearing an earphone. It requested a password (PIN) of four to seven digits, and asked me to record my name, and then decide whether I wanted a canned greeting using that recording, or wished instead to record my own custom greeting. The voicemail system seemed to record audio quality poorly: I had to try maybe a dozen times before it had a recording of my name that came near to what I had said. A TracFone FAQs page advised that I would have to contact Customer Service to get the direct dial number of my voicemail. I was not sure why I would want that: the FAQs said I could check voicemail from a landline phone by calling my TracFone number and pressing star (*) when the voicemail greeting begins, then entering my PIN. Strangely, the FAQs said it was not possible to turn off voicemail, once it had been set up.
  • Apps. To designate specific numbers that I wanted to block, eventually I concluded I would need a third-party app. Desirable features would include free price, the ability to review what has been blocked, and minimal use of resources. A search led to the list of choices shown in the Apps section (below). It appeared that some antivirus apps might also offer a call blocking feature.

I was surprised that the TracFone appeared inferior in some of these regards. These steps and findings suggested that this smartphone offered a remarkable selection of features, as long as you didn’t need it for making or receiving phone calls.

Other Voice Functions

The SGCP was able to do at least four other things with voice, aside from handle phone calls: it could record audio; it could convert text to audio; it could respond to voice commands; and it could do voice recognition  (i.e., it could convert voice into text).

Audio recording was straightforward. All I had to do was go into Apps > Voice Recorder > press the red dot to start recording > speak into the bottom of the phone > press the red dot again to stop. The recording was saved by default in the phone’s High quality setting in a folder that the PC recognized as Samsung Galaxy (i.e., on the device, not on the Micro SD card) \ Phone \ Sounds. The high quality setting was mono, in .m4a format, at a bitrate of only 125kbps, making it good for speech but pretty mediocre for music. I did not test the bitrate for the Normal (i.e., the only alternative) voice recorder setting. I was not sure whether 125kbps constituted a hardware or software limitation — whether, that is, a different audio recording app might produce different results.

AbilityNet explained that the text-to-speech option was available through Settings > Accessibility > Text-to-speech options. They said the Google text-to-speech engine was selected by default, but that was not the case on my phone: Samsung’s engine was selected. It appeared other apps were rated higher than either of these (below).

Voice command recognition quality seemed decent. I would say “OK, Google,” wait to make sure it was showing signs of life, and then tell it what I was searching for — or, even better, proceed directly with the search using the preinstalled Voice Search app. For instance, it understood me when I mentioned the SGCP: it ran the search and then said, “Here’s information about the Samsung Galaxy Core Prime.” O’Brien offered some examples of working commands. TrendBlog (Knoll, 2016) offered a list of more than 70 such commands, but it was clear that these were only the start (e.g., “Call [so-and-so]” or “Set alarm for [time]” or “How much is [X divided by Y]” or “Map of [specific place]” or “What time is it in [city]?” would have open-ended possibilities. It seemed Google Now might be the most commonly used voice command app, but there were alternatives (below).

It was one thing for the phone to recognize “OK, Google” when I was looking at a Google screen telling me to say exactly that. It was a very different matter for the phone to figure out whether I was saying “lettuce spray” or “let us pray.” I was familiar with the concept, at least, of Dragon NaturallySpeaking and other voice recognition software: you spend hours training the software to recognize your way of talking, and then it does reasonably well. A search led to TopTenReviews and Zapier pages particularly identifying several speech-to-text apps named below. But eventually I would find that the pre-installed Google voice recognition tool (available through keyboard button, above) was quite good.


As with other tools on the SGCP, most of the camera options seemed self-explanatory. It did take me a little while to realize that there were more modes for the rear camera (facing away from me) than for the front camera, and also that the two had different settings options (gear icon, upper left corner). To take a picture or shoot video, I just had to press the appropriate icon at the bottom of the camera screen (or at the side, if I rotated to Landscape view). With the shutter sound turned off, the only indication of a shot taken was a brief white frame flash around the screen, as with screenshots (above).

Other Basic Functionality

  • Text Messaging. The User Guide (p. 79) told me to go into Apps > Settings > More Networks > Default Messaging App. There was only the one preinstalled “Messages” app. That app had its own Settings menu option, but I went with the defaults there. To disable text message notifications while I was on a call with someone, Samsung advised that I go to Settings > Alert. I did not seem to have that option.
  • Sounds. To control the noises that the phone would occasionally make, when it was doing something, I tried Home > Apps > Settings > Sound. There, I saw that some items were turned off already. I turned off those that weren’t. This included going into Notifications > scroll to the top > Silent. The User Guide didn’t explain the “Emergency Tone” option, but a search led to a page indicating that this was for “incoming emergency alerts.” That still wasn’t too informative — who was going to be sending me emergency alerts? — but a T-Mobile page explained that these could include presidential alerts (which apparently could not be turned off), imminent severe or extreme alerts, and AMBER alerts. A Verizon page said these could also include emergency alert test messages.
  • Vibration. I went into Apps > Phone > hold the # key. That caused a momentary vibration and put a no-sound icon (i.e., an audio speaker with a line through it) on the status bar, and also put up a little message onscreen, “Sound mode set to vibrate.” Doing it again removed the speaker icon and produced a different message: “Sound mode set to sound.”
  • Text Size. This option was at Settings > Accessibility > Font Size. It seemed to apply only to some texts (i.e., not to all webpages).
  • Night Mode. I could go into Settings > Accessibility > Negative Colors. This would give me a generally worthy effect, where the screen would display in mostly black rather than mostly white, and other colors would likewise be reversed. I believed this could reduce battery use, and would also be easier on the eyes at night. Unfortunately, this option also inverted the colors on images. There was apparently a Night Mode in newer versions of Android, and possibly there were also themes or other options, to address this issue.
  • Radio. The User’s Manual (p. 60) said the phone had an FM radio, in Apps. I did not see any such icon. It appeared I would have to use a third-party radio app (below).
  • Sharing. Computerworld (Raphael, 2013) characterized Android’s sharing capability as a “killer feature” not found on other platforms. Briefly, the idea was that app designers needed merely to signal that their apps were available for sharing — at which point their apps would join the many others among which data could be shared merely by tapping the Share symbol (looks like a glorified < symbol). Examples: hold finger on text, highlight a few sentences, tap Share, and see the list of apps to which the text can be sent; tap Share in a web browser to send the current URL to email, Facebook, or Evernote; tap Share next to a file (in a file manager) and send it to any file storage service. The User’s Manual said, that if I had turned on Settings > Bluetooth, I could use this Share symbol > Bluetooth > select the target device. Items received from another Bluetooth device would be in Apps > Gallery > Download folder — which, I suspected, was the same as My Files > Device Storage (i.e., not the SD card) > Download folder. Sharing was also feasible, using largely similar steps, via Wi-Fi Direct (below).
  • NFC Scanning. Near-Field Communication (NFC) meant communication between two suitably equipped electronic devices, brought very near (within about 1.6 inches) to each other. The SGCP had an NFC antenna in its battery. Thus, the SGCP could scan NFC tags, typically in a shopping context, by going into Settings > NFC. That NFC option was supposed to be listed in Settings right below Location. My SGCP didn’t have that. It appeared the TracFone SGCP might not be able to do NFC. If it had, evidently the next step, after turning on NF, would have been to place the back of the phone, near the battery, directly over the NFC tag on some other object, so as to read its information.
  • Printing. The User’s Manual (p. 71) said that, if I wanted to connect with a printer, I should go to Settings > Printing > Add Printer. That gave me a choice: Complete Action Using > Chrome, Play Store, or Internet. The Manual seemed to recommend using the Play Store option. I tried that, and saw apps for HP, Lexmark, Canon, and others, but did not see an app for Brother, the manufacturer of my home printer. I found that Brother had a Network User’s Guide. I expected to pursue that further if and when I needed to print something from the SGCP. In the meantime, out on the road, I assumed I could add printers from these other manufacturers, using those apps, as the need arose.

Tweaks and Tools

The Android OS generally seemed efficient and appealing. There were, however, some complexities and, in any case, some things that I wanted or needed to alter.


In my exploration of various issues and solutions on this phone, I was going to encounter many references to the concept of “root” or “rooting.” According to AndroidCentral (Hildenbrand, 2016),

Root . . . is the superuser. . . . [T]he root user (superuser) has permissions to do anything to any file any place in the system. This includes things we want to do . . . as well as things we don’t want to do that can put your Android in an unusable state. . . . Rooting is how you get complete access to everything in the operating system . . . . [It] can turn a very expensive Android into a paperweight. You also need to know that for many Android models, rooting means your warranty is null and void.

In other words, rooting the phone would mean making myself its superuser. It would give me access and power to make changes that could not be made otherwise. Tentatively, it appeared that rooting the phone could also violate the TracFone language (above) prohibiting “tampering with . . . or altering the software.” Seeking Alpha (Moyen, 2017) reported, in addition, that Google was allowing Android app developers to prevent their apps from being installed on rooted Android devices. One reason: rooted devices had the potential to use apps and services (e.g., Netflix) without paying for them — which would harm Google as well, given its reported 30% cut on app sales through its Google Play store.

For those who were nonetheless thinking about rooting their phones, it seemed advisable to get some experience with Linux (perhaps via a dual-booted or virtual installation) and then with Android (perhaps by experimenting on a cheap old phone from eBay). I did have some prior exposure to Linux. But I was new to Android, and was not presently inclined to root my new phone. Hence, except for a few mentions of solutions for rooted phones, this post explores only non-root solutions.

Finally, it was apparently possible to unroot an Android phone. If there was ever any doubt as to whether a phone was rooted, it seemed Root Checker (4.2 stars at Google Play) might clarify.

Secret Codes

Joy of Android (Billa, 2016) listed numerous codes that could supposedly be entered at the Android phone keypad. Billa warned that some were dangerous. But most did not even work on the TracFone SGCP. These worked for me:

After entering a code, I had to hit the phone icon to dial it. Later, I saw indications that some were calling General Test Mode by a different name: Diagnostic Mode (below).

Enable USB Developer Options and USB Debugging

This tweak was relatively technical, and strictly optional. I pursued it as an essential prerequisite for a few other things that I wanted to do (below).

It started with USB Developer Options. USB Developer Options was not originally visible in Settings. To make it visible, AndroidPit (Woods, 2017) suggested going to Apps > Settings > About Phone > tap on Build Number about ten times, until it tells you that you are in Developer Mode. Once that was done, a new entry for Settings > Developer Options appeared near the bottom of the Settings list. I would be using Developer Options for a number of purposes as I went along — but I would be very careful about not changing anything in Developer Options without specific instructions on how and why.

In Settings > USB Developer Options, there was an option to enable USB Debugging. This option was tricky. When the phone was not connected via USB to the PC, there was just a checkbox, allowing me to decide whether the phone would go into debugging mode when a USB cable was connected. But if I was looking at that option when the phone was connected to the PC, after a moment’s delay, a black pop-up would ask whether I wanted to allow USB debugging, and also provided the option to “Always allow this computer.”

As described below, the “always allow” option could enable an unauthorized user to get past the phone’s lock screen. To turn off that “always allow” option, I went to Settings > USB Developer Options > uncheck USB Debugging and tap Revoke USB Debugging Authorizations. Then the “always allow” question would reappear when I turned on USB Debugging, if the USB cable was connected.

Install SDK and ADB

This was another optional, technical tweak. The basic idea here was that the user could install software, on a computer, that would enable him/her to send certain commands via USB cable to the phone. This software was known as Android Debug Bridge (ADB). Lifehacker (Ravenscraft, 2014) said that ADB was often used on rooted phones, but could also be used to send commands from the PC to an unrooted phone.

I made two attempts to get this to work. The first time, I followed steps prescribed by Lifehacker (Ravenscraft, 2017). These steps started with downloading and unzipping the ADB package (i.e., SDK Platform-Tools for Windows). Either the instructions were wrong or I did it wrong, because it didn’t work. Possibly I would have had better luck if I had been simultaneously consulting the instructions provided by How-To Geek (Hoffman, 2012).

I uninstalled that stuff and tried again, this time following instructions provided by GadgetHacks (Thomas, 2017). This involved downloading and installing Android SDK Tools (i.e., installer_r24.4.1-windows.exe) from the link Thomas provided. (As an alternative source, it appeared FileHippo’s download was identical.) When installation finished, I took the option to open Android SDK File Manager. Leaving its settings at their defaults, I just clicked the Install (in my case, “Install 9 packages”) button in the lower right corner > Accept license > Install. As one other item of preparation, I also downloaded and installed the 32-bit (i.e., x86, not x64) Java Development Kit.

That took a little while, as an apparently substantial amount of software was needed to update to Android SDK Tools version 25.2.5. When it was done, it suggested I close and reopen the Android SDK Manager. I did that, using the newly installed Start menu program icon to reopen. In the Manager, I made sure certain items had Installed status: Android SDK Platform-tools in the Tools section, and Google USB Driver in the Extras section. I noticed the Install (i.e., “Install 4 packages”) button needed to be clicked. I had to watch the progress bar across the bottom to make sure I didn’t close the Manager before that update was finished.

The next step, Thomas said, was to download and run a driver file (i.e., UniversalAdbDriverSetup.msi). Assuming I had enabled USB debugging (above), he said, I should be able to send ADB commands. To test whether ADB was working, Hoffman (2012) told me to go to C:\Program Files (x86)\Android\android-sdk\platform-tools in Windows Explorer, then right-click on an empty space in that folder and use Shift-right-click to open a command window there. At the command prompt, with the phone connected via USB, Hoffman told me to enter this command:

adb devices

That gave me a “List of devices attached” naming only one: “40gc81e1, unauthorized.” So my ADB was working. Hoffman said that, if no device appeared, that was probably because the needed drivers had not yet been installed.

Hoffman said I could use ADB commands for various purposes. A search led to a variety of sources on that. For instance, Linuxtopia and ADBShell provided lists of ADB commands, and AndroidCentral (Hildenbrand, 2013) and Lifehacker (Ravenscraft, 2014) suggested a handful of especially useful ADB commands. Examples: adb push (to copy listed files from computer to phone) and adb pull (to copy files from phone to computer); adb shell (to open the door to Linux commands, such as those enabling searches within and among files on the device); adb backup (to create a full backup with a single command — or, on an unrooted phone, a relatively full backup) and adb restore (to restore a backup). There were others that might exceed the TracFone terms (e.g., fastboot oem unlock). Android offered more detail on ADB. I would be pursuing some of those options later (below).


Probably the first kind of option that I encountered, with this phone, had to do with updates. As mentioned, I was not taking notes at that point, but in just turning it on — newly arrived and fresh out of the box — and going with the questions and information appearing onscreen, I think I got an option to allow automatic updates. Now it seemed like automatic updates were a potential source of problems.

I had already encountered one reason for turning off automatic updates: it seemed that something had updated or modified itself when I connected the USB cable to the desktop. GottaBeMobile offered a different reason: sometimes app updates can cause new problems, in which case it can make sense to wait a few days, and let the mistakes be discovered and fixed, instead of becoming one of the victims. Yet another reason came from WorldSim, which I found through a different search: updates when traveling internationally could entail unwanted data roaming costs. In addition, I still hadn’t mastered the sounds the phone was making, so I could have been mistaken, but it seemed like I was getting whistles or chirps or something related to updates, and I didn’t want that distraction.

It turned out that the location for turning off or controlling app updates was not obvious or easy to find. In the User Manual (p. 72), I saw instructions to go to Home screen > Apps > Settings > scroll down to About Phone > Software Update. It said, “Checking for updates” and then “The latest updates have already been installed.” But there was nothing there about controlling them. The User Manual didn’t seem to offer a way to turn off automatic updates.  A search led to only a few hits, none seemingly on point.

Eventually I found that, to turn off automatic app updates, I had to go to Home > Apps > Play Store > menu icon in top left corner (or swipe right from left edge of screen) > scroll down > Settings > Auto-update apps > choose between “Do not auto-update apps” or “Auto-update apps over Wi-Fi only.” While I was there in the Settings menu, I went into Notifications > turn off Deals and Promotions. I also made sure the setting was right in Require Authentication for Purchases.

Data Usage

Thanks to horror stories (some involving bills for several thousand dollars of data usage, though that wouldn’t happen on TracFone or on an unlimited data plan), I was concerned that some app might be going online and burning through my data allotment. To avoid this, comments in a Verizon discussion suggested several things to avoid: streaming or downloading media (e.g., video, audio, pictures) (or at least use low-resolution settings if possible); close down applications and disconnect from WiFi when not in use; check usage frequently, especially when first getting used to the device; turn off automatic updates; and secure the device by changing the default connection credentials.

In the course of investigating some of those suggestions, I found some complexity. For one thing, it seemed that complaints about Android’s frequent WiFi disconnections could apparently stem from the option chosen at Settings > Wi-Fi > menu (upper right corner) > Advanced. Those options included one for Keep Wi-Fi on During Sleep. I was puzzled that the phone indicated that the Never setting “increases data usage.” I would have thought that no data usage would be possible if WiFi was turned off. The User Guide PDF (p. 76) explained that, if WiFi is turned off, “the device automatically accesses mobile networks if it is set to use them,” resulting in possible “transfer fees” and greater battery use. An AndroidForums comment agreed: “The moment you get disconnected from WiFi your 3G will come back on.” GuidingTech and others warned that leaving it always on would use up more of the battery; but a Reddit remark said, “Searching for a weak mobile data connection uses way more battery than a strong Wi-Fi connection.” Another source concluded,

After some investigation the conclusion I’ve reached is that the settings are mislabled . . . . “Always” results in disconnection [after 15 minutes] . . . . “Never” keeps WIFI on and connected indefinitely, and if autosync is also on you’ll get lots of wake-locks and reduced standby battery life, particularly if you have location reporting on and google maps installed.

. . . but another participant in that same discussion disagreed. The best explanation I found was provided by SUroot: “Keep WiFi on during sleep should be set to ‘Always’. Constant disconnecting and reconnecting when you turn on and off your screen is a drain.” Beyond that, it seemed that a thorough understanding of these matters would call for a deeper dive into cellphone technology than I really cared to undertake at this time. I left it on the Always setting. Otherwise, to minimize data usage as suggested in that Verizon discussion, I followed these steps and suggestions, along with topics addressed in other sections (below):

  • Turn WiFi off at Apps > Settings > Wi-Fi > top button.
  • Frequently check Settings > Data Usage.
  • Regarding Settings > Data Usage > menu (at top right corner) > Restrict Background Data, a search led to Bartlett’s (2016) indication that this applied only to “the wireless data network, not Wi-Fi.” When I checked that Restrict box, I got a warning: “Restricting background data will stop some apps and services from working unless device is connected to a Wi-Fi network.”
  • TechAdvisor (Black, 2017) recommended using Home > Apps > Play Store > menu (icon at top left corner) > Settings > Auto-update apps over Wi-Fi only. This was an alternative to an earlier suggestion. I decided not to switch to this approach now.
  • Black also recommended using Home > Apps > Settings > Data Usage > turn off Mobile Data. Choosing this gave me a warning: “Unless you connect to a Wi-Fi network, you will not be able to use the Internet, Email or other apps that require a data connection.”
  • If I did not turn off Mobile Data, an alternative at that same location was to Set Mobile Data Limit. This produced another message: “Your mobile data connection will be turned off when the specified limit is reached. Data usage is measured by your phone, and your service provider may account for usage differently, so consider using a conservative limit.” This seemed to be a fail-safe option, protecting those who wanted to leave Mobile Data on from incurring extra expense. Black recommended making sure that monthly cycle timeframe shown on the phone matched with that of the phone contract (not applicable to us pay-as-you-go users).
  • As another approach (evidently useful either instead of, or in connection with, the foregoing), Black suggested going Settings > Data Usage > Mobile (if there are separate Mobile and Wi-Fi tabs) > scroll down to view the list of apps that use data on this phone > tap an app > scroll down to see how much foreground and background data it has been using > tap on its View App Settings option > choose various options.
  • As an example of an app offering its own data saving settings, YouTube gave me the option of turning on its Limit Mobile Data (or perhaps Downloads — I could see only the letter “D”) option, so as to “Only stream HD video on Wi-Fi.” As another such example, AndroidPit (Herrmann, 2017) pointed out a data-saving compression feature in Chrome (with some drawbacks mentioned on the phone itself when I signed up for this) via Apps > Chrome > menu (top right corner) > Settings > Data Saver. The Opera browser also offered compression.
  • To minimize downloading or streaming media, it seemed I might download videos, audio, and large images on the computer (using e.g., Easy Youtube Video Downloader Express) and then copy materials over. CNet (Profis, 2013) said that the YouTube Watch Later List (editable on computer as well as phone) would preload content, when a WiFi connection was available, and would then save it for later viewing. Otherwise, How-To Geek (Fitzpatrick, 2017) warned that gigabytes of data can be used very easily.
  • Profis suggested going into Apps > Settings > Accounts > Google > select an account > unsync the items that don’t have to be synced. Those items would then be synced when the user opens the app (e.g., Google Drive). Alternately, Profis suggested turning off syncing altogether when it would not be needed (e.g., when working at the computer): Settings > Data Usage > menu > uncheck Auto Sync Data. This gave me a message: “This will reduce data usage and conserve battery power, but you need to sync accounts manually to collect the most recent information.”
  • Fitzpatrick also recommended buying apps, rather than using the free versions, if the latter are ad-supported, because ads use data too.
  • For Google Maps, Fitzpatrick recommended Apps > Maps > menu (top left corner) > Offline Areas > Select your own area. At first, this was blank. Fitzpatrick said that Google Maps used a lot of data, and that having an area pre-loaded in this Offline Areas section would reduce that data usage. I was not sure what I did to make it work. Possibly it was just loading; GotB said that Location History had to be turned on, that that it could take a while to activate an app. But mine was now working without Location History. Once I had it working, and downloaded an area, Google Maps said, “Your areas will automatically update over Wi-Fi. If Maps can’t reach Wi-Fi, areas will expire after 30 days.” It seemed Maps would continue to work in any area as long as I was connected to WiFi.
  • For those using a wireless hotspot (below), the risk of incurring a huge and unexpected data usage bill could supposedly be reduced with tools like the Pepwave Surf Mini and Peplink Balance 20 Router, to monitor usage while it is happening, rather than after the fact.
  • Newer versions of Android would have additional data usage controls.

Closing Unused Applications

On the PC, of course, a user might close programs (and a more advanced user would turn off services and startup items in msconfig), so as to make memory and CPU resources available for the main task at hand. But as with data usage (above), it seemed that what would make sense on a laptop, in terms of closing programs that did not need to be running, would not necessarily be the best move on an Android smartphone.

Wired (Pierce, 2016) said that a smartphone app could be in several different states. Between Active on one hand and Not Running on the other, the principal alternatives were Background (running but not directly visible) and Suspended (loaded into memory but not doing anything). Pierce said that Android was “very good at knowing” whether to kill an app that was using needed resources, or to keep it alive because it was going to be needed again. ITWorld (Purdy, 2013) said that swiping (i.e., stroking the app to the left or right side) did not actually kill it; it was more like hitting the Back button in a browser, preventing it from continuing what it was currently doing but not preventing it from continuing in background processes. Android Tips & Hacks said that the ability to run multiple apps was actually a strength for Android vs. the iOS and Windows Phone OSs, and that doing so also used more battery power, apparently because Suspended apps would not be using any resources and yet would be able to come back to life more easily when next needed. Various sources seemed to agree that task-killing apps were no longer a good idea.

Since I was new to smartphones, I was not clear on which of my many activities would actually start an app. VisiHow said, “Every time you open an application then press the ‘Back’ or ‘Home’ button rather than closing the application, those applications will stay active and open in the recent apps section.” The Recent Apps section was available by pressing and holding the Recent Apps button — an actual button (i.e., not onscreen), at the very bottom left corner of the device. For me, that didn’t work immediately, When I stopped pressing that button, I had something else; I had to tap it again to get the set of tiles indicating which apps were running, like this:

Tapping on one of those tiles would bring that app back to full size. If I pressed and held on a tile, I would get choices: Remove from List or App Info. If I chose App Info, I would get several options for the app (e.g., Force Stop, Turn Off, Move to SD Card). Purdy and WikiHow said that Force Stop (below) was the way to completely kill an app as well as all of its associated background processes. When I tried Turn Off, I got a message: “Turning off built-in apps may cause errors in other apps.” Eventually I would discover that pressing the icon at the bottom of the Recent Apps list (i.e., in the foregoing image, the little white X with three short horizontal lines) would close all apps in the list at once, but would not necessarily close them completely. After doing that, a return to this location just gave me the statement, “No recent apps.”

Battery Life

As described above, there was a debate on the effect of keeping WiFi on, during sleep or otherwise, and part of that debate included some apparent disagreement as to how WiFi and sleep would affect the battery’s charge level. Other thoughts and suggestions on getting the most out of a battery charge:

  • In a long thread spanning a year and more, EasilyAmused contended that WiFi did not significantly drain the battery — that, indeed, leaving WiFi on might extend battery life, because the phone’s “radio” (i.e., its wireless connection to cellphone towers) uses much more power than WiFi, and the radio stays off if the phone can get its data through WiFi. The primary reason for turning WiFi off would be to reduce the risk of major unexpected data usage (above).
  • Obricko observed greatly improved battery life by turning off Apps > Settings > WiFi > menu (top right corner) > Advanced > Always allow scanning.
  • EasilyAmused also recommended using Apps > Settings > Airplane Mode in areas of no cell coverage, to prevent the phone from constantly trying to find a signal.
  • A search led to debates on battery drain due to Bluetooth. Comments in an AndroidCentral forum suggested that a user’s battery drain may have occurred because his/her device was not connected to a device, and was thus constantly searching. TheAndroidSoul (2016) noted many complaints about battery drain in Nougat, and offered a workaround that involved turning off battery optimization for Bluetooth devices. How-To Geek (Hoffman, 2016) said that Android had been improved to a point where turning off Bluetooth would make only a small difference — but, he said, it “used to be a very important step in optimizing your Android device’s battery life” — suggesting that it might make a big difference in my KitKat SGCP from 2013. As noted above, I did not plan to upgrade this phone to a newer version of Android. SoftonicApps (Pewter, 2016) said that Bluetooth itself had improved markedly from its earlier versions — that Bluetooth 4.0 consumed only 10% as much power as Classic Bluetooth — and advised, “[I]f you do have an older version, turn off Bluetooth when not in use.” Wikipedia said the current version was 5, and that 4.0 was adopted in June 2010, and 4.1 in December 2013. So it seemed — and Samsung confirmed — that my SGCP had 4.0. Wikipedia agreed that 4.0 incorporated significant power-saving innovations. AndroidAuthority (Dye, 2016) agreed that it used to be good advice to shut down Bluetooth, but said that doing so nowadays would save perhaps a half-hour of battery life per day. It seemed that turning off Bluetooth would not make a compelling difference if I felt that Bluetooth would contribute meaningfully to my SGCP experience.
  • AndroidBeat (Pandey, 2014) noted that Power Saver mode on newer Android phones would turn reduce screen brightness, among other things. In Apps > Settings > Display > Brightness, I tried dialing it back from the default, which looked to be about 60%, to less than 25%. It was still fine for my purposes. The auto-brightness option (for phones that had it) was said to be a power hog, paradoxically, because it required the phone to keep sampling the light level and making corresponding adjustments.
  • Pandey also noted that PowerSaver mode would turn down the clock speed of the phone’s CPU, so as to use less energy. Underclocking the CPU (or getting an app for that purpose) reportedly required a rooted device.
  • Pandey mentioned the option of using an app (e.g., Greenify, below) to control the CPU. There were other battery-saving apps as well. EasilyAmused (above) recommended against battery-saver apps, on grounds that (as of 2012) Android apps had largely switched to technology rendering those apps obsolete and even counterproductive. But others disagreed. It appeared that the need for such apps was reduced with the arrival of Doze mode in Android 6 (Marshmallow).
  • Sprint recommended turning off GPS when not in active use: Apps > Settings > Location > Power Saving. Also choosing a non-live wallpaper at Settings > Display > Wallpaper. I just stayed with the default there. I had seen claims, and I believed, that vibrating would use a lot of energy. Sprint said I could turn that off at Settings > Sound.
  • There was also Settings > Ultra Power Saving Mode, which the phone described as using “a minimal Home screen layout and limiting the number of usable apps.” When I turned that on, I was given a “terms and conditions” screen that wasn’t really terms and conditions; it was just a YMMV warning. Then I got an “Estimated max. standby time” of 13.2 days — and that was with only 69% power remaining on the battery. The resulting screen contained just Phone, Messages, and Internet, with space to add several more, and it powered down after maybe five seconds of inactivity. The option to undo this appeared onscreen as soon as I restarted.
  • There were options of buying a higher-capacity battery and/or a mobile charging solution (below).

Storage Setup

I had inserted a MicroSD card before closing the back of the phone. Somewhere, I had seen an indication that this card would need to be formatted before the system could use it. That seemed to be why Google Maps > menu > Offline Areas > Settings (top right corner) > Storage Preferences said I had 0MB available on the SD card. Someone had told me, moreover, that I should or perhaps must use the phone (rather than the computer) to format it properly. So now GeekSquad advised backing up the phone (below) and then going into Apps > Settings > Storage > scroll to bottom. Geek said the options should include Erase SD Card or Format SD Card, but I guess I wasn’t there yet; mine only said Mount SD Card. I chose that. It turned blue for a few seconds, then white, and I momentarily saw “Blank SD Card” at the top of the screen. But it still said Mount SD Card, and nothing changed in the Google Maps option. It seemed something might be wrong with the card. PowerDataRecovery recommended attaching it to a PC and running CHKDSK. I did attach it to the PC, and it did appear to be bad. MiniTool Partition Wizard said, “Bad Disk,” and when I tried formatting it in Windows Explorer, I got, “Windows was unable to complete the format.”

I tried replacing it with another Micro SD card. The User Guide PDF (p. 15) said I needed to go to Settings > Storage > Format SD Card > Erase Everything. But — unlike the picture shown by Samsung — I still didn’t have Format SD Card or Unmount SD Card options. I only had Mount SD Card; and when I hit that repeatedly, the message at the top just kept saying “Preparing SD card” and then “Blank SD card.” A search led to a suggestion to format the card as NTFS on a PC and an indication that the card’s size of 32GB was at the maximum supported by the phone — although the User Guide (p. 14) said the maximum was 128GB. I tried again, with a third Micro SD card. This one was a Transcend, 8GB; the others were Samsung. Same result.

The PC told me (Windows Explorer > right-click on the card > Properties) that the Samsung 32GB was already formatted as NTFS. I tried quick-formatting it as FAT32. That worked. Now, at Settings > Storage, under the SD Card heading, I had readings for Total and Available Space (both 29.79GB) as well as Unmount SD Card and Format SD Card. I tried the last. It warned me that it was going to erase everything. That worked. Now Total and Available were at 29.80GB. I did some of this while waiting in queue for Samsung chat. When they finally came online, they confirmed that it had to be FAT32. Now, belatedly, I found that the User Guide (p. 14) said it could also be exFAT. In the end, as I considered the amount of data I might want to access on the SGCP, it seemed that 64GB was the more sensible (and not much more expensive) size of SD card, so I repeated the formatting with one of those.

Note that the internal SD card was not the only storage option. Other sections (below) discuss external and cloud storage options.

Rearranging and Uninstalling Apps

According to WikiHow, apps that came preinstalled could be removed only if the phone was rooted. As noted above, I was not planning to do that. Hence, for present purposes, I would not be uninstalling any preinstalled apps.

For the alternative case, where I had installed the app, uninstalling seemed easy enough. WikiHow essentially told me to go to Apps > Settings > Application Manager > select the app to be uninstalled > choose Uninstall. At this moment, I was looking at the Google Play Books app. Instead of an Uninstall button, it only had Uninstall Updates. Apparently that was because this was a preinstalled app. There were at least the options to Force Stop or Turn Off preinstalled apps.

Short of uninstalling, it appeared that I would not be able to remove app icons from Home > Apps. To make it easy to find the apps that I would use most often, it appeared the best option would be to create shortcuts to those apps, and then arrange the shortcuts in ways I found convenient. That way, I would rarely need to go digging and swiping through the Apps screen; I would be able to access everything I needed from icons or folders on the Home screen. My guidance on creating and organizing these shortcuts came from various sources (e.g., Lifewire; Dummies; Ubergizmo).

By this time, I had heard people referring to Home screens, plural. Steve Cope (2017) said that (at least some versions of) Android offered up to seven different Home screens. From his remarks, I gathered that, when people talked about multiple Home screens, they meant the screens that you would get by going to the Home screen and then swiping to the right or left. The separate “screens” were, in effect, multiple panes comprising the Home screen — or, as some might think of it, the Home page.

I didn’t want to have to swipe among multiple Home panes. My phone came pre-equipped with three of these panes — or maybe, in my screwing around, I had inadvertently created at least one of them (or perhaps the previous Walmart customer had created these before returning the phone). One of these panes, I saw, was the main pane, with several icons (i.e., Phone, Contacts, Messages, and Apps) across the bottom. Another was a Google pane, with some other icons added. The third seemed to be devoted to a song player, with the Gallery icon. One by one, I pressed the icons on these second and third panes, and held them, for a second or so, until the Create Folder and Remove options appeared at the top of the screen; and then I dragged them to Remove. I verified that I was not thereby doing any permanent damage — that duplicate icons for these apps were still available in Home > Apps. I was also able to drag and Remove the Google and media player apps that seemed to be running on those panes. So now I just had a basic Home pane with the Phone and other icons across the bottom.

Now I was ready to go to Home > Apps and create shortcuts for the apps that I expected to use. To do this, I pressed on an app, waited for the screen to clear (i.e., to return me to the Home screen), dragged the icon inside the rectangle that appeared onscreen (if my finger was not already inside that rectangle), and then let go. Now I had an icon for that app on the Home screen. I also did this with the icons across the bottom of the Home screen, until the only one left was the unremovable Apps icons. So now my Home screen had icons for all of the apps that I thought would be useful. These filled the first pane on the Home screen; I had to swipe to bring up another pane to hold the rest of them. Dragging an icon on top of another icon was not what I wanted to do yet.

To organize these icons, I decided to take an approach somewhat like that of my customized Start Menu in Windows 7. It seemed that some of these apps could be categorized as Tools, so I started by creating a Tools folder. To do that, I put my finger on an app icon and held it until the rectangle appeared — when the Create Folder and Remove options also appeared at the top of the screen — and then dragged the app icon onto the Create Folder icon. When I did that, I was prompted to enter the folder name. So now Tools would contain Calculator. Next, I added Calendar to that Tools folder. I did that by pressing and holding calendar until the rectangle appeared, and then dragging Calendar and dropping it on the Tools folder.

Some of the icons I wanted to add to the Tools folder were on a different Home pane. The Tools folder did not appear on that pane. So I needed to move the folder to that other pane, or move those other icons to the pane where the Tools folder was located. To do that, I pressed on the icon to be moved, held it until the Home pane tiles appeared, dragged it to the edge of the screen, held it there until the other pane appeared, and then dropped it on that other pane.

After I had stocked my Tools folder, I was ready to create a Settings folder. This one would contain (at least) the plain old Settings shortcut plus Google Settings and Play Store. I created this folder in the same manner as before, and likewise with other Home screen folders for Online, Phone, and Media.

So now I had one Home pane with six folder icons in it. That left me with unused Home panes. To get rid of them, I put two fingers on the screen and dragged them together, like a scissoring motion. Another method was just to hold my finger on a blank area of the Home screen. Either way, that caused the Home panes to display as tiles. Then I could drag the empties to the Remove trash can that had appeared at the top. I closed out of that by hitting the Back button at the lower right corner of the phone. To add a new empty Home pane, I did the same thing — I got the Home panes to display as tiles — and then I swiped to the left until I got the blank pane with a big plus symbol on it. Tapping on the plus gave me a new, empty Home pane.

For future reference, a search led to several relatively drastic methods of resolving uninstallation problems, if the simple ones (e.g., rebooting the phone; reinstalling and trying again to uninstall) didn’t work. These more drastic options included doing a factory reset (i.e., wipe all apps and configurations and start over); using Odin Mode (above); deleting the installation folder, though I assumed that could cause system instability; using Titanium Backup (on a rooted phone, above) to uninstall virtually anything; or installing a custom ROM (above).


Samsung described a widget as “a simple application extension that is often part of a larger application already installed on the device.” Android said, “You can imagine them as ‘at-a-glance’ views of an app’s most important data and functionality that is accessible right from the user’s home screen.” Android distinguished information widgets (e.g., current time, weather, sports scores), collection widgets (e.g., displaying a list or a grid showing at least some of the text or images in a larger set), control widgets (e.g., easy access to frequently used functions, such as a widget that lets the user play or skip a music track without going into the music player), and hybrid widgets with a mix of features from two or three of the other types (e.g., a music widget that combines control and information functions).

To set up one of the widgets that were already installed, I merely needed to hold my finger on an empty spot on the Home screen, and the list would come up. PCWorld (Patterson, 2016) liked widgets that, with just one or two taps, would enable direct calling or messaging to a specific contact, provide direct access to a specific message thread, view a specific Gmail label or folder (especially when filtered to allow only certain messages), open Google Maps to a specific location, and scan a document. Patterson said that larger Android widgets could be resized by pressing and holding until the Remove button appears, and then dragging handles. How-To Geek said that I could also create widgets to function as shortcuts to various items in Settings. Others suggested additional widgets of potential interest.

Lifehacker (Gordon, 2010) said that widgets would sometimes impose a “slight performance hit.” Others had said they were always running, and thus might reduce battery life and involve extra data usage. I was also unsure whether I would be able to stick widgets inside folders, so as to keep my stuff on a single Home pane, nested within a hierarchical “Start Menu” folder arrangement. It seemed I could — and, for my priorities, it seemed I probably should — try to achieve as much as possible of what I would get from widgets by using shortcuts instead.


Lifehacker (Ravenscraft, 2013) said that Google was treating shortcuts and widgets as the same thing. That did not seem to be how things had turned out: I was presently seeing continued distinctions between shortcuts and widgets. Perhaps the key distinction for present purposes (i.e., with an eye toward minimal battery and data usage) would be that a widget would be something that remained active (e.g., a clock), while a shortcut would normally just sit there (e.g., a shortcut to a friend’s contact info).

As noted above, I had already created shortcuts for the phone’s preinstalled apps and had arranged those in folders on my Home screen. I would also be adding more apps (below) and adding their shortcuts to those folders. Meanwhile, the question was whether there would be other, non-app kinds of shortcuts that I should also add to those folders.

  • File and Folder Shortcuts. It appeared that shortcuts to specific files would require an app. AndroidCentral and TomsGuide provided information on using ES File Explorer for this purpose, but some said it had become bloated; there were more highly recommended alternatives (below). Otherwise, to add a folder (not file) shortcut to Home, I went into the My Files folder (now located on my Home screen) > scroll down and navigate to desired folder > menu (upper right corner) > Add Shortcut > Add to Home Screen.
  • Contact Shortcuts. To make a shortcut to my contact information for someone, I went into the preinstalled Contacts app > select the desired person > menu (upper right corner) > Add shortcut to Home screen. As with the other kinds of shortcuts, it would be feasible to create a Contacts folder for frequently used contacts, and even alphabetical subfolders within it — or, alternately, to choose a suitable app (below). Note that it was also possible to designate Favorites within the Phone app.
  • Bookmark Shortcuts. To create a shortcut to a specific webpage, the procedure in Chrome was to view the page > menu (upper right corner) > Add to Home screen. (It was also possible to create a bookmark via menu > bookmark icon (i.e., the star at top left, not the word “Bookmarks”), and then edit its name and location, but it was difficult to avoid putting it outside the Mobile Bookmarks folder. To see bookmarks created in this alternate way,  How-To Geek said the procedure was similar in Firefox: menu > Page > Add to Home Screen.) There did not seem to be a direct way to create a shortcut to a webpage viewed in the preinstalled SIA browser. The steps described by WikiHow did not seem to correspond to the SIA options on this phone.

Synchronizing and Backup

It was one thing to create Home screen shortcuts for a few frequently used bookmarks, as described above. It was quite another to deal with the dozens or even hundreds of bookmarks that a user might have accumulated on his/her computer. For those, it could be quite onerous to manually reconstruct, on a phone, the folder structure or other organizational system for bookmarks on a computer.

Those who used only one browser could have a simpler time of it: Chrome, Firefox, and others had sync features that could bring bookmarks over intact. Those who used two or more browsers would not normally have an opportunity to merge their sets of bookmarks into a single list. Xmarks was the principal answer to that: install it on each browser on the computer, and it would synchronize bookmarks (and also, optionally, passwords and/or open tabs). Then, when setting up a new browser on the phone, its sync feature could bring aboard the desktop’s nice, organized, synchronized set of bookmarks.

But that’s where the party ended. To keep a mobile device synchronized with other devices going forward, as new bookmarks were added or taken away, the user would need a premium Xmarks account, and that would cost $12 per year. I would have no problem with that — if there weren’t dozens of apps that deserved that $12 as much as LastPass (which now owned Xmarks and which also charged $12 for its own premium password service). What made more sense to me was to keep my money and, if I had any to spare, to try to spread it out in donations (as I had in fact done) to the programmers who had helped me most, regardless of whether they had the need or desire to charge a fee.

Translated, that meant I was looking for Xmarks alternatives. AlternativeTo didn’t really have any. TopBestAlternatives named 15 alternatives, among which the most notable cross-platform tools appeared to be Papaly (not yet available for Android; 4 stars at Chrome Web Store), Pinboard ($11/year; not considered further here), Pocket (4.5 stars on Google Play, 4.54 stars at Chrome Web Store), and FVD Speed Dial (5 stars at Firefox Add-ons). Pocket was among the leaders recognized by Slant readers. It didn’t appear in Firefox > Tools > Add-ons, and was not found in Firefox Add-ons, but did provide a button for the toolbar (though it took a restart to make it appear in the Customize area, whence I could drag it from obscurity). Once I had signed up, Pocket’s webpage annoyingly refused to take me to a real home page, where I hoped to find more information. Pocket seemed more oriented toward saving articles for later reading (see e.g., How-To Geek) — not a bad purpose, but not in focus here. In lieu of FVD, with its large and (to me) ugly “speed dial” design, I gravitated toward its companion program EverSync (4 stars at Firefox Add-ons, 4.5 stars at Google Play, 4.37 stars at Chrome Web Store). Some of the negative reviews of EverSync at Google Play suggested some continuing rough edges.

For now, I decided to try the approach of creating a WordPress blog webpage containing my bookmarks, organized the way I wanted. This would have the drawback of not being very editable in the phone. That was OK, for me: I didn’t often add or change bookmarks. Those that I did add, I’d add in Chrome or Firefox, synchronized, and then occasionally sweep those into the webpage. There could be a private version of (or addition to) the webpage, if I had links I didn’t want others to see. For a basic page, I would be able to get by with very little HTML knowledge. The webpage would be viewable from any device that could go online. As it turned out, by the time I finished cleaning out old bookmarks I never used, there were only a few left.

Another possibility (which I didn’t choose) was to make the link on the SGCP’s Home screen point to an offline HTML webpage, located perhaps in a folder that I would keep synchronized among my devices (using e.g., Beyond Compare on the PC, or a scheduled batch file running XCOPY). Either way, this approach could make my shortcuts more visible, and would reduce my dependence on apps that might go the way of Xmarks.

Backup and Sync

Samsung offered a backup option at Settings > Backup and Reset > Back up my data. The text there said, “Back up application data, Wi-Fi passwords, and other settings to Google servers.” Thus the built-in backup would be a Google function.

The sync concept (in e.g., Google Chrome) was that the same app or program could be used on multiple devices (e.g., Android phone, Windows desktop PC), and its settings and other data (e.g., open tabs) could be synchronized among such devices, so that the user could stop working on one device and pick up where s/he left off using a different device. By contrast, the backup concept was that user information (e.g., a list of open tabs, a screenshot showing preferred settings, a folder full of photos or documents) could be saved in static form on some other physical device. A backup copy of a file could remain unchanged for years, whereas the current synced status of one’s Chrome browser could change moment by moment. It would probably make sense to keep backups of everything, not necessarily to capture the very latest status of a given app, but at least to preserve baseline settings. Backups, including potentially voluminous video files and other materials, could fill gigabytes and even terabytes, while current settings and other typically synced information might require very little disk space.

In that light, synchronization could be seen as primarily a matter of convenience and efficiency (e.g., not having to remember which webpages were open on one’s desktop, or reconstruct the Google search that led to those webpages), whereas backup could be seen as a matter of digital survival, in the sense that the loss of irreplaceable photos or original document images could be devastating. It could be convenient and even important, for some purposes, to have a clear sense of what was being synchronized; but in many cases that would be largely distinct from the question of what was being backed up.

To some extent, backup and sync concepts seemed to be commonly confused in discussions of Android and Google capabilities. Synchronizing among devices would not necessarily preserve valuable data. For instance, mistakenly deleting a bookmark from within a browser on one device could result in its unwanted deletion from other devices as well. Without a backup, syncing could compound the original error. So, for example, How-To Geek (Hoffman, 2016) said the built-in Android Backup Service (ABS) would back up most data and settings associated with Google programs and services — but then proceeded to explain that this “backup” actually consisted of mere syncing.

Not to deny the usefulness of syncing. Google’s sync settings were visible on the phone at Settings > Accounts > Google. Mine said, “Sync is turned off.” That was apparently a consequence of the decision (above) to choose Settings > Data Usage > menu > uncheck Auto Sync Data, to reduce data usage and save battery power. I went into Settings > Accounts > Google > Gmail > tap each item that said, “Tap to sync now.” For some reason, Calendar was the only one that updated itself. It now said, “Last synced on 07/03/2017 5:18 PM.” None of the others said that; they all just said, “Sync is turned off.” I went into Apps > Gmail. It said, “Auto-sync is off. Tap to turn on.” I didn’t do that. Back in Settings > Accounts > Google, Gmail still just said, “Tap to sync now. Sync is turned off.” Apparently that’s how it was going to stay — I was not going to get confirmation of the last sync. To make sure, I posted a question on it. Then I discovered the answer to my own posted question:

If I turn auto-sync on (at Settings > Data Usage > menu > uncheck Auto Sync Data), and then go into Settings > Accounts > Google > Gmail, I still see “Sync is turned off,” but now I also see a checkbox allowing me to turn on individual items for syncing.

It seems I was getting a last-synced date and time for Calendar because it was the only one in the list with a checkbox. If I checked them all, and then turned off auto-sync, and then came back to this list of apps, I saw that all of them had last-synced notices, and those would be updated if I tapped again.

Eventually, it seemed, I might have to try auto-sync, to see whether it was really such a data or battery hog. Or possibly I could get into the habit of just turning it on and off briefly, now and then, to let everything sync.

Outside of Google’s own apps, How-To Geek (Hoffman, 2016) said that Android would automatically back up some system settings, in case of a factory reset or phone replacement, and that Google would remember and offer to reinstall any previously installed apps. But for any third-party app, the advice was to make sure it did synchronize with, or back itself up to, some location in the cloud. An example would be a password manager: LastPass was automatically cloud-synced, so a lost or destroyed phone would have no effect on its data (unless the finder was able to get into the user’s LastPass account), but KeePass was not cloud-synced, so losing the device on which it was installed would mean losing any passwords saved on it. Avoiding that outcome would require the user to make a specific effort or arrangement to export or back up the KeePass password list, and to make sure the resulting data file was saved somewhere other than on the phone.

How-To Geek (Hoffman, 2016) said Google and Android did not automatically sync or back up text messages, custom settings, Bluetooth settings, and security data (e.g., lock screen passwords). Likewise, for non-Google apps, it was apparently mostly up to the user to make sure that settings and data were being synced or backed up. So now, having considered the topic of syncing, I turned to the topic of backup.

On the PC, there were two general types of backup: system backup, in which a program (e.g., Acronis) would typically make an image of the entire system (C) drive, and data backup, focusing on individual files and folders that were not part of the currently running Windows OS. By contrast, there did not appear to be many options for making an image of the complete Android OS. One possibility was to root the phone (see above) and then use Titanium Backup. Alternately, it seemed I could use Android SDK to create a full backup. According to 1 2 3 sources, assuming that ADB and SDK were installed and USB debugging was enabled (above), the command to enter on the USB-connected PC, to accomplish the backup, was as follows:

adb backup -apk -shared -all -f C:\Users\Ray\backup.ab

In place of Ray (my name), other users would have to enter the appropriate name found in their own C:\Users folder. To enter that command, I went to C:\Program Files (x86)\Android\android-sdk\platform-tools in Windows Explorer, right-clicked on an empty space in that folder, and used Shift-right-click > Open command window here. As described below, that command would result in a “device unauthorized” error unless I enabled the “always allow” option that came up on the SGCP when I connected the USB cable; but leaving that option enabled after finishing this procedure would compromise security. Upon finishing all those preparations, and running the command, the command window responded with what appeared to be an error (“adb server version (31) doesn’t match this client (39); killing”; but then it looked like we were OK. I got this message on the phone:

Full backup

A full backup of all data to a connected desktop computer has been requested. Do you want to allow this to happen?

If you did not request the backup yourself, do not allow the operation to proceed.

If you wish to encrypt the full backup data, enter a password below.

For now, I skipped the password and just hit “Back up my data.” But the phone did not proceed to anything else. Instead, the “Back up my data” option was dimmed, and the focus was on the password box. But there was no keyboard to enter a password. Tapping on the password box solved that: a keyboard appeared. But the phone was still stuck otherwise. I went back to the earlier ADB instructions (above) and added the part about installing Java, which I had not previously done. Then I tried again. This time, no error message about “adb server version doesn’t match this client.” But the Full Backup was still hung on the phone. The solution was to treat the password as mandatory, not optional. Once I did that, I got a message, “Backup starting.” It was done almost immediately. I had a file: C:\Users\Ray\backup.ab. But it was only 1KB. Was that right? A search led to a StackExchange discussion and other materials suggesting the presence of multiple bugs in ADB backup and restore processes. I decided not to troubleshoot this option further at present.

Another possible approach to system backup was to follow instructions for making the Android system files accessible from the PC by connecting the USB cable. The instructions suggested using pull-down (i.e., stroke a finger downwards from the top of the Home screen) > Notifications > Connected as a media device > make sure Media Device was checked. But I didn’t find that necessary: the Samsung Galaxy was visible in Windows Explorer on the PC, displayed as though it were a storage device, as soon as I connected the cable. Right-clicking on a partition (i.e., either the phone’s Phone or Card partitions) > Properties yielded a description, “Generic hierarchical.” I was not sure what that meant. I had formatted the SD card as exFAT. Regardless, the generic hierarchical format appeared to make various files visible via Windows Explorer on the PC. But the Android (i.e., Linux) system files would not be visible that way.

If Android system backup was not feasible or adequate in a particular situation, it seemed the preferred response to OS corruption on the SGCP would be to use a factory reset. Presumably that would draw upon a backup stored in the phone’s ROM, inaccessible to the user. The general concept appeared to be that, if the phone got screwed up, a factory reset would restore it to original condition. (If the factory reset failed, perhaps there would be no alternative but to take the phone to a Samsung store, or replace it.) After a factory reset, it would be up to the user to restore everything else via synced apps and backed-up data files.

So much for the Android system, then. How about backing up user data files? This was largely a question of where the files should be backed up to, and how to get them there. Generally, the “where to” question was answered by (a) the cloud, (b) the SD card inside the phone, (c) a linked computer, or (d) possibly an external drive (see the Hardware section, below); and the “how” question was answered by (e) manual efforts (e.g., copy and paste in Windows Explorer) and (f) automated backup software. In other words, the user might be able to manually copy data files from the phone to the cloud, or to the SD card, or to an external drive, or to the PC; and s/he might also find software that would automate the copying process.

Depending up the amount of data involved, it might not be ideal to back up the full contents of an SD card to the cloud. An SGCP with a 128GB SD card, full of video and music files, could take a week (if not a month) to upload via WiFi. Cloud backup, if any, would be better reserved for smallish collections of data, especially those of a volatile nature, calling for prompt backup rather than waiting until the next time the user happens to be back with his/her PC. Even then, ZDNet (2016) recommended disabling cloud-based data backup, on the grounds that “law enforcement can demand that Google turn over your data.” While such a concern would once have seemed downright paranoid, times had changed: people were increasingly aware of abusive prosecutors filing false charges against which innocent individuals could not afford to defend themselves. For those who found it necessary to sign in using their Google account, ZDNet suggested various settings that would minimize exposure to data collection and ad targeting activities.

It might also not be ideal to back up from the phone to its own SD card. Losing the phone would mean losing both. But some otherwise desirable backup apps might be capable of only this sort of backup. They might offer an appealing automation of that process; they might conveniently package a mass of data files or other materials in the phone’s internal memory into a single ZIP file on the SD card. It would then be up to the user to make a manual or automatic arrangement by which the SD card’s contents (including that ZIP file) would be backed up to the PC — from which the user could then arrange sequential and/or offsite backups as desired.

For a good local (i.e., phone to computer) backup tool, AndroidCentral (Hildenbrand, 2017) pointed toward Samsung’s Smart Switch program (4.3 stars; also available on Windows and Mac). But Wikipedia said that Smart Switch was aimed toward newer devices; it sounded like Kies version 3 was the best choice for KitKat. Unfortunately, when I followed Wikipedia’s link to the Google Play page for the Kies app, I got an error message: “Sorry! This content is not available in your country yet.” That was puzzling: Samsung itself offered Kies versions 2.6 and 3.2 as well as Smart Switch. I downloaded, installed, and ran Kies 3.2 on the Windows 7 PC. From the websites just mentioned, I had not acquired a clear sense of whether wireless would work. It now appeared not to be an option for this phone and/or this version of Kies. With Kies running, I connected the USB cable. After a moment, Kies said, “The connected device is not supported by Kies 3. So, OK, I uninstalled it and tried again with Kies 2.6. When installation finished, I connected USB again. The Windows PC said it was installing drivers, then said, “Your device is ready to use.” But after a moment, Kies said,

Unsupported device alert

This device is not supported by Kies.
Make sure that your device is supported and try again.

Check the supported devices list.

The link to the Unsupported Devices List led to a Samsung Smart Switch page. So, OK, Kies was a bust. I uninstalled it and looked at the Smart Switch page. Smart Switch seemed to be designed for direct syncing of old and new phones. At the bottom, it pointed me toward Kies 2.6 for syncing with the PC. That was confusing. I decided to try from the SGCP end of the USB cable, with the Smart Switch app (below).

In the interests of product comparison, I thought I might also try a third-party backup app. A search led to advice from ProGeeksBlog, Wondershare, and MakeUseOf. Exploration of their suggestions, within my constraints (e.g., a non-rooted phone) and preferences (e.g., the option of backing up to MicroSD card) yielded the conclusion that I should start with Helium (4.1 stars). To get some experience, to help choose the better approach, and also to reduce the risk that I would wind up with a half-assed backup (as seemed my destiny), I decided to start with both Helium and Smart Switch (below). When those failed, I decided not to try other recommended backup apps, but instead just to make zipped backups of all visible contents via USB using Windows Explorer.

SGCP Modes

According to Recover-Android (Bruce, 2013), Android devices had six different modes: Normal, Safe, Recovery, Bootloader, Fastboot, and Diagnostic. The User’s Manual did not discuss such modes. By running various searches and checking various sources, I was able to identify these for the SGCP:

  • Normal Mode. Standard phone operating mode.
  • Recovery Mode. Recovery Mode was said to be useful for several technical purposes. To enter Recovery Mode, sources said, start with a phone that has been completely powered down (above). Then press and hold the Volume Up, Home, and Power buttons simultaneously, until you see the screen that says Android System Recovery. GoGoRapid (2016) said I could also reach that screen via ADB (above), with the command “adb reboot recovery.” Either way, the options visible on the Android System Recovery screen included Reboot system now, Apply update from ADB, Apply update from external storage, Wipe data/Factory reset, Wipe cache partition, and Apply update from cache. The instructions onscreen told me to use the Volume up/down buttons to highlight the desired item, and then hit the Power button to select it. I highlighted and selected Reboot system now. That worked: I was back in Normal Mode.
  • Download Mode. This was also known as Odin Mode. XDA-Developers explained that Odin meant “you are a God” — a reference, presumably, to an old Germanic god somewhat reminiscent of Gandalf. Odin Mode, apparently unique to Samsung, was apparently dangerous, insofar as it seemed many users’ phones became stuck in this mode and could potentially be bricked. The process of entry was almost identical to that of Recovery Mode, except that it used Volume Down rather than Volume Up. It seemed the purpose of Odin Mode was simply to flash (i.e., update) system firmware and the Android OS kernel. Fonepaw (Murray, 2016) said ROM flashing via Odin Mode required use of a USB-connected computer. The “Odin” name seemed overly dramatic: in my limited browsing, it did not appear that this mode provided the kind of comprehensive system control ostensibly provided by e.g., the so-called God Mode in Windows 7.
  • Bootloader Mode. How-To Geek (Gordon, 2016) indicated that unlocking the bootloader would be one way to root the phone. Gordon (2016) explained how to unlock the bootloader, and noted that not every phone would allow this. A discussion in XDA-Developers seemed to confirm that unlocking the bootloader was feasible in the SGCP. I did not investigate that process further. Summerson (2016) said that, actually, on a Samsung device, Bootloader Mode just meant Download Mode.
  • Safe Mode. In the event of app instability, according to Gizmodo, Safe Mode could help in troubleshooting. On the SGCP, T-Mobile said Safe Mode was entered by starting with a completely powered-down phone (above). The necessary steps were to press and hold Power; then, when “Samsung Galaxy Core Prime” appears onscreen, release power and immediately press and hold Volume Down until you see Safe Mode in the bottom left corner of the screen. T-Mobile said the purpose of Safe Mode was to uninstall troublesome apps. I had to hold Volume Down for maybe 30 seconds, but then Safe Mode did appear, as described, on an otherwise normal Home screen. To get out of Safe Mode, I held the Power button until I was given an opportunity to press Restart.
  • Diagnostic Mode. There appeared to be two distinct concepts of what this mode might mean. One approach involved using a rooted phone and/or Unknown Sources (above). A very different approach called for entry of a simple code, without rooting or Unknown Sources. The code for this latter approach was *#0*# entered on the phone dialer keypad, followed by tapping the dialer key. The latter approach, the only one I explored, then led to a selection among various items (e.g., Sleep, Speaker) that Diagnostic Mode would presumably test. I tried it with Dimming. I wasn’t sure what I was supposed to see, but what I actually saw was kind of pretty. I had to use the Back button, and a bit of patience, to get out of it.
  • Fastboot Mode. While some treated Fastboot as a mode, GadgetHacks (Bozzo, 2014) saw it more as a command-line tool (see also AndroidCentral, 2012). Bozzo said its uses included flashing (i.e., installing) a custom ROM (i.e., customized firmware), a custom recovery system, and a kernel (i.e., OS core), as well as changing the phone’s splash screen. XDA-Developers said a custom ROM could allow overclocking (to improve performance), underclocking (to improve battery life), upgrading to a newer version of Android (i.e., for the SGCP, at least Android 5.0 Lollipop), and customizing various aspects of the phone (e.g., screen colors). How-To Geek (Gordon, 2016) said that a custom ROM could provide a way to root the phone (above). How-To Geek (Hoffman, 2014) said that the stock (i.e., default) Android recovery was the thing that enabled Recovery Mode (above), and a custom recovery would have other features in addition to those in the stock Recovery Mode, such as creating and restoring device backups and installing a custom ROM. It seemed the Team Win Recovery Project (TWRP) offered a particularly popular recovery environment with easy-to-use touch buttons. MakeUseOf (Stieben, 2014) said that, as one would expect, a custom kernel could modify many aspects of the Android OS — in many cases focused, again, on improved performance or battery life. GadgetHacks (Thomas, 2015) said the first step, when attempting such customizations, would be to make a NANDroid backup — that is, a backup of the Android NAND flash memory. Thomas provided an explanation of how to do that using TWRP. I was not sure which of these various customizations would involve rooting the phone and/or violating the TracFone terms, or how risky they would be. KingoApp said that not all phones had Fastboot Mode, and that its installation would require the Android SDK (above). I saw indications that some people got stuck in Fastboot Mode, so I decided not to pursue this further at this time.
  • Sleep Mode and App Standby. The combination of different background experiences (with e.g., Windows 7) and different versions of Android seemed to confuse people regarding what it meant for an Android unit to be in sleep, standby, or (more recently) doze modes. According to Skillgun (2014), Sleep Mode meant that the CPU would go to sleep immediately after the display turned off, and would respond only to alarms and incoming text and call information. Describing older versions (apparently applicable to the SGCP), AndroidForums (Erisuser, 2010) said that apps (e.g., listening to music) could prevent the CPU from shutting off after the screen went dark. Thus, Sleep Mode on an Android was somewhat like sleep on a Windows 7 machine, where touching the mouse would awaken the machine unless that behavior was turned off. Greenbot (Whitwam, 2016) said that Android 6 brought App Standby:

An app on Android 6.0 defaults to Standby unless one of three things has happened in the last several days — the app has a foreground process active, you explicitly launch the app, or the app produces a notification.

An app that goes into Standby loses all network access and all its background sync jobs are suspended. These restrictions are temporarily lifted when your phone is plugged in and for a few minutes every day or two. This gives suspended apps a chance to run any pending sync jobs, but they won’t be allowed to continue running. A high-priority push notification will also be able to wake an app from Standby for a short time.

  • Doze Mode. Whitwam (2016) said Doze Mode debuted in Android 6. Some apps (below) emulated some doze-like features for pre-Marshmallow versions of Android. Lifehacker (Ravenscraft, 2017), seconded by an app developer, said such apps could actually be superior to Doze Mode, insofar as they would offer greater functionality and/or would funnel all data through a VPN that could control incoming data. For example, Greenify could activate its Doze-like features after minutes, where Doze might wait hours to kick in; unlike Doze Mode, apps would not necessarily require the device to be immobile and/or unplugged with the screen off. As another example, ForceDoze could turn off the app’s doze mode while the unit was charging, or could disable motion sensing or WiFi whild dozing. AndroidCenter (Hildenbrand, 2015) worried that the VPN could enable the app developer to monitor all traffic on individuals’ devices. Regarding Doze Mode itself, How-To Geek (Hoffman, 2016) said,

Android phones and tablets will “sleep” when you leave them alone . . . . [This sleep] allows apps to run in the background, checking for new data, receiving notifications, and generally doing whatever they want. . . . Doze kicks in when you aren’t using your device. . . . [It keeps your phone in] a deeper sleep mode . . . . [where] only high priority notifications, like phone calls and chat messages, will wake the phone. Apps won’t be allowed to constantly sync in the background. [Lifehacker (Ravenscraft, 2016) says, “That’s why apps like Facebook kill your battery, even when you’re not using them.”] Instead, Android provides “idle maintenance windows” every once in awhile, where apps can do all their work in one big batch. As time passes without you using your phone, those windows come further and further apart. . . . [Apps] can mark their notifications as “high priority” . . . . High priority notifications have to be delivered through Google Cloud Messaging, which means Google has control over them. If they find that an app’s developer is abusing these notifications, Google can cut them off. . . . [I]f you want notifications from a certain app the minute they come through . . . you can give it permission to run while dozing. . . . [Some third-party apps, e.g., Greenify allow] you to tweak various parameters and load profiles, making Doze more or less aggressive.

  • Other Power-Saving Modes. Samsung (2017) described Power Saving Mode and Ultra Power Saving Mode. Power Saving Mode was supposed to be available at Settings > Battery. It did not appear on my SGCP. Ultra was available at Settings > Ultra Power Saving Mode. My SGCP did not have Settings > Power Management options (available to at least some Sony users) to set a power off timer.
  • Other Modes. The User’s Manual mentioned other “modes.” These appeared to refer merely to one or more settings, chosen to achieve a particular purpose. Examples included “mute mode,” “predictive text mode,” and “flight mode.”

As those descriptions suggest, some such modes could be risky. I mention them here primarily for purposes of reference, as some of them were mentioned in other materials discussed below.

Other Tweaks and Tools

  • Troubleshooting. LoadTheGame (Kilin, 2015) listed several problems experienced by some Android users. These included overheating, keyboard lag, and WiFi signal problems. Depending on the problem, Kilin recommended various troubleshooting steps. These seemed to boil down to this sequence: first, reboot the device. If that doesn’t solve it, reboot into Safe Mode (below). I did not investigate that step, but the idea appeared similar to Safe Mode on a Windows PC: safe mode would test whether the system would run properly with only minimal software running. If so, then the trouble may be due to an app running in Normal Mode. If necessary, do a factory reset or ship the device back to the manufacturer if it’s still in warranty. Finally, consider installing a custom ROM (below).
  • Guest Access. This is a negative comment — that is, a report of functionality that is largely not available. The question: is it possible to set up the phone so that someone else can use it, without yielding access to private information? The short answer appeared to be no, on an unrooted KitKat phone. The best alternative appeared to be to use a good app-locking app. AndroidAuthority (Hindy, 2017) and others generally seemed to favor AppLock by DoMobile Lab (4.4 stars; described as the most downloaded app on Google Play, with 4.2 million downloads). The drawback would be that the phone’s owner would have to unlock apps each time s/he wished to use them.
  • Vysor. I noticed a funky option of viewing the Android screen on the PC (running Windows, Linux, or Mac), using Chrome on the PC with the Vysor extension. I pursued that briefly. Once I installed Vysor, the Chrome Web Store page changed to give me a Launch App button. When I did that, I got a popup window telling me to click the Find Devices button in the upper left corner. Then, in another pop-up, I had to click on my phone and click the Select button. Now, in the bottom right corner of my screen, I got a message:

    An error occurred while connecting to the Android device. Restarting the Vysor app, or disconnecting and reconnecting the Android may resolve this issue.

    I decided not to go further down this path for now, reasoning that (perhaps with a reboot) its solution would eventually emerge. If not, and if I decided I really needed or wanted the Vysor functionality, I would start with a search.


Mobile security called for certain system settings and precautions. The topic was complex enough to deserve separate treatment in its own (large) section.

Criminal Methods

One question was, how do criminals actually use smartphones? I ran a search and came up with some interesting materials. According to CNet (Nieva, 2014), one in ten smartphone users in the U.S. have had a phone stolen. Nieva related stories about thefts from people walking down the street in San Francisco, eyes glued to the screen, not paying attention to their surroundings. A thief could grab the phone, run, and quickly unload it at

a plaza downtown that’s well-known as the place to buy and sell stolen phones. . . . Black-market buyers are looking for phones that are unlocked, or unprotected by the security features that make them harder to restore to factory settings. . . . AT&T and T-Mobile phones rake in the highest take, Greg says, because they’re configured for global communications and therefore are easier to resell overseas.

Nieva indicated that authorities hoped that kill-switch software, quickly rendering a phone useless, would deflate the market for hot phones. Evidently it worked: Consumer Reports (2015) noted a sharp drop in smartphone thefts as manufacturers implemented those switches. But there were caveats. The technology did not arrive in Androids until Lollipop, leaving my SGCP unaffected; also, there were different implementations. According to Sophos (Zorabedian, 2015), in Lollipop 5.1, Google implemented a Device Protection scheme sufficient to meet legal “kill switch” requirements, such that the phone could be locked and its data deleted remotely. And yet, according to AndroidPolice (Ruddock, 2016), it was not clear when, or if, Google would enable an option to truly brick an Android device, in the sense of making it unrecoverable without “dedicated JTAG hardware” — which, according to comments in an AndroidEnthusiasts discussion (2015), would typically cost “a couple hundred US dollars” and would be best used by someone with a “background in electrical engineering” (see XJTAG).

InformationWeek (Zeman, 2015) observed that the implementation of kill switches was only somewhat effective in reducing phone thefts. In Paris, for example, Claire (2016) said that cellphone pickpocketing was still targeting tourists, seen using their cellphones, who were followed until an opportunity presented itself. Closer to home, U.S. Federal Trade Commission fraud investigator (Roth, 2017) described how a thief got her phone, containing “everything” in terms of personal and financial data; turned it off, so that the Find My Phone feature (below) couldn’t help; and deprived her of material that proved irreplaceable, because she had no recent backup. Roth advised several precautions, most of which are discussed in this section (below), along with a few other options she did not mention:

  • Lock your phone, using at least a six-digit passcode.
  • Update it and back it up.
  • Install and turn on the Find My Device app.
  • Notify your wireless provider as soon as your phone disappears.
  • Turn on two-factor authentication in your accounts.
  • Know which devices have access to your accounts, so that you can log into the accounts and remove devices from them.
  • See if your email or social media accounts notify you of attempts to connect to your account or to change your password.
  • If you lose your phone, change all passwords to which it had access (e.g., banking, email, social media, shopping).

Yet, reading comments following her article, it was not surprising that some opted not to use their phones for anything valuable, or kept their passwords on a page or in a file at home (which would, of course, have their own security vulnerabilities).

It was not clear that security options were always keeping up with the bad guys. For example, my SGCP did not have a fingerprint reader, but conceivably that was just as well. I had worked at a supposedly maximum security prison where fingerprint scanning entry would often accept any finger from either of my hands and, sometimes, someone else’s finger. Even worse, The Verge (Brandom, 2016) said that a security researcher was able to produce a working model of the fingerprint of Germany’s defense minister, just by using a high-resolution photo of the minister’s hand. Brandom said, “The bad news is . . . you can’t change your fingerprint, so a single credential theft creates a lifetime vulnerability.” As another example of not necessarily keeping up, Wired (Fenton, 2013) argued that

[T]wo-factor authentication [2FA] is fraught with difficulties. . . . Most two-factor authentication technologies don’t securely notify the user what they’re being asked to approve. Therefore, it’s too easy for an inattentive user to approve an attacker’s transaction without knowing it.

To illustrate that last point, SmartVault (Gutierrez, 2016) described a 2FA scam to which a key item of advice was, never text your authentication code to anyone; use it only to log into your account. But how many users were unaware of that advice, and how many were confused (as I had been) by 2FA? According to KnowBe4 (Sjouwerman, 2017), a company would send a code to one of its users only after the user attempted to log in — so if you did not just try to log in and yet, out of the blue, you received an alleged verification code, that was a sign something suspicious is happening. In another description of that scam, Business Insider (Price, 2016) noted,

The attacker can sometimes even spoof their identity — so the text looks like it comes from Google, or Facebook, or Apple, rather than an unknown number. . . . Huge databases of tens of millions of email addresses and passwords have been floating around in the last few weeks — notably from LinkedIn and MySpace. So if you reuse passwords, your login details may be being shared online right now without you realising.

(One way to find out whether a user’s account was compromised in a data breach was to enter his/her email address or username at HaveIBeenPwned. This would be a warning to change passwords (and perhaps also usernames) promptly.) LogDog (Toppol, 2015) said that two-factor authentication could also be hijacked by infecting the user’s PC first, displaying a pop-up that would tell the user to send a text message to the hijacker’s phone number, in order to get a link for downloading an so-called security app. The user following this procedure would thus help the hijacker redirect the bank’s (or whoever’s) real two-factor authentication codes to the hijacker.

As suggested by that discussion of two-factor authentication, some of the spookiest criminal uses of unknowing individuals’ cellphones did not involve phone theft. Consider these concerns from InstantCheckmate (Smith, 2015):

  • MSpy, a supposedly undetectable app advertised as useful to “[r]emotely track and control activity of employees,” was capable of tracking all calls, looking through emails, monitoring Internet use, controlling apps, tracking GPS location. As countermeasures, Smith said experts recommended using a strong password (below).
  • The tilt sensor on at least some newer phones was sensitive enough to read vibrations from a nearby computer keyboard with 80% accuracy. This information would potentially be available to anyone who managed to install spyware on the phone. Smith recommended keeping the phone stashed, well away from the keyboard.
  • A hacker gaining access to a smartphone equipped with Near Field Communications (NFC) would be able to read the Radio Frequency Identification (RFID) chips that had been more frequently installed on debit and credit cards in recent years. Smith recommended using an RFID-blocking security wallet. Another option was to get rid of those cards.
  • If hacked, smartphones used to program “smart” home locks, security systems, and appliances would give the hacker power to alter or disable any connected device. Smith’s suggestion: use devices with 128-bit encryption, and password all devices.
  • Free public phone charging stations were able to infect a phone within one minute of being connected. Suggestion: invest in a portable battery.
  • WiFi of any sort (including personal WiFi hotspots) must be password-protected to prevent hackers and criminals from piggybacking. Logging into seemingly innocuous public WiFi networks (e.g., “Starbucks”) that were actually created by a hacker could leave a connected device wide open to attacks. Warning: never connect to public WiFi without absolute certainty it is safe. Promon (Birkeland, 2016) narrowed that, warning especially against making payments over public WiFi.
  • The top 10 flashlight apps (i.e., apps designed to use the phone as a flashlight) on Google Play were all spying on their customers. Their privacy policies contemplated reading contact lists, writing programs, and viewing mobile banking information. Advice: delete all such apps; change passwords on sensitive accounts accessed while the app was installed.
  • The phone’s gyroscope (i.e., an internal sensor detecting movement or orientation) could be used as a microphone, even if the phone’s actual microphone was turned off. Recommendation: disable Bluetooth, to prevent roaming hackers from discovering your phone. Smith also mentioned jailbreaking but not rooting, though my reading suggested that both could bring security vulnerabilities (see Hoffman, 2013).
  • Pictures taken by a hacked Android phone’s camera could be sent anywhere without the owner even knowing that a photo has been taken. Military software even allowed hundreds of surreptitious images to be taken and used to reconstruct the user’s environment. Advice: don’t point the phone toward anything you don’t want the world to see (e.g., put it in a drawer, bag, or case, such as the EyePatch); don’t take sensitive images and, if you do, don’t store them on the phone.

A Federal Commnications Commission (FCC) webpage listing a number of mostly common-sense precautions to prevent phone theft and protect data. Among those precautions, one was perhaps less obvious:

Note the device’s make, model number, serial number and unique device identification number (either the International Mobile Equipment Identifier (IMEI) or the Mobile Equipment Identifier (MEID) number or the Electronic Serial Number (ESN)), usually found in your device settings or printed on a label affixed to your device underneath the battery. The police may need this information if the device is stolen or lost.

On the SGCP, the IMEI was visible inside the battery compartment, on its packaging container, probably in the invoice, at Google Dashboard, and also at Settings > About Phone > Status. I took a photo of the former and kept it with a scan of my receipt. The Settings screen could be saved by taking a screenshot (above). With the IMEI, IMEI Detective provided a database in which users could look up the numbers. The bad news was that, according to India Times (Anwar, 2016), theives or their fences were able to flash phones, permanently altering their IMEIs and making them untraceable. Wired (Shaer, 2014) offered a fascinating account of smartphone crime. Consumer Reports (2014) listed additional steps to take when the phone was lost, and also when (if) it was recovered.

Strong Passwords

In 1 2 previous posts, I summarized the current wisdom on passwords. This section combines the gist of those previous remarks with newly encountered material.

Much password advice was oriented toward choosing passwords that would resist brute-force attacks. A brute-force attack was one in which a computer would go through all of the possible combinations (e.g., aaa, aab, aac . . .) until one was found that would work. Hence, the current advice was that a strong password would have at least 12 (some said 10, 11, 16, 20, or some other number of) characters (but never fewer than eight), and would include upper- and lower-case letters, numbers, symbols, and spaces. Tools used by password crackers reportedly included HashCat, RAR Password Genius, and John the Ripper, along with others recommended by Infosec Institute (2017).

Password checking websites provided a sense of how long it would take a brute-force attack to guess a password of a given length and complexity. But Carnavalet and Mannan (2015) found that such online password checkers varied dramatically in their reliability:

[M]ost meters in our study, which includes meters from several high-profile web services (e.g., Google, Yandex, PayPal) and popular password manager applications (e.g., LastPass, 1Password) are quite simplistic in nature and apparently designed in an ad-hoc manner.

Sophos (Stockley, 2016) indicated that, nearly two years after that previous research, this situation had not changed. I tested various bad passwords, suggested by these researchers, on several online password checkers suggested by these and other sources. My findings:

  • zxcvbn (demonstrated by Dropbox; approved by Stockley; see discussion) indicated that all of these passwords would be identified within three minutes in an unthrottled online attack, and within one second in a fast-hash, multicore offline attack, usually because they are very common: abc123, ncc1701, iloveyou!, primetime21, qwerty, querty1, Password1, Password$1, password0, and password0+, and password$1 would be identified within 30 minutes online, and still within less than a second offline.
  • cupslab (profiled by BetaNews, 2017) rated all as too short, extremely common, or very easy to guess.

By contrast against those two critically praised password checkers, consider what I found in several alternatives:

  • Mato Ilic’s PWStrength (considered by Stockley to be an example of typical password testing strategy) rated most of those as weak, but rated several as mediocre (i.e., iloveyou!, password0+, password$1) or strong (i.e., Password$1).
  • Lastpass rated most of those as too weak, but considered some very strong (i.e., primetime21, Password1, Password$1).
  • Google (login required) rated most as too short, but rated some as fair (i.e., iloveyou!, password0), good (i.e., primetime21, Password$1, password$1), or strong (i.e., password0+).
  • OnlineDomainTools rated all as being of dangerously low strength, but rated several as medium (i.e., password0, password0+, password$1) or fairly good (i.e., Password$1).

It appeared that some checkers relied solely on the number of calculations necessary for a brute force attack. From that perspective, the situation was clear enough: it could take a very long time for an attacker to get anywhere. Elcomsoft (Afonin, 2017) offered some examples based on the elPassword calculator. For instance, as anyone can verify by counting from one to a million, there are 1,000,000 possible combinations (starting with zero) if you use a password of up to six digits. Divide that by the number of passwords that can be tried per second, and you have the number of seconds required to brute-force the password. Thus Afonin calculated, for instance, that an attempt to crack an eight-character (upper- and lower-case alphanumeric) RAR5 password, on a machine equipped with a powerful graphics processor, would take 273 years, as compared to only two hours for that same machine, if the password was only six characters.

The problem, Afonin said, was that hackers would not necessarily want to spend 273 years at this, and therefore found it expedient to devise workarounds. One workaround was to use a dictionary attack, defined by Wikipedia as a password cracking approach that tries each item in a list, typically including ordinary dictionary words and other relatively obvious series of characters by themselves, in combination, or with relatively simplistic modifications. The items tested above (e.g., ncc1701, the number of the USS Enterprise in Star Trek) would only occur to about a billion people, and as such would merit inclusion in such “dictionary” lists. Much the same was true for obvious substitutions (e.g., substituting L for 1 or O for zero), and for such variations as abcd1234, which could be made stronger (in the sense of being less likely to appear on a dictionary list) by scrambling its characters in a way that the user might still be able to remember (e.g., a4b2c1d3) (see e.g., How-To Geek, Hoffman, 2015).

According to Ars Technica (Goodin, 2013), password crackers could have access to dictionaries containing a billion different passwords. That may sound like a lot, but it would be tiny compared to the endless trillions of combinations to be tested in a brute force attack against a long password. In the test Goodin was writing about, three skilled crackers were given a list of about 16,000 hashes. A hash was an encrypted version of a password. The user might enter password1, but its hashed (and stored) counterpart would be 7c6a180b36896a0a8c02787eeafb0e4c. As described by Wikipedia,

Storing all user passwords as cleartext can result in a massive security breach if the password file is compromised. One way to reduce this danger is to only store the hash digest of each password. To authenticate a user, the password presented by the user is hashed and compared with the stored hash.

The challenge for a hacker, coming into possession of a trove of hashes stolen from a company, would be to convert those hashes back into usable passwords that could then be sold or exploited. Ars Technica watched those three cracking experts convert up to 90% of those 16,000 hashes back into usable passwords within just a few hours. With the aid of their dictionaries and graphics processors capable of processing eight billion guesses per second (or 350 billion per second, if using one hacker’s five-server system) — along with hybrid dictionary-brute force (e.g., append all possible two-character strings to the end of each dictionary word) and combinator (i.e., combine every word in the dictionary with every other word in the dictionary) methods — the hackers were able to figure out, in a very brief time, that someone’s password was momof3g8kids, even though its 12 characters would have taken many years in a strictly brute-force attack. A different example: Intel estimated that it would take six years to crack the password BandGeek2014, and yet these three hackers all got it within 30 minutes — because they weren’t using mere brute-force attacks.

Ars Technica recommended passwords consisting of at least 11 characters, including numbers and upper- and lower-case letters (and, presumably, special characters, if allowed by the website or program in question). Other advice was to use a unique password for each website or other application; use random arrangements of characters, not words that can be found in a dictionary; and avoid often-used combinations (e.g., one uppercase, five lowercase, and three digits). Dropbox offered other suggestions: several uncommon words used together; nonstandard uppercasing (e.g., aPple); creative spelling (e.g., speling); personal slang; inside jokes. More suggestions: don’t use personal information; update passwords at least every six months; avoid foolish password mistakes.

There seemed to be many schemes for remembering complex passwords. Those that seemed most practical were to remove letters (e.g., vowels) (e.g., “miss you very much” > mssyvrymch) (WikiHow); to move fingers a bit on the keyboard (e.g., to the left one key) and then type a memorable phrase in that position (e.g., hitting “s” for each occurrence of “d” in the phrase); to convert a phrase into a set of symbols, such as summarizing “Rent was $400” with “Rw$4” (How-To Geek) or “Tramps like us, Baby we were born to run” with “Tl|_|,BwwB2R” (USA Today).

With a strong password and a good encryption system, it could be very difficult (sometimes, with luck and planning, potentially impossible, at least for now) for anyone, including national security agencies, to break into one’s data.

Samsung Security Options

I started with Samsung’s Find My Mobile page > Prepare: Ready Device for Find My Mobile. The page told me that, to use the Find My Mobile feature, I needed a Samsung account registered on the device and Remote Controls enabled. The instructions there told me to go to Settings > Security. There, I saw Remote Controls: On and Reactivation Lock: On. But I didn’t see “Find My Mobile.” The instructions said, in that case, my device did not have the feature. But Samsung said it was a feature of the SGCP. Only one way to find out: back at the initial Samsung page, I went to Find > Sign In. It began trying to locate my device. It found it, displaying a map of where I was. So that answered that question: my TracFone SGCP did have Find My Mobile.

On that same screen, I tried Ring My Device. That worked: a black screen came onto the SGCP, bearing the words, “This device has been lost,” accompanied by a loud tune (even though I had turned the volume down), and that kept repeating until I swiped the red X at the bottom of that screen to shut it off.

I also tried Lock My Device. That told me to enter a four-digit PIN. It gave me the option of entering a phone number that could be called even from the locked device. I didn’t do that. Presumably the purpose was to tell the finder how to find me, so as to return my phone. The other option was to choose a message to display on the screen of the locked phone. There was already a default message, so I left it at that. I clicked Lock. That worked. The phone’s screen said, “Phone Locked,” followed by that default message and a keypad. I entered the PIN on the keypad > OK. That worked: the phone was unlocked. The PIN did not endure: it was there only for that one use. In other words, if I hit the Power button to turn the phone off and back on, there was no longer a need to enter the PIN. I was back at the default setting: I just had to swipe to unlock.

On the Samsung webpage, I tried Retrieve Logs. Oddly, it displayed only one item, and that was from the previous day. A search yielded no insight. I did not try Wipe My Device or Unlock Reactivation Lock. I was not sure whether Wipe My Device would require the Google Settings option to “Allow remote factory reset” (below).

Samsung also offered security options for the SIM card:

  • SIM Card Lock. T-Mobile explained that a SIM PIN code could protect my SIM from being used in other devices. According to TechRepublic (Wallen, 2014), without this (even on an encrypted phone with a lock screen), others could use my phone number, security data, and billing information simply by removing the SIM card from my phone and inserting it into theirs. Wallen said the default PIN (if any) was most often 0000 or 1111. To set this up, I went into Settings > Security > Set Up SIM Card Lock > Lock SIM Card > enter default PIN. I tried 0000. That produced “Unable to change SIM card lock state. Possibly incorrect PIN.” I tried again with 1111. That worked: the box was now checked. The SIM PIN did not seem to do anything when the phone was already running. To see what it did, I held the Power button > Power Off > OK. After the phone shut down, I held the Power button to turn it back on. Now I was looking at a numeric keypad and a scrolling message at the bottom: “SIM card is locked. Searching for service.” I entered 1111. It said, “Unlocking SIM card,” and then I was back in. That was what happened when I had no screen lock enabled. I enabled a pattern screen lock, powered down, and tried again. It gave me the SIM card keypad first, then the pattern matrix. The latter was a little scary: it seemed to expect me to rip right through it — any pause resulted in an “Incorrect pattern” error. Maybe it was always like that; maybe I lacked experience in pattern entry. Wallen provided information on the PIN Unlock Key (PUK) that the user would need to unlock the phone if s/he couldn’t get past the SIM card lock. A brief glance suggested there might be ways to bypass or defeat a SIM PIN lock. For example, Wondershare offered a few methods, one of which was to use a Dr.Fone module (below).
  • SIM Change Alert. I did not find a lot of guidance out there, for this one. The steps I took were as follows: In Settings > Security > SIM Change Alert, I entered my Samsung password (i.e., the one I would use to access my Samsung account online) > top of screen: turn it on > enter Alert message (maximum 18 characters) > identify up to five people to notify (via phone number) > Save (top right corner).

Google’s Find My Device

As an alternative to the Samsung approach, AndroidPit (Marshall, 2015) recommended going into Apps > Google Settings (i.e., not ordinary SGCP Settings) > Security (not Sign In & Security) > Android Device Manager > enable both Remotely Locate This Device and Allow Remote Lock and Erase. Both were supposed to be already turned on, by default, but it was wise to double-check.

“Android Device Manager” (ADM) was the name of this service on my phone, but ADM had recently been renamed as Find My Device (FMD). ADM/FMD could be accessed by website and also as an app. This subsection discusses the website. But I also installed the app, partly in case someone else needed my help, and partly just to have convenient access to relevant information.

In the event of actual phone disappearance, Marshall’s older article recommended using the options provided by ADM (now FMD) in this order: first, make your phone ring, to insure it’s not just misplaced nearby; next, change the lock screen to display a message (e.g., “Please call me,” perhaps with an offer of a modest reward); if no response, erase your data (equivalent to a full factory reset, effective for an offline phone as soon as it comes back online), revoke access for your missing phone in your Google account, and change passwords to which the phone might have had access.

To learn about FMD, I went into my Google account (on my PC) > Manage Your Location > look at (1) Manage or Delete Your Location History, (2) Turn Location On or Off for Your Device, and (3) Manage Location Settings for Apps. The basic idea, elaborated by those websites, was that you could control which apps are informed of the location of your device (which, for many users, could raise uncomfortable privacy issues); you could turn your device’s Location Mode on or off, and adjust its accuracy; and you could control how much location information Google would keep.

As I poked around in those options, I saw that my Samsung settings were not necessarily reflected in my Google settings. For instance, as described above, I had previously turned off Settings > WiFi > menu (top right corner) > Advanced > Always allow scanning. The description accompanying that option said, “Let Google Location Service and other applications scan for Wi-Fi networks, even when Wi-Fi is off.” I turned that off to reduce battery use. But now, when I went into Apps > (Google) Maps > menu (upper left corner), I saw that Wi-Fi Only was turned off. I turned it on. The accompanying note said, “Wi-Fi Only turned on. When there’s no Wi-Fi network, only your offline maps will work.” To a newbie, this seeming inconsistency (i.e., Wi-Fi turned off in Settings, but still on in Google Settings) could be disorienting. This sense of disorientation might have been reduced if, for instance, a change to Wi-Fi only in the phone’s Settings had provoked a follow-up question as to the user’s preferences in the related Google Settings. As it was, I could not be entirely sure of which instruction would control, if the Samsung and Google settings were inconsistent.

For now, I decided to maximize security rather than privacy. Thus, as advised, I went to Settings > Location > turn top switch On and set Mode to High Accuracy. Those settings were already in place. (At this point, I was not sure whether I had set them or they were the defaults.) At this same screen, I went into Google Location History. It was turned on. I left it there.

To access Location History and other matters, I went to Google’s My Account webpage. After signing in there, I saw options for Find Your Phone and Manage Your Google Activity. In the latter, I went into Activity Controls. There, I saw, again, that Location History was turned on. Meanwhile, in the Find Your Phone option at the My Account webpage, I clicked the arrow to continue, re-entered my Google account (not phone) password, and saw that Google was proposing to take me through a sequence of steps somewhat like those suggested by Marshall (above): make the phone ring; then lock the phone; then try calling the phone; then sign out on the phone; then “Reach out to your carrier”; then “Consider erasing your device.”

To use those options, according to a Google webpage, the phone would have to be turned on, signed in to a Google account, connected to mobile data or WiFi, and visible on Google Play, and its location and FMD both had to be turned on as well. I was not sure where the foregoing options led, but this other Google webpage provided a link to There, I saw a map showing where my phone (and I) were, listing my battery power and the WiFi network to which the phone was connected, and offering just three options: Play Sound (“Device will ring for 5 minutes even if set to silent”), Lock (“Lock device and display message or phone number”), and Erase (“Erase all content from the device. You will no longer be able to locate it”). I tried Play Sound. It worked. I got a pleasant melody with a hint of reggae. Pressing the phone’s Power key stopped it.

Third-Party Lost-Phone Apps

The Android Lost app (a/k/a Lost Android) provided another way to deal with a lost phone. TrendBlog (Knoll, 2017) and Wallen (2014) recommended it as an alternative to FMD. How-To Geek (Hoffman, 2013) explained how to install Android Lost remotely on a lost phone. Unfortunately, Knoll said, Android 3+ eliminated that option. AndroidCentral (Lagace, 2016) named other third-party apps (below) with similar functionality.

While Lagace felt that the Google option (above) was the best, it was tempting to consider the capabilities offered by these nonfree alternatives. Those capabilities included tracing capabilities (i.e., identify the cell and/or WiFi network currently connected); remote file retrieval; anti-thief tools (e.g., record audio; take screenshots, pictures, screenshots, and/or videos); and remote command execution.

For a phone of this value, in a city whose police force had previously displayed a lack of interest in petty crime, I was not confident that even a solid record of unauthorized web access by a photographed thief would yield meaningful results. For me, then, an investment in even an inexpensive lost-phone app seemed unnecessary. I could imagine alternate uses of such tools (e.g., taking photos remotely, when I was not present in the same room or building as the phone, which could perhaps be concealed) — but, again, I did not personally need anything like that.

Default and Third-Party Lock Screens and Widgets

The option to limit access to the SGCP’s contents was available at Settings > Lock Screen > Screen Lock. There, the phone offered several choices, in order of increasing security. The first two were None and Swipe. Swipe was the default: a new user could access the phone by just swiping a finger across the screen. The more secure options were Pattern, PIN, or Password. Pattern meant that I would have to draw lines, in a certain pattern, on a 3 x 3 matrix (e.g., down one step, right two steps, up one step). The User Manual (p. 38) said that the Pattern option included the option of a backup PIN in case I forgot the pattern. The PIN option (by itself, or with Pattern) had to include at least four digits. Password had to be at least four letters, numbers, or symbols. As alleged in security discussions, I found that the phone would not allow me to reverse direction (e.g., to go down one step, and then back up one step), but it would allow me to revisit the same dot from a different direction.

For most purposes, this Screen Lock option could be the only thing preventing someone from accessing, using, deleting, or screwing up everything on my phone, and every account to which the phone might have access, not to mention making or sending undesirable outgoing calls, texts, and emails in my name. In that light, it seemed obvious that I would want a very secure limit on access. As advised by ZDNet, I was inclined to go with a password of at least six characters, to reduce the risk of brute force unlocking – though I was not sure whether a thief or finder would be able to use any password-entry method other than manually typing characters, in which case four digits would be plenty.

On the other hand, I would have to be entering this pattern, PIN, or password every time I wanted to use the phone. That could be a real hassle, considering that the phone was set, by default, to go to sleep within a few seconds. I could spend half my day just re-entering the password every three minutes. I could set that timeout period to be much longer, but doing so would make the phone’s contents available if I turned my back on it while it was still awake, not to mention that a long timeout would use up battery power.

Recognizing this problem, Android was improved to add a Smart Lock feature. How-To Geek (Klein, 2014) described Smart Lock as a setting that allowed the user to set trusted places (e.g., home) where the phone would not lock, trusted devices (e.g., a Bluetooth headset), and trusted faces (e.g., yours). Collectively, these trusted entities would keep the phone from locking or would unlock it without manual effort. TechRepublic (Wallen, 2015) criticized the trusted device aspect, offering the scenario where a thief takes both the phone and the Bluetooth device and thus gains access to the user’s data, and Wallen accordingly recommended not using the trusted device aspect; but otherwise the convenience of this feature was undeniable.

The bad news was, Smart Lock only became available starting with Lollipop (i.e., version 5). The good news was, it seemed this functionality could also be added retroactively to KitKat (i.e., Android version 4.4). The bad news was, the software adding it appeared not to have progressed past the alpha level. Entrust the security of my device and its contents to alpha software, created by people who admit this is their “first ever app”? I don’t think so.

In other words, I found myself wondering whether third-party lock screen apps could provide Smart Lock technology on KitKat. I did not find many lock screen apps that offered anything like the later Android Smart Screen technology. Microsoft’s Next Lock Screen (4.2 stars) appeared to be the best of the lot. Alternately, MakeUseOf (Shanbhag, 2014) recommended Llama (4.5 stars), providing a detailed explanation of how to set up the screen lock feature.

If I did decide to use widgets (above), there was the option of using a default or third-party lock screen widget. To do that, Cult of Android (Bell, 2013) and How-To Droid (n.d.) said I could go to Settings > Security > Enable Widgets. But I did not have that option. I had already seen (above) that I could go to Home > press empty spot on screen > Widgets > scroll to the right. That all worked, but I did not see a lock screen widget. It seemed widgets were enabled automatically, else I would not have seen those options when I pressed on the Home screen. Evidently I would have to add a third-party lock screen widget. I already had recommendations for the two screen lock apps mentioned in the previous paragraph, so I let it rest there.

Methods of Bypassing the Lock Screen

As just described, security would call for a long password; but for a user who wanted to be able to get into the phone quickly (and especially for one who would be accessing the phone and then letting it sleep repeatedly, throughout the day), a long password could become an annoyance and an impediment.

A long password would also be pointless if GadgetHacks (Thomas, 2015) was correct in saying that there were at least seven ways to bypass the Android lock screen. This would be news to the writers of the User Manual: in the event of lockout, it simply advised me to “take the device to a Samsung Service Centre to reset it.” As described above, I had already been introduced to two of those seven ways, involving the Samsung and Google device-finding services. My concern (above) had been with finding, locking, and possibly erasing a lost phone. Now I revisited those two specifically for the purpose of unlocking a phone. I also investigated the rest of those seven, along with a few suggestions from other sources.

Note that data on a phone’s SD card would tend to be available to a person possessing the phone. That data could include app settings, documents, and anything else that the user had put on the SD card. A thief or finder of the phone could simply remove the SD card, plug it into an adapter, and read it on a computer. The lock screen would protect only the internal contents of the phone. Data on the SD card would need to be secured separately.

Note also the option, at Settings > Lock Screen > Screen Lock, to turn on Owner Information, which I interpreted as an opportunity to put my name on the lock screen, so as to immediately confirm my ownership in case I caught someone with my phone.

1. Samsung Phone-Finding Service. I went into Settings > Lock Screen > Screen Lock. I chose the PIN option and set a four-digit PIN. (I noticed the Lock Automatically option in that menu said, “Screen will be locked in 5 seconds after screen automatically turns off.”) Then, following the GadgetHacks instructions, on my PC, I went to Samsung’s Find My Mobile page > Unlock My Device. It asked for my password. I entered my Samsung password – not the phone’s PIN that I had just keyed into the phone. That worked. The device was on, and the PIN login option was shut off: all I had to do was swipe across the screen, as in the original setup, to use the phone. So this would not be something to do if the phone was not in my own hands.

2. Google’s Find My Device. I locked the phone again, with a PIN, and then went back to Google’s My Account webpage > Find Your Phone > select the SGCP > verify Google password. I clicked Locate (at the right side) to verify that Google did know where my phone was. Now I had two separate webpages open, and they differed in functionality. The new Find My Device screen did not offer an option to change the password. That was not what I wanted. I closed that webpage. What I wanted, per GadgetHacks, was the Lock Your Phone option, back on the main Find Your Phone screen. There, I entered a new password > Lock. It said, “Trying to contact your phone.” It stayed that way for a while. Then it said, “Your phone’s locked. Since you already had a screen lock, the password you just set up won’t be used.” The phone itself was still off. I hit its Power button. It did have the default Google message onscreen, “This phone is lost. Please help give it back. Locked by Android Device Manager.” There was an Emergency Call option at the bottom. That opened an Emergency Dialer. It wouldn’t let me call a non-emergency number. In punching the Power button repeatedly (the device kept turning off after just a few seconds), occasionally I would see the login screen, with the keypad waiting for me to enter my PIN. But I couldn’t get back there. Now I really was locked out of the phone. Back on the webpage, I clicked Next Step. That gave me the option to Sign Out on Your Phone. This meant, “Sign out of your Google Account.” It assured me, “You’ll still be able to ring, locate, lock, and erase your phone.” Great, but what about unlock? Was it going to work this way for everybody, or had I confused Google by clicking Locate and opening that other webpage? I tried randomly punching and swiping on the phone. Eventually I hit the Back button. That took me to the numeric keypad. I entered the PIN. It worked. Whew! I was back in. Moral of the story: contra GadgetHacks, this did not seem like a way to unlock a locked phone. But maybe if the phone was on when I tried? I went back to Google’s My Account webpage and took the same steps — but this time, no screwing around: Find Your Phone > select phone > enter Google password > Lock Your Phone > set password > Lock. Same thing: the phone was locked, but I still got that message saying the new password would not be used. Same result. This was definitely not a way to unlock a locked phone. Probably Google had changed this since the time of the Gadget Hacks article.

3. Forgot Pattern. To try this, I went back to Settings > Lock Screen > Screen Lock and chose Pattern. Then I pressed the Power button to turn off and back on. The 3 x 3 dot matrix appeared onscreen. I tried drawing the wrong pattern. It vibrated briefly and said, “Incorrect pattern.” As advised, I did this five times. Nothing changed. I had to do it eight times to get the “Forgot Pattern” option at the bottom of the screen. (Backup PIN was another option there.) This gave me an opportunity to enter my Gmail username and password. That got me back in. Here, again, the original pattern was gone; swiping was sufficient for entry thereafter. As with the Samsung and Google account options (above), my account name and password were essential; a random thief or finder (as distinct from e.g., someone living under the same roof) would be very unlikely to have access to those.

4. Factory Reset. Multiple sources provided information on how to perform a factory reset. Those sources made clear that a factory reset would wipe user data from the phone’s internal memory (as distinct from the SD card, which would not necessarily be affected). Yet AndroidPit (Gordon, 2017) summarized a Cambridge University study (Simon & Anderson, 2015) in which researchers overwrote the data and then performed factory resets on 21 phones using Android 2.3 to 4.3 devices. While the researchers did not test newer versions of Android, their findings suggested that similar problems would occur there as well. Among other things, the researchers were able to recover “master tokens,” providing access to most Google data, from 80% of the phone models tested. Gordon said such data recovery was possible because users did not use strong passwords (above), and because the relevant companies (e.g., Google, phone manufacturers) incorrectly implemented flash storage wiping (which I had previously encountered in the attempt to wipe solid state drives). The researchers (p. 7) noted that a remote wipe on a lost phone would not be a satisfactory alternative to a flawed factory wipe process. The researchers (pp. 6-7) speculated as to the ways in which dishonest phone salespeople, for example, could profit from sale of data found on old trade-in phones.

Aside from destroying the phone, the researchers’ suggestions (p. 7) for achieving more secure erasure involved relatively technical efforts. Gordon mentions one such method: attempting to fill the phone with useless data. But the researchers could not guarantee that that would work. I did not research the question of whether apps existed to aid in any such technical efforts. It seemed a possible workaround would be to solicit dummy accounts (from e.g., Google and banks) that the user could log into before selling or trading in a phone; presumably a login to the dummy account could overwrite the phone’s previously saved data about one’s real accounts at those same places, unless the relevant software perversely saved prior account information. For present purposes, it did appear that, at least on this phone, a factory reset could eliminate the lock screen barrier without necessarily deleting valuable account data. A thief might be taking a risk that the reset would succeed in wiping everything, but I was a beginner in these things; perhaps s/he would have ways of using ADB (above), or some other backup procedure, before attempting the factory reset.

5. ADB. Another GadgetHacks (Thomas, 2015) method of bypassing the lock screen called for using ADB commands on a computer connected to the phone via USB. This method required me to install ADB (above). To enter the necessary command, in Windows Explorer I went to the PC’s ADB program folder (i.e., C:\Program Files (x86)\Android\android-sdk\platform-tools). There, in an empty space, I used Shift-right-click > Open command window here. I wanted to run three commands, one at a time:

adb shell ls /data/system
adb pull /data/system/gesture.key D:\Temp
adb shell rm /data/system/gesture.key

The last of those three was the one recommended by GadgetHacks. It would RM (i.e., remove, i.e., delete) the gesture.key file from the phone. To this newbie, that seemed a bit rash. So I started with an LS command, to list the files in the /data/system folder on the phone. LS was not an ADB command. It was a Linux shell command. Thus, the first command here invoked the Linux shell in order to run LS and see what files were in the folder. When I ran that first command, I got errors. One time, it was “error: no devices/emulators found.” The solution in that case was (sad but true) to make sure the other end of the USB cable was actually plugged into the computer. (Others found it necessary to reboot the computer.) Another time, when I ran that LS command, I got a different error:

error: device unauthorized.
This adb server’s $ADB_VENDOR_KEYS is not set
Try ‘adb kill-server’ if that seems wrong.
Otherwise check for a confirmation dialog on your device.

I got that error regardless of whether I was logged into the phone (i.e., had entered the PIN and moved beyond the lock screen). The fix for this was to turn on the “always allow” option when enabling USB debugging (above). With that turned on, even when the phone was sleeping and locked, the LS command gave me what appeared to be a list of files in the phone’s Android /data/system folder. As noted above, to get the “always allow” option, I might have to unplug the phone; go into Settings > USB Developer Options > uncheck USB Debugging and tap Revoke USB Debugging Authorizations; and then replug the phone and recheck USB Debugging.

That list of files did include gesture.key. So now my second command (above) copied gesture.key to drive D on the PC, as a backup. It was necessary to designate a folder on D: attempting to copy to simply the root of drive D resulted in “adb: error: cannot create file/directory ‘D:\’: No such file or directory.” After fixing that, I got a new error: “Permission denied.” My browsing yielded the conclusion that I would be able to get past that only by rooting the phone. Without a backup copy of gesture.key, I did not attempt the third command shown above, to RM the gesture.key file — but I suspected it, too, would require root permission.

I tried again, using a different ADB suggestion, provided by m.sabra (2012). This was supposed to work at least with a pattern lock. The recommended sequence was as follows:

  • Enable Settings > Developer Options > USB Debugging. To test that, I did not enable the “always allow” option that came up, there, when the USB cable was connected.
  • With the USB cable connected, and with ADB installed and a command window opened as just described, enter these commands:
adb shell
cd /data/data/
sqlite3 settings.db
update system set value=0 where name='lock_pattern_autolock';
update system set value=0 where name='lockscreen.lockedoutpermanently';

m.sabra’s instructions then continued: I was to reboot the phone, enter one more command (i.e., “adb shell rm /data/system/gesture.key”), reboot again, and then the lock should be gone (or, in case of a pattern lock, just enter any pattern). m.sabra said this might not work on some devices. The very first command (“adb shell”) produced errors that I should not have gotten because, as far as I could tell, we were all systems go: cable plugged in, drivers installed, no problems in Device Manager. Oh, but then I saw: USB Debugging was off. I tried again with USB Debugging on. Result: same as above: I got the “error: device unauthorized” and “$ADB_VENDOR_KEYS is not set” messages quoted above. I had to enable “always allow” to get past them.

The conclusion here was that, in the worst case, someone could root my phone and then execute commands to get past the lock screen. They might even be able to unroot the phone, so that I would not be able to see that this had happened. But this appeared to be feasible via ADB only if I enabled the “always allow” option. If I disabled that option (and chose Cancel when the “always allow” pop-up appeared), ADB seemed to be unable to gain access to the phone. For example, I found that the LS command (above) would produce an error: “no devices/emulators found.” A thief or finder would have to get past the phone’s lock screen to change the USB option. So, as far as I could tell, this ADB approach offered a way for others to bypass the lock screen only if I failed to disable the “always allow” option.

6. Crash the Lock Screen. GadgetHacks (Thomas, 2015) said that lock screens could be circumvented, on devices running Android 5, by crashing them. The method for doing this involved entering more characters than the screen could handle. (See also The Telegraph,  2015.) I accepted the statement that this was only feasible on Android 5, and did not try to test it on my Android 4.4 SGCP. But this quirk did lead me to suspect that there were other methods, beyond those listed here. That suspicion was supported by the closing words of the GadgetHacks article, inviting readers to share “other hacks that will bypass Android’s lock screen.”

7. For Rooted Phones. Commenters did respond to the GadgetHacks article by testifying as to other methods that had worked for them. A couple of those comments focused on lock screen bypass methods that would apparently work only on rooted phones. The best example may have been the one calling for use of Team Win Recovery Project (above) to gain access to Advanced > File Manager > /data/system > erase all three .key files.

8. Dr.Fone. Wondershare suggested using its own Dr.Fone app (3.8 stars). The recommended steps started with putting the phone into Download Mode. As noted above, Download Mode was risky. Besides, the app information said that, for non-rooted phones, the recommended approach was to use the desktop version of Dr.Fone. I tried that. It offered multiple functions. I connected the phone and chose Lock Screen Removal. It detected Samsung, but asked for the device name. Unfortunately, its list did not include the SGCP. It warned, “Very important: Presently the supported list of devices is limited. Please select the correct device model to protect your phone from being bricked.” The screens I was seeing were not identical to those in some materials turned up in a search, including materials provided by sources claiming that Dr.Fone would indeed unlock an SGCP. So while I was not willing to try my luck with this thing, and was also not willing to spend a substantial sum ($49.95) for a licensed PC copy of Dr. Fone, it seemed a knowledgeable thief might be able to use Dr.Fone to break through the lock screen.

9. Boot into Safe Mode. GadgetHacks (Thomas, 2015) suggested that this method was useful only for bypassing third-party lock screens, not the default Android lock screen that I had been testing thus far. I tried this approach after installing a third-party lock screen (below).

10. Direct Physical Access to Memory. See encryption (below).

11. Observe Finger Smudges. Participants in a StackExchange discussion said it was sometimes possible to detect a pattern or PIN form of security by observing the smudges left on the phone by the user who had opened the lock screen and had not then done much other swiping or tapping. Aviv et al. (2010) found that, “In the vast majority of settings, partial or complete patterns are easily retrieved . . . . [even from a phone that has been] placed in a pocket.”

12. Shoulder Surfing. It would sometimes be possible to obtain a PIN, password, or — especially — pattern by simply watching the phone’s owner enter it. This would be relatively easy where, for instance, the phone and its user were at a table in a library, while a spy was seated at an office or study carrel in the mezzanine, one level up. Given the proper angle, an individual using a zoom lens (or perhaps just having sharp eyesight) could detect exactly what was entered. A spy seated at another table on the same level might also see the pattern, or might be aided in that task with a laptop’s webcam. TruthNews (Davis, 2017) described a method of detecting the PIN or pattern with the aid of a thermal camera. The odds of success in any such observation would grow with repeat viewings and with multiple opportunities to test one’s observations — at a familiar place, for instance, or among familiar people.

Conclusion. I did not find an easy and simple way to bypass the lock screen on the SGCP. But that may have been due merely to my limits. Among other things, I was not willing to spend $50 on Dr.Fone, to root the phone, or to risk damaging it or its contents. A thief might have no such qualms. In my browsing on the subject, I did encounter the general impression that one should not assume the lock screen would provide a reliable barrier against intruders in physical possession of the phone. InfoSec Institute offered the analogy of the front door lock on a dwelling. Basically, it was there to keep the honest people honest; it was not a guarantee of security.

Drive Encryption

Encryption was essentially a way of using a password to scramble and unscramble data. The problem was that, according to ZDNet (Kingsley-Hughes, 2016), less than 10% of Android devices were encrypted. And I was about to see why.

As discussed below, a phone would typically contain a built-in memory device, similar to an SD card, and would also have a socket in which the user would add an actual SD card. In smartphone land, the latter was usually called an “external” drive (even though it was not external to the phone) because it was not hard-wired into the phone’s circuitry.

It would be easy to remove the SD card and, if unencrypted, read it on another phone or, with an adapter, on a PC. In the words of one participant in a StackExchange discussion, “I don’t need your [screen lock] password to access your data. I can disassemble your device . . . . I can pull your drive and connect to my pc to access.” It was also allegedly possible to remove the internal memory and access it elsewhere. Someone in another discussion said, “In principle, a sufficiently sophisticated attacker, if he has access to your phone, can likely disassemble the phone, pull out the flash chips, and read off the data.” But my search led to 1 2 sources contending that, in fact, specialized equipment would be required to remove the internal memory without ruining it. So it seemed that, for purposes of defeating casual thieves and random finders, the SD card would be the first thing to encrypt.

How-To Geek (Summerson, 2016) explained how to perform encryption, but cautioned that phone encryption could be undone only by doing a factory reset (above), which the user should treat as wiping user data. I would soon verify that the user-added SD card, unlike the phone’s internal memory, could be reformatted in a PC without a factory reset.

There was a question of what kind of data we were protecting. I saw that internal memory was limited, and that it was apparently possible to install some apps on the SD card. If I used the SD card for non-sensitive apps and data, encryption would be unnecessary. For example, I would not care if some stranger got access to a bunch of songs and miscellaneous videos. And those were the kinds of space-consuming materials for which I had made the decision to install a 64GB SD card.

There were reasons to avoid encryption if possible. For one thing, it could take a while. A poster in XDA-Developers expressed concern because the process of encrypting his/her 64GB SD card had stretched into its third day. That particular one may have frozen midstream, bringing the possibility that the SD card was ruined. I was sensitive to that possibility: I had recently found that, for some unknown reason, an SD card used elsewhere had ceased to function. Prices had come down, but I was still not fond of the idea that I might have to lose data and spend money because SD cards were more fragile than one would hope.

Whatever the situation with that particular encryption saga, others likewise reported waits of many hours, sometimes stretching on longer than a day. During those hours, it would be necessary to keep the phone connected to its charger, overcharging itself, lest it die halfway through the encryption, conceivably ruining the SD card. And then, going forward, Elcomsoft (Afonin, 2016) noted that using encryption would dramatically reduce smartphone battery life. There were also some reported encryption incompatibilities — most notoriously involving Samsung itself, insofar as some of its own software and hardware would not work with an encrypted Samsung device (XDA-Developers, 2015).

Encryption also had performance drawbacks. According to Ars Technica (Cunningham, 2016), “[F]or more casual users with older or lower-end devices [such as my SGCP], encryption can noticeably impact performance in ways that can make these devices actively unpleasant to use” because encryption and decryption demand processing power that older devices lack. Cunningham contrasted a 2014 Moto G phone against a 2015 Moto E phone. With encryption, the newer phone ran half as fast with encryption as without it — but the older phone ran only one-quarter as fast. Afonin found a significant performance impact even in newer devices running Android 7. Malkani (2015) disagreed — contending that, in actual user experience on phones a year or two newer than mine, there would be only “a slight stutter” during disk-intensive tasks.

I decided to test that on my SGCP. Onto an unencrypted exFAT-formatted 8GB Transcend SDHC Class 6 Micro SD card, I copied a 1.3GB MP4 video file (1280 x 720, 1.6Mbps). Copying from my PC onto the SD card via USB adapter took 2:21 (minutes:seconds). I inserted the SD card into the phone and went to My Files > Videos > tap on the MP4 > Complete action using the default SGCP Video Player. It played without stuttering (and, may I say, the 16:9 aspect ratio of the 1280 x 720 video was just about right for this screen, with only a little blank space at the top and bottom of the screen, viewing in landscape mode).

Next, with the USB cable connected to the PC for reliable power, I went to Settings > Security > Encrypt External SD Card. It said, “SD card encryption is turned off. Set an unlock password of at least 6 characters, containing at least 1 number. Set screen lock type.” I found those multiple instructions confusing. “Set screen lock type” was in the largest print, so I tapped on that first. It gave me a choice among the various kinds of screen locks available on the SGCP (e.g., None, Swipe, Pattern), but they were all greyed out except Password – High Security. So, being reasonable, I chose that. I entered a password. Now “Set screen lock type” was replaced by “Turn on.” I tapped that. It said this:

Encrypt all files on your SD card?

If you tap Yes, all files on the SD card will be encrypted. If you tap No, only files that have been created on this phone will be encrypted.

I chose Yes. It said,

Exclude multimedia files (e.g., avi, jpg, mp3) from encryption?

If you tap Yes, multimedia files will not be encrypted. If you tap No, multimedia files will be encrypted.

I tapped No. It said,

SD card encryption will be turned on.

Selected options

Full encryption

The above options will be applied.

I tapped Continue. It asked me to reenter the password I had just created. It gave me a long message, repeating some of the foregoing information: all open files on the SD card would be closed; existing and new SD card files would be encrypted; the SD card would not be available during this process. Also, SD card files encrypted on this phone could be used only on this phone, and a factory reset would leave encrypted files on this phone unusable. I tapped Apply. It put me back to the screen last quoted (above). I thought it was making me tap on Continue again, but then I discovered that was grayed out; apparently encryption had already begun. So I was maybe ten seconds slow in hitting the Start button on my stopwatch, to time this process. There was no onscreen progress bar, but when I swiped down from the top of the screen to get notifications, I saw the top one was, “Connected as a media device” and, under that it said, “SD card encryption: 52%.” It was clicking right along: I barely had time to type these words and screw around with something else before it was done. Total time to encrypt the 8GB Class 6 SD card containing that 1.3GB MP4 file: about 4:25.

I hit the Back button. Now the main screen said, “SD card encrypted.” I tapped the Turn Off button, thinking it meant, “Turn off the phone.” It asked for my password. I suspected it meant, “Turn off encryption.” I backed out of that. I went back to the Home screen and powered down the phone. Then I powered it back up. The opening screen displayed the typewriter. Evidently there was not an option of using the phone’s non-encrypted internal memory without entering a password: if the SD card was encrypted, then I would have to enter the encryption password to use the phone, even if the phone itself was not encrypted. I entered the password and repeated the steps to watch the movie. It played without stuttering. Encryption did not seem to affect performance for purposes of viewing a 1.6Mbps MP4 file on a SGCP with hardly any apps installed beyond its original condition.

On the PC, I made another version of the MP4 file, using a video editor (Adobe Premiere Elements). This version consisted of only the first five minutes of that MP4. This version was 1920 x 1080, target (VBR) video bitrate 30Mbps, audio bitrate 320kbps. With those settings, just five minutes of that 113-minute movie required 617MB. This would be a demanding file to play. The PC could play it, but could the SGCP?

While that video file was being rendered, I erased the MP4 from the phone and re-copied it from the PC via USB cable, using Windows Explorer. That gave me a question:

Do you want to convert before it’s copied to your device?

Yes, convert and copy (recommended)

No, just copy.
Your fill will be copied, but might not play on your device.

I said No, just copy. This time, the copy process took 13:27 — almost exactly one-third as fast. I took the SD card out of the phone and copied the file via USB adapter directly to the SD card, as I had done the first time. This time, the copy took only 2:19. So copying to the encrypted SD card, when it was in the phone, was far slower than copying it directly to the card, mounted in an adapter.

But wait. If the SD card was encrypted, why was I even able to see it in Windows Explorer? Because I could: I could see the Android-installed folders on it; I could see the MP4 file on it when the copy was complete. I plugged the SD card back into the phone and powered it back up. I went into My Files. Now there was no SD card entry, and Videos showed no files. It seemed that writing from the PC to the encrypted SD card, when it was mounted in the adapter, had wrecked the encryption and made the card unreadable in the phone.

I started over. I went back to the PC, reformatted the SD card as exFAT, put the reformatted SD card in the phone, and powered up the phone. The password requirement was still there. That was odd: the card itself had just been reformatted; it was no longer encrypted. Evidently the SD card’s encryption status was set in the phone, regardless of the SD card’s actual condition. Thus, I would find that, when I told the phone to turn off SD card encryption, it did not check to see whether the SD card was actually encrypted; it required the password and waited for me to tap “Turn Off” before it would test a reformatted SD card and conclude that encryption was now turned off.

As soon as I entered the password into the phone, I was returned immediately to the “SD card encryption will be turned on” screen (above). I tapped Continue. Almost immediately, it said, “SD card encrypted.” No wait of 4:25 this time. Presumably that was because, this time, the SD card was empty. Back on the PC, with the USB cable connected, I copied the same 1.3GB MP4 file to the phone again (again choosing No, just copy – don’t convert). It took 13:24 – almost exactly the same as before.

I tried connecting the phone via USB cable to a laptop that had not been involved in any Android-related activity. The phone gave a brief notification, “Connected as a media device.” Windows Explorer on the laptop was able to see the contents of the phone, including this newly copied MP4 file. It seemed that, as long as I had entered the password on the phone, the contents of its encrypted SD card would be visible to any connected PC.

I powered down the phone, removed its SD card, plugged the SD card into the adapter, and plugged the adapter into a USB jack on the PC. Yes, again, in Windows Explorer on the PC, I was able to see the MP4 file’s name. But its right-click > Properties > Details came up blank, and an attempt to play it produced an error: “Windows Media Player cannot play the file.” It seemed the encryption was concealing the contents of individual files, but not the names of the files, nor of the folders in which they were located.

To explore that, I put the SD card back in the phone, powered it back up, and copied a few different kinds of files to it: a PDF, a spreadsheet, an MP3, a WAV, a plain text file. This gave me a question, “Do you want to copy x.xlsx to your device? Your device might not be able to play or view this file.” I said Yes, do this for all files. Windows Explorer now said I had all those files on the SD card, and I was able to open or play them normally on the PC, as if the encrypted SD card were just a storage device. Using the phone’s own file viewer, I was surprised and pleased to see that the phone already had software to view all of these file types. I powered down the phone, removed the SD Card, and viewed its contents again on the PC via USB adapter. Yes, I definitely could see the names of all those files on the encrypted SD card, using Windows Explorer. But I could not view the contents of any of them except the plain text file, and its contents were gibberish. So, yes, encryption was concealing the contents, but it appeared an intruder would still have access to the names of files and folders.

I put the encrypted SD card back into the phone and connected it via USB. Using Windows Explorer, I copied that demanding (30Mbps) five-minute excerpt from the movie to the SD card. It copied that 617MB file in 6:14. So we were averaging a transfer speed of right around 100MB per minute, via USB cable to the encrypted SD card. On the phone, I tried playing that dense file from the encrypted SD card. It played without any problem.

That simple encryption test suggested that SD card encryption, per se, might not pose a performance problem. The problem might come, rather, if I had multiple apps running from the SD card, each calling for on-the-fly decryption of multiple program and data files. This was not a state-of-the-art CPU. I believed it probably would struggle, if I put enough demands on it. With or without encryption, my tentative conclusion, pending further experience with the device and its apps, was that I would have to try to use the SGCP in a disciplined manner, using its apps as I needed them, but expecting it to handle just one core task at a time, and reducing its load where possible. For my purposes, it would probably make sense to exclude media files from encryption, perhaps using a file-by-file encryption app to encrypt sensitive media files.

Aside from potential performance issues, there were other reasons to consider postponing encryption until it was definitely needed. According to Green (2016), the kind of encryption typically available on Android phones would be relevant only when the phone was completely shut down, or when someone tried to view the SD card in a different device. Once the phone was powered up and the encryption password was entered, encryption would add no security. On the other hand, stories (above) suggested that smartphone thieves would commonly power them down immediately, so as to prevent Find My Device services from making contact with them. In doing so, the thief would inadvertently lock him/herself out of any encrypted partitions (i.e., phone internal memory and/or SD card). Between prompt use of Find My Device and a strong encryption password, it seemed possible to leave the thief no good alternatives, at least for purposes of accessing data.

Ars Technica (Goodin, 2016) reported that researchers had found holes in encryption due to weaknesses in the design of the Qualcomm chips used in phones such as the SGCP. The problems had been patched, but Goodin reported that an estimated 37% of such phones remained vulnerable because the relevant manufacturers or carriers did not pass along the patches nor allow users to obtain them directly from Google. As noted above, my information so far was that TracFone would likely be among those carriers. In other words, there was a possibility that I would endure reduced performance and battery life, due to encryption, and yet would not ultimately protect my data from an attacker who knew how to exploit a probably unpatched Qualcomm problem on my phone. These, I thought, were probably the sorts of frustrations that prompted people to root their phones, so as to gain access to newer and better-maintained versions of Android.

For encryption to matter, the phone would have to be powered down. One could have one’s hopes as to what a finder or thief would do in that regard, but the safest policy was surely to power the phone down when it was not in use. But if the user enabled a screen lock, encryption, and a SIM card lock (above), and if s/he was diligent about powering the phone down whenever s/he was not using it, then — every time s/he wanted to use the phone — s/he would have to enter three different security items (i.e., password, PIN, or pattern), along with five to ten seconds’ worth of powering the phone up and down. These multiple delays and complications would hopefully not encourage a counterproductive tendency not to power the phone down. Hopefully the user would be able at least to power it down whenever his/her work or study session ended and s/he was packing up to go elsewhere.

Generally, I liked the idea of encrypting partitions on the phone. But the technology seemed to suffer from multiple weaknesses on the SGCP. It seemed a good strategy would be to explore other security options and see whether they might take care of the concerns that encryption would ideally address. Encryption was easier to add than to remove, especially for the phone’s internal storage; hence, it seemed wise to postpone encryption until its need became clear, and then to adopt it on an as-needed basis, possibly encrypting just one of the phone’s storage devices, possibly taking advantage of the option to exclude certain (e.g., media) files from encryption.

File Encryption

If I did not choose Android’s built-in device encryption options, was there perhaps a way of encrypting sensitive files or folders? On the PC, I used VeraCrypt for encrypting partitions. But on PC and cellphone alike, if there was a chance that others would access my files after I had entered the drive encryption password, I would want sensitive files to be encrypted as well. I would also want to encrypt them before emailing them to anyone else.

Another post describes how I used WinRAR, or could have used 7-Zip, to compress and password one or more files on the PC into a single RAR (similar to ZIP) archive. So there was a question of whether Android had features or apps that would do that. A search led to a variety of responses:

  • ArchiDroid (4.2 stars) offered the ability to unpack a variety of archives (e.g., RAR, ZIP, TAR, 7z), to unpack a few (i.e., ZIP and RAR) encrypted archives, and to create simple and encrypted ZIP archives.
  • B1 Archiver (4.4 stars) seemed to deal with more archive types than ArchiDroid. It was hard to tell from the limited descriptions typically offered for various apps, but it appeared B1 might also be superior in other regards, notably involving the ability to browse and extract selected files without having to decompress an entire archive.
  • AndroZip (4.2 stars) offered AES 256-bit encryption in its paid version. It appeared to be produced by the AVG antivirus people.
  • RAR (4.4 stars) (a/k/a WinRAR for Android) was produced by RARLAB, creators of WinRAR, which I had been very impressed and pleased with during the 4.5 years since I had bought a copy for my PC. Unlike the others, it was able to create RAR archives. I suspected I would find its style familiar. Thinking about it, I was reminded of my interest in avoiding unpleasant surprises (e.g., archives that wouldn’t unzip; corrupted files). First choice of AndroidAuthority (Hindy, 2017), SafeTricks (Kumar, 2016), and ILoveFreeSoftware (Tyagi, 2017).
  • Easy Unrar (4.0 stars) seemed to offer a generally capable, free solution.
  • ZArchiver (4.5 stars) allowed creation of a half-dozen types of archives, including 7z and ZIP, as well as viewing, editing, and partially decompressing archives.
  • EasyCodeWay (2016) said that the ES File Explorer file management app (below) was able to zip and encrypt files. Other file managers (below) had similar ability. Mostly this seemed limited to ZIP files, which might be good enough in the field; none seemed to create RAR files; but apparently some could create comparably impressive 7-Zip archives.
  • Other options: see e.g., Kumar (2016) and Obasimvilla (Ebuka, 2017).

The next question had to do with the state of the art. A search led to a Lifewire article (Fisher, 2017) recommending Free RAR Password Recovery (3.8 stars at Softpedia) and Free RAR Password Cracker Expert (3.6 stars) for cracking passwords. These tools claimed to offer various approaches, including brute force and dictionary attacks (above). Hacker Nucleus (Suman, 2017) ofered a video promising to “hack password of any RAR / ZIP file.” The video was poorly done, and its process seemed to depend on black box software that, for all I knew, was malware. I quit halfway through. iTechHacks (2017) recommended NSIS, WinRAR Password Cracker (3.4 stars at Softpedia), and iSumsoft. I suspected the mediocre ratings were due to users’ discovery that strong passwords were not crackable. In a Microsoft discussion, someone said, “WinRAR uses a very secure encryption algorithm (AES-256). . . . If the password is weak, your best bet is to find a tool that can brute force or dictionary attack the password.” The response was much the same for ZIP files encrypted with AES-256, though some ZIP files were instead encrypted with a weaker algorithm and could be cracked. RARLab confirmed that it switched from AES-128 to AES-256 in RAR 5.0. Brief review of a handful of current research articles found in a search yielded the conclusion that, despite extensive research attempts to crack it, the AES encryption algorithm continues to be “fast, secure, simple and flexible” (Narayanan & Durai, 2016, p. 386).

There would still be a question of computing power. As noted in my previous post, my Core i7 PC could take “an hour or more to produce a 23GB RAR file from a folder containing a large number of files.” That sort of task could tie up the SGCP for an entire day. As a matter of practicality, it seemed I would want to limit my expectations, regarding the size and number of encrypted files that I would expect the SGCP to handle. I would often compress files into a single RAR file on the PC, just to keep them together. Probably I would continue to transfer my larger compression tasks from the SGCP back to the PC. Zipping on the SGCP would probably want to be limited to a smallish number of special files.

Passwords and Antivirus

On PC and smartphone alike, there was a question of whether intruders could discover or defeat passwords used for entry into various websites.

In response to that question, The Telegraph (McGoogan, 2017) cited security researchers for the advice to keep using password management software — even though, on a few occasions, such software had been found to have “severe vulnerabilities that allowed attackers to steal all of the passwords in a user’s account without their knowledge.” McGoonan said experts still recommended using password management software because, among other things, users who didn’t have a password manager to keep track of their passwords would often resort to using easily guessed passwords, or would leave notes or hints as to those passwords where others could find them. Of course, the user would want to choose a strong password (above) to control entry into the password manager.

As of June 2017, PCMag said the best password managers were Dashlane and LastPass. ASecureLife (Alt, 2017) agreed, leaning toward the more expensive Dashlane. PC Mag said, “Dashlane still offers a slicker experience, but LastPass goes farther in terms of features.” I was already a LastPass user, so that choice was easy enough for me. My impression, prior to personal experience on the SGCP, was that these tools would be free if I didn’t want to sync my passwords on the phone with those on the PC.

Another security concern: antivirus. Multiple sources debated whether antivirus software was necessary for an Android smartphone. Tom’s Guide (Wagenseil, 2017) disagreed with Gizmodo’s (Nield, 2017; see also ExtremeTech, 2016) suggestion that antivirus software wasn’t necessary, even on Windows PCs, for users who practiced safe computing (e.g., don’t open unfamiliar files, don’t click on unfamiliar links, avoid app sources other than Google Play, don’t approve questionable app permissions, apply updates regularly). Wagenseil called that “dumb” and insisted that “you absolutely do need antivirus software,” even on Android. The problem, he said, was when new malware comes along, before the update writers have time to respond. In response to Nield’s claim that smartphones were particularly safe, Wagenseil cited multiple barriers to prompt updates: “Even fully supported phones may wait months for a new security update from Google,” and phones running Android 5.1 and earlier were no longer officially supported. An AV-Test representative reported that Android malware had become vastly more widespread within the last 2.5 years (Digital Trends, 2015). Presumably that trend had continued in the two years since the date of that article.

One particular source of malware: officially approved sources, notably Google Play. MakeUseOf (Albright, 2016) said that Google Play and other sources “regularly let in quite a few apps that contain Android-specific malware.” AndroidPit (Gordon, 2017) elaborated: “One of the most common security risks is in apps from the Play Store that pose as reputable apps . . . [with] the exact same name and icon as the real one.” As an example, Forbes (Mathews, 2017) described the Marcher malware program, seeking banking information, which arrived on mobile devices via installation of fake versions of Netflix and Bloomberg PRO, among others. DigitalTrends (Hill, 2014) recommended making sure the app actually being installed at Google Play had high ratings from many users; doing a search to verify that the app has “a legitimate website” and has been reviewed independently or discussed in forums; and checking current app reviews in Google Play before installing updates (which may contain malware that was not present in the version first installed). Mathews said that Marcher, at least, was not distributed via Google Play; attempts to upload it there were reportedly detected and prevented. Contrary to Albright and Gordon, Mathews believed that Google Play users were safe.

On the no-antivirus side, AndroidPit (Gordon, 2017) cautioned that antivirus on Android did not necessarily function as effectively as antivirus on PC: such apps “do not automatically remove harmful software for you,” “[n]ot all virus definitions are up-to-date” — and, moreover, antivirus apps “commonly consume a lot of battery, take up disk space, annoy you with notifications and reduce processing speed.” Gordon quoted Android’s security chief: “Do I think the average user on Android needs to install [antivirus apps]? Absolutely not. I don’t think 99 percent plus of users get a benefit from [anti-virus apps].” Judging from an extended Quora debate, this view seemed to be based partly on the general safety of Linux (including Android) as compared to Windows, and partly on the belief that users should (and therefore would) practice safe computing. But as others noted, users do not always know what they are doing; even the careful ones can sometimes make a mistake; and caution can be overdone.

MakeUseOf (Albright, 2016) noted that firewall software (e.g., DroidWall) was available for Android, but might require rooting — which, based on many comments I encountered during my browsing, would tend to increase system vulnerability. Albright also recommended protection from malvertising (via e.g., Adblock Browser, Disconnect), which Wikipedia defined as the use of online advertising to spread malware. A search led to a number of relatively recent articles about malvertising. For example, PC World (Constantin, 2016) said the default SIA browser (see below), on older Android devices such as the SGCP, was vulnerable to a form of ransomware that functioned without any user interaction other than navigating to infected websites. The Chrome browser was protected against that one — but not against the Svpeng Android banking trojan operating on Android devices via Google AdSense ads visited in Chrome (Bleeping Computer, 2016).

Tom’s Guide (Honorof, 2017) discussed another piece of malware, victimizing Android users who have gone into Settings > Security > enable Unknown Sources. (There was a time when use of Unknown Sources was necessary even for something as mainstream as Amazon Appstore, but evidently that was less the case now: for Amazon, at least, there was now an app in Google Play.) Enabling Unknown Sources allowed malware ads to install an alleged device-cleaning program that, if used, would result in the device being overwhelmed with unwanted ads. To remove those ads, a factory reset was necessary — meaning permanent loss of anything that was not backed up (below). Honorof said that good antivirus would catch this malware.

I saw that multiple sources advised against using public WiFi hotspots (e.g., Starbucks). I had often done so with my laptop, and would probably do so with the cellphone. (Note the alternative of using one’s own private WiFi hotspot, below.) In that case, if I didn’t want to risk losing my TracFone minutes or anything else of value on the SGCP, it seemed I probably should protect it with an antivirus app. Presumably the app would notify me when it caught malware in the act, as AVG did on my PC. If the app didn’t seem to be doing much, and especially if it was a burden to battery or performance, I would always have the option of uninstalling it.

For users who did decide to install an antivirus app, several sources (i.e., TechRadar, Tom’s Guide, ExpertReviews) tended to consider Bitdefender the best paid, and Avast the best (ad-supported) free, antivirus for Android. DigitalTrends departed from that somewhat, naming Sophos as best. AndroidPit (Woods, 2017) departed further, naming only Avast among the foregoing, and instead preferring CM Security, Kaspersky, Malwarebytes, AVG, Lookout, McAfee, and Norton. The basis for these recommendations was not clear. As of May 2017, gave five stars for both protection and usability to a number of antivirus tools, including Bitdefender, Sophos, CM Security, Kaspersky, McAfee, and Norton, and 4.5 stars for protection to Avast, but did not mention AVG or Lookout. Malwarebytes (also not listed by AV-Test) was a special case, being designed as a supplement to traditional antivirus software (see Ellis, 2017). AndroidPit (Gordon, 2017) suggested that “in most cases the vital functionality is available in the free version” of antivirus apps.


According to Wikipedia, a Virtual Private Network (VPN) “creates a secure, encrypted connection, which can be thought of as a tunnel, between your computer and a server operated by the VPN service” (quoting a webpage that had since changed its wording). This tunnel would operate as if the user’s computer were directly connected to that remote server. For example, VPNs would enable to connect geographically separate offices in a single cohesive network.

TechHive (Paul, 2017) said, “Once you’re connected to the VPN, . . . it becomes very difficult for anyone else to spy on your web-browsing activity.” Even the VPN provider could face limits in knowing what you were doing, if you used an HTTPS connection. Hackers at a public WiFi location would find it more difficult to steal your login credentials. Paul offered the example of Australians using VPN to get access to the U.S. version of Netflix. But there were limits, he said: “Protection against an active and hostile government? Probably not.” The website being viewed would, itself, know the same amount about you as if you were not using a VPN. Paul warned that paid VPN was worth its price, in terms of transmission speed and/or monthly bandwidth usage.

While the concept of VPN was good, there were some bad implementations. HackRead (Waqas, 2017) reported on a study (Ikram et al., 2016) finding that 82% of the 238 Google Play apps using Android VPN permission “request permission to access sensitive resources including user accounts and text messages,” and 38% contained malware. In the interests of limiting my review to reputable VPN providers, I looked at the PCWorld (Paul, 2017) list of the best VPN services of 2017. Criteria included online privacy, anonymity, a variety of locations from which to direct the user’s traffic, fast and reliable performance, and ease of use. The number of servers was a reliability factor, because it “provides an idea of how much load a VPN can take before slowing to a crawl.” The results:

  • Paul named Mullvad (four stars) as the best overall VPN, primarily because of its privacy protection, but admitted that Mullvad was fast, but not as fast as some, and had a troubled interface. Pricing: $5.80 (€5) per month.
  • Paul liked TunnelBear (four stars) for its simplicity, speed, intelligent security warnings, and features (e.g., automatically activating TunnelBear on any WiFi network not listed as Trusted). TunnelBear pricing was free (500MB data limit per month), $10/month (unlimited data), or $5/month (unlimited data, paid as $60/year).
  • Paul gave NordVPN 3.5 stars. Strengths: great interface, U.S. Netflix access, impressive country selection, dedicated TOR servers, good privacy. Price: $12/month, $69/year, $42/six months.
  • Paul himself used Private Internet Access (PIA). He valued the fact that PIA had gone to court, and won, against an FBI demand for usage logs; PIA kept none. PIA said it chose to be based in the U.S. because it was one of few countries that did not require data retention. Mostly, Paul said, he was currently using PIA just because he made a practice of switching VPN providers every year or two. The interface seemed minimalistic and the service “no-frills.” Users were not allowed to choose specific servers within a given country. Speed was good but not outstanding. Price: $7/month, $40/year, $36 for six months (sic).
  • SaferVPN. I quickly gained the impression that this service was more expensive and less impressive than several others, and thus did not review it in detail.

From those reviews, I favored TunnelBear. A search led to a number of other rankings. I viewed some of these (i.e., Tom’s Guide, Lifewire, TechRadar, PCMag). Tom’s Guide favored (in descending order) PIA, CyberGhost, IPVanish, and Avast, with more criticism for (still descending) Opera, Avira, ExpressVPN, NordVPN, and PureVPN. Lifewire ranked IPVanish first, followed by PureVPN, NordVPN, Speedify, VyprVPN, Avast, TunnelBear, and others. TechRadar preferred IPVanish, VyprVPN, ExpressVPN, NordVPN, TunnelBear, Windscribe, and others. The PCMag Editors’ Choices were NordVPN, PureVPN, PIA, and KeepSolid, with TunnelBear lagging slightly for its lack of geographically diverse servers and P2P or BitTorrent support. The PCMag display of features was evidently not an accurate representation of its actual decision criteria.

These results suggested rather substantial differences in priorities, among reviewers. I revisited those four sources, to differentiate among their criteria. Tom’s Guide was concerned with speed, number of servers, and price. Lifewire did not specify criteria, but said that it relied in part on reader feedback. TechRadar seemed especially concerned with privacy. PCMag seemed to prioritize speed.

The speed criterion was important. PCMag said that VPN involved more steps than normal browsing, so it was rare to achieve the same kind of speed — although a few services (notably PureVPN, IPVanish, and ExpressVPN) would produce faster-than-regular-Internet speeds, probably due to the quality of their infrastructure. PCMag noted that NordVPN and PIA were particularly strong in their Android apps, and that PIA also blocked ads.

After further reading, I decided to abort this exploration with a pragmatic decision. I had used VPN years earlier, but did not recall much about it. Practically speaking, I was a newbie. Also, I had gotten by without it; the matter arose now just because of concern about using public WiFi on the SGCP. It made sense to start with the free version of the easy-to-use TunnelBear.

Even so, there was one other alternative to consider. Ars Technica (Salter, 2017) said, “Unfortunately, an awful lot of the critical infrastructure of your access to the Web is unencrypted and really cannot be secured.” Salter offered guidance in how to “roll your own, personally hosted VPN service to get your data away from prying eyes at your ISP” and elsewhere. This approach, he said, had the potential to be extremely secure, free, and platform-independent; but the user would still have to trust his/her hosting provider (and, perhaps, the NSA), and would have additional ongoing maintenance.

To add TunnelBear or any other VPN service, Samsung said I should go into Settings > More Networks > VPN. At that point, I got a notice: “Set screen unlock PIN or password before you can use credential storage.” That led to the Select Screen Lock screen. Then I got a bubble, pointing at the plus symbol in the upper right corner of the screen, telling me, “Tap to add VPNs.” That led to questions about the VPN. I was not yet ready to add TunnelBear, and I also thought perhaps its app would take care of some of this. So I postponed that for the moment.

Hidden Partitions, Folders, Files, and Data

On the PC, I had used VeraCrypt to encrypt entire drive partitions and also to encrypt a container burned onto an unencrypted BD-R disc. I also knew that VeraCrypt was able to create a hidden volume. The concept there was that you would create a normal VeraCrypt volume, create the hidden volume (with a different password) inside it — and then, in VeraCrypt’s words, if relevant instructions were followed carefully,

Even when the outer volume is mounted, it should be impossible to prove whether there is a hidden volume within it or not, because free space on any VeraCrypt volume is always filled with random data when the volume is created and no part of the (dismounted) hidden volume can be distinguished from random data.

One scenario for the hidden volume was that a user would create a regular TrueCrypt or VeraCrypt volume, but would be forced (by e.g., a court or an extorter) to reveal the password to that volume. So then the intruder would be able to see the contents of the encrypted volume. And the clever user, fearing that this would happen, would prepare for it by putting a convincing quantity and type of materials in that volume, including some relatively sensitive data. The intruder would see those sensitive materials and think that was it; s/he had penetrated to the core of the user’s secrets. But the user would have hidden the really juicy stuff in a hidden volume that would be impossible to detect. Unfortunately, among various doubts and criticisms of the concept, Kedziora et al. (2017) reported multiple technical means of determining that a hidden volume did exist.

Regardless of the hidden volume option, VeraCrypt remained the safest bet, for purposes of secure encryption of partitions. Alternatives lacked VeraCrypt’s audit-level (albeit not perfect) security. There was no Android version of VeraCrypt, and no plan to develop one, but VeraCrypt was implemented in EDS (4.1 stars, $5.49; see website), with support for hidden containers. I suspected it might also be possible for a Linux user to find a way to use VeraCrypt on Android: VeraCrypt was available in Linux, and it was apparently possible for Linux users to edit and create files and folders in Android, possibly even on a non-rooted device.

Within a partition, hidden or not, there was the option (above) of encrypting a sensitive file or folder. In that case, if an intruder did find it, his/her challenge would be narrowed, though still not necessarily easy: s/he would know where the desired information was, and would now just have to get past its password. To make it harder for him/her to reach that point, there were the simple options of giving the file or folder a false name and/or extension, or (in Android) of putting a period in front of its name (e.g., .secret.file), and the more sophisticated option of hiding it. Various file managers, some of which are named below (e.g., Solid Explorer, Amaze, ASUS File Manager, File Commander, but apparently not Total Commander) offered a file-hiding capability.

There was also steganography — that is, hiding data within another file (e.g., JPG or MP3). There were tools to detect this sort of thing. I did not investigate the degree of sophistication, the amount of time, or the complexities that might affect how well this would work.

Finally, there were apps to hide files. Gallery Lock Pro (4.6 stars; $4.25) offered that capability, along with a claim that “Times Magazine” named it “App of the Year.” Having never heard of such a publication, I wrote to ask for the link or else deletion of that claim. Image Vault (few users) offered similar capability. There appeared to be others.

Other Security Notes

  • Private Mode. The SGCP did not offer the Settings > Private Mode option described by Samsung.
  • Secure Folder. Samsung also referred to a Settings > Lock Screen > Secure Folder option that did not exist on my TracFone SGCP.
  • Private Browsing. Samsung explained that private browsing was available by going into Chrome > menu (upper right corner) > New Incognito Tab. That opened a webpage explaining that, in this mode, my tabs would not remain in Chrome’s history, cookie store, or search history after closing out — but my ISP, employer, and the website itself would still be able to see my browsing.
  • Tor. Wikipedia said that TOR was short for The Onion Router, the concept being that this software project used layers (as in an onion) to make it difficult or impossible for others to detect a user’s activity and location. The Tor Project offered the Tor Browser for this purpose. Orbot (4.2 stars) was evidently designed to anonymize the user’s activity on Android (and presumably other) devices.
  • Updates. SecurityInABox (2016) advised regular checks for two sets of updates: (1) Settings > About Phone > Software Update and (2) Play Store > menu > My Apps & Games > Check for Updates.

App Selection

The previous sections address numerous issues involving phone functioning and security. By now, however, it seemed I was moving closer to the point of actually being able to use the phone. Using the phone would tend to involve apps that could perform various productive or rewarding functions. This section turns to the question of which apps would be most recommended for such purposes.

Finding Good Apps

As mentioned earlier, when I first turned on the phone and responded to the questions and instructions that appeared onscreen, I found myself going through setup and connection processes for Google and Samsung tools and websites. I did not log those steps in detail. Later, I installed the TracFone “My Account” app (above). Now, a search for the best apps for the SCGP led to other interesting apps. There seemed to be quite a few of them. The free section at App4Smart listed 665 games for the Samsung Galaxy Core (albeit with grossly inflated ratings: all but 13 were rated at least 9.0). App4Smart also offered grab-bags of uncategorized free apps, as did, Brothersoft, Appraw, and others.

In my work with the SGCP so far, I had learned that Google Play would be the mother lode of apps. That source also offered movies, TV, music, books, and other diversions. Its Apps section offered lists of the top (presumably most popular and/or most highly rated) apps and games in several categories: free, paid, and grossing. (The meaning of “top grossing” was unclear, as these were free apps or, in most cases, games; possibly it referred to income from sales of points or credits to users.) The Apps section also offered apps by category. There were 25 categories of non-game apps, 17 categories of games, and nine “family” categories (e.g., “creativity,” presumably for children). The 25 non-game categories were Android Wear, Art & Design, Auto & Vehicles, Beauty, Books & Reference, Business, Comics, Communication, Dating, Education, Entertainment, Events, Finance, Food & Drink, Health & Fitness, House & Home, Libraries & Demo, Lifestyle, Maps & Navigation, Medical, Music & Audio, News & Magazines, Parenting, Personalization, and Photography.

Hours devoted to video games rather than study, back during my grad school days in the 1980s, had taught me to avoid them diligently, lest I be sucked in. So I was not planning to do much gaming. I decided to look into the Top Free Apps at Google Play. I was able to scroll down to view the top 300 on this list before hitting a Show More button. I decided the top 300 would surely contain most of the must-have apps. Unfortunately, there was not an option to subsort these (by e.g., category), and I saw that games were mixed in. Moreover, the grid layout did not allow enough space to view the longer titles. Here, it appeared that “Top” was probably defined by number of downloads, as I saw that some of the most highly ranked apps actually had lower ratings (e.g., four stars instead of five) than others lower in the list.

I decided to try another search. This time, I avoided sites that looked like they would contain that sort of random collection of apps. I did find a number of sites listing apps that were said to be the best for specific purposes: for managing files in the cloud; for adult entertainment; best camera and photography and photo editing apps; best ringtone apps; best back-to-school apps; best music player apps; best keyboard apps; best eBook reader apps. I also found 1 2 3 4 5 6 7 sites listing the five or ten or twenty all-around best apps, in the writer’s opinion. But these recommendations seemed to be all over the place.

It occurred to me that, to get guidance from more authoritative sites, I would have to use a search that would not specify the phone’s model or manufacturer. Trying that, I got lists from sources I recognized, including PCMag, CNBC, TomsGuide, DigitalTrends, PCWorld, Business Insider, Tech Radar, Time, AndroidPit, Mashable, and Lifehacker, among others. Some such sources tried to list mainstream apps, while others named more idiosyncratic choices.

From descriptions offered by those sources, I began to develop an organized list of the most appealing apps. I refined this list by looking at the various app writeups in Google Play, including Google Play > Apps > Top Charts > Top Free > See More. Sometimes I also looked at the display of “Similar” apps on the right side of each Google Play page. For example, the page for Microsoft Office Mobile (4.0 stars) showed Polaris Office (4.3 stars) as a Similar app.

It was not always clear that star ratings were reliable. On the PC, I had seen that sometimes people would recommend programs (e.g., assorted “cleanup” utilities) that were not necessarily helpful and could even cause problems. There did seem to be some rating inflation here as well. For example, indy100 (Dore, 2015) rated Ghost Radar as one of the worst apps of all time, and yet now I saw that Ghost Radar came in several versions, including Ghost Radar Classic (3.9 stars). As another example, Worst App of the World averaged 2.7 stars — although, in fairness, some rated it highly because that was exactly what they were looking for, and in their opinion it delivered what its name promised. According to 1 2 sources, there had been some recent controversy involving CNN, where floods of people gave its app a one-star rating for political reasons (or, sometimes, incoherently expressed reasons) unrelated to the app’s functionality. Rating inflation was also assisted by Google’s reported decision to scrap apps with one-star ratings: that is, Google Play would not contain a representative selection of all known apps, good and bad.

App List Disclaimer

It was not presently feasible for me to gain firsthand, detailed knowledge of the many highly rated apps available for a broad range of purposes; I could only try to look into some of the apps that others recommended. I came up with a list (below), drawing on sources like those listed above. I could not be sure whether any apps in my list might have harmful effects. The list would continue to be a work in progress. I expected to revise it from time to time, but would not necessarily keep up with real-world developments. There may have been better apps for at least some of these purposes. I was interested in reducing the phone’s workload, and also in reducing the amount of time I would have to spend configuring and learning to use apps, so this list tended to name only a few apps for each purpose. If in doubt, however, I included additional apps that seemed to have somewhat different functionality that I might want. Items labeled “Maybe” were possible alternatives or additions to the items earlier in each list. Except as otherwise described in this post, I did not install Maybe items. I also did not install all of the non-Maybe items, nor did I get to know all that I did install. Not all apps discussed elsewhere in this post appear in this list. Apps with asterisks came preinstalled on the SGCP. Most apps (in at least an apparently working basic version) were free (but perhaps ad-supported). Prices for paid apps were often unclear on the Google Play pages; I noted specific prices as I became aware of them. Some paid apps may have offered a free trial period. I did not always research prices if they were not plainly displayed. Links and star ratings refer to Google Play. I did not test all links, to verify that they led to legitimate software rather than malware knockoffs, but as far as I saw, they seemed legitimate. It seemed highly advisable to read the notes after the list (below), and the next sections of this post, before installing any apps.

Recommended Apps

Backup & Storage

Home and App Screen Organization

Documents & Productivity

User Interface


Browsing, Shopping, Travel

Calls, Text, Other Communication

Photos & Images

Music & Radio

News & Weather

Other Entertainment

Help & Assistance

System Administration

That list did not include some of the categories identified by some of those sources. Specifically, I ignored food, health and fitness categories, as well as (for security reasons) those involving payment or money management (e.g., Mint, PayPal).

App Installation & Uninstallation

Some earlier sections of this post include a few, mostly brief, app installation discussions. This section provides broader and deeper coverage of issues encountered while installing and configuring a number of apps, among those listed in the preceding section. I did not attempt to write notes for every app; these are just some points that seemed worth recording.

Adding apps to the phone was not like adding programs to a computer. Google said, “When you add apps or digital content it’s connected to your Google Account, not just the device you add it on.” Trusted Reviews (Mundy, 2014) elaborated:

[I]f you find something you like whilst navigating [the Google Play store on your PC], you don’t then have to find it on your phone or hook your phone up to your computer in order to install it.

When you first set up the Google Play Store on your Android phone and logged into your account on your computer, the two were linked. So, if you click Install on an app on the desktop, it will automatically start downloading on your active phone phone.

I hoped to take this one step at a time. It would not necessarily turn out that way; but now, at the start of the process of installing all those dozens of apps, I began by powering down the phone (i.e., not just put it to sleep), so that it would not do anything until I could watch. Then I looked at the Google Play webpage for the first app that I wanted to install: Helium, the backup app. I intended to back up the phone to the PC before proceeding to install the other apps. I would find that a struggle with Helium would introduce me to a number of issues related to app installation and uninstallation.

Helium: Failure & Uninstallation

On the Google Play page for Helium App Sync & Backup (4.1 stars), I clicked the Install button. As just indicated, this prepared the app to be installed on the SGCP, as soon as I turned it back on. Thus, I connected the phone to the PC, to charge it, because I had noticed the battery was low, and I figured installation of many apps might take a while. I would want to be careful about my procedure for installing paid apps, because Google said I had only 48 hours to request a refund on grounds that the app wasn’t what I expected, didn’t work, or I didn’t want it anymore. (Later, when I bought Folder Organizer (below), I saw they said I had only two hours to request a refund. I was not sure of the reason for the apparent discrepancy.)

When I clicked the Install button on the Google Play webpage for Helium, the page checked compatibility with my type of device, let me choose which device it was being added to (I could change the name of my device at Google Play page > gear icon (upper right corner) > Settings), and told me what the app would have access to. Helium was seeking access to many things, so there was a scrollbar, allowing me to scroll down and view the full list. The number and extent of permissions requested were dismaying. A search confirmed that some users were concerned. But the general mindset seemed to be that this was just the way things were, that no real harm had come of it, and that developers needed this to make the app work and/or to pay their bills. For the ordinary user, lacking any meaningful legal representation in such matters, the guiding philosophy seemed to be, play along or go home. I wished to use the cellphone and these apps, so I went along with the herd.

Confirming installation of Helium, on the Google Play page, was harder than it looked. It seemed that I just had to click the Install button a second time. But apparently I had been timed out, in the process of writing these words; and then, after logging in again, I got another error: “An unexpected error has occurred. Please try again later.” Merely refreshing the page didn’t work. Possibly it was a problem with the Firefox browser that I was using for this, on my desktop; it had been having problems. I killed Firefox and started over. That was it: this time, after the repeat click on Install, I got a confirmation: the app “will be installed on your device soon.” I clicked OK. Now the button on the app’s Firefox page said, “Installed.” The My Apps list (upper left corner of Google Play page) showed it as installed.

It occurred to me that Helium might somehow have been installed via the USB cable, through which I was charging the phone, even though the phone was turned off. I unplugged the USB cable and powered up the phone, to see what was going on. No, Helium hadn’t been installed yet. There was no icon for it in Apps. Then I noticed a download arrow flashing in the status bar. I swiped down from the top to open the notification list. It said Helium was downloading. Within a matter of seconds, the notification changed: now it said Helium was installing. Then the notification changed again, to tell me it was installed.

I took a moment, here, to deal with notifications, as detailed below. When I came back to the Helium installer, it was saying I needed to connect to the Helium desktop application. In Firefox on the PC, I browsed to the location they indicated and downloaded the Windows installer. I installed and ran it. It said, “To enable Helium on your Android, please connect it to USB.” I tapped the OK button that had been waiting for me, on the phone. It said, “Please enable USB debugging.” I went into Settings > USB Developer Options > USB Debugging > check to enable > OK > Allow USB debugging (but not “always allow”).

Now the installer had another request: “Your Android USB is in MTP mode. You may need to switch it to PTP.” A search led to endless fascinating information on this subject, but it seemed perhaps I just needed to tap the “Enable PTP” button there on the phone’s screen. Now it said, “In your Android Settings, you will find a setting to enable Camera (PTP) mode. Enable the setting, then press back to return to Helium.” But that was incorrect: I did not have anything like Settings > Camera Mode. The User’s Manual suggested Notifications Panel (i.e., slide finger down from top of screen) > Connected as a media device > check Camera (PTP). That turned off the MTP alternative. Apparently this Notifications option would be available only when the USB cable was connected. The PC said, “Installing device driver software,” and then, a moment later, told me the driver was successfully installed.

Once again, I had the question about allowing USB debugging; again I said yes, but not “always allow.” Now it was saying, again, that I needed to enable PTP. I verified that it was already enabled. I tried just tapping OK. Helium said, again, that it was waiting on the PC. The PC program was running, but apparently now was the time for me to respond to its statement, “Is your Android connected but not detected? You may need to install drivers.” I clicked on that link. A webpage opened in my browser, offering Universal ADB Drivers. The exact name of the download was UniversalAdbDriverSetup.msi. I had already installed that (above), and that was confirmed now, because when I ran that download, I got a dialog asking if I wanted to repair or remove it — which was typical for an already installed Windows program. I chose Repair. No joy: the phone still said it was waiting on the desktop, and the desktop was still showing me that message about installing drivers.

I unplugged the USB cable, rebooted the PC, and powered the phone down and back up. I went to Apps > Helium. It said I needed to connect to the desktop. I plugged the USB cable back in. When the question came up, I said enable debugging again. The phone said it was waiting on Helium Desktop. I started Helium Desktop. It gave me the same message as before. I tried a search. It seemed very few people had had this problem. No solutions emerged.

I uninstalled Helium from the PC. On the SGCP, I went to Settings > Application Manager > Helium > Uninstall. (Alternately, I could have used Google Play > menu (or swipe from left edge) > My Apps and Games > select Helium > Uninstall.) Ironically, that worked quite well — on the phone. Uninstalling from the phone was another matter (below).

Notification History

I wanted to see the full list of those several notifications, so I tapped on that installation notification, but that just erased the notification and put me at the Helium configuration screen. A search led to several suggestions on how to gain access to prior notifications. Guiding Tech (Ashish, 2017) said I could press on a blank space on the Home screen > Widgets > add the Settings widget. But my SGCP didn’t have a Settings widget. Alternately, Ashish said, I could use an app. He recommended Past Notifications (4.1 stars, 401 ratings, 50-100,000 installs). I looked at several alternative apps and decided that was the best of the lot, so I installed it. When I went into Apps > Past Notifications, I received a notice, telling me to go to Settings > Accessibility > Services section > PastNotifications > On.

Later, I encountered Timeline-Notifications history (4.4 stars, but only 73 ratings). I decided to take a chance on it, and gain experience with these two notification tools, so as to learn whether I needed both, or whether one was superior.

I suspected I would want to squelch unimportant notifications about app updates. For that, Trusted Reviews (Mundy, 2014) recommended going (on the phone) to Play Store > menu (upper left corner) > Settings > Notifications > turn off Auto-Updates.

Samsung Smart Switch

The installation of Samsung Smart Switch Mobile (4.3 stars) was straightforward. When it was done, it said, “Select what this phone will do.” The choices were Send or Receive. That was unfamiliar language, for a backup tool. In the upper right corner, I tapped on the menu. That gave me a Settings option. It allowed me to require a security code or to password-protect files being transferred to another phone. I backed out of that and tried the menu’s External Storage Transfer option. That was going to back up the phone to the SD card. No reference to a computer.

Trying another angle, Samsung gave me a link to download the Windows version of Smart Switch. I installed and ran that. It gave me an error:

Unsupported USB connection.

The current connection mode is not supported by Smart Switch.
Change the connection mode to transfer media files (MTP) and try connecting again.

I went back to Notifications (i.e., slide finger down from top of screen) > Connected as a camera > check Media Device (MTP). That turned off Camera (PTP). Smart Switch detected that change immediately, but then had another error:

Unsupported device

The connected device is not supported by Smart Switch.
Check which devices are supported and try again.

I clicked the Check Supported Devices box. That opened a webpage leading to another webpage that said Smart Switch was only for Galaxy S II and newer devices. At this point, as mentioned above, I opted just to use Windows Explorer, on the PC, to identify SGCP folders (on both Phone and Card partitions) that I would save as zipped (actually, RAR) files, relying on Google’s automatic sync (above) to capture everything else.

Browsing the Web

For software installed on this SGCP phone, I did not see an “About” menu pick (if, indeed, I saw any menu at all). I became aware of that absence when I attempted to learn about the stock (i.e., default) Internet browser that came pre-installed on the phone. That browser was represented, in Apps, with an Earth icon labeled as simply “Internet.” I could get some limited information about it via Home > Apps > Settings > Application Manager > scroll to the right (i.e., swipe leftwards) to the ALL column > scroll down to Internet > tap. This told me the version number of the default web browser, but not its actual name.

Browsing on my PC revealed that, starting in 2012, according to Samsung (2016),  the stock Internet browser on Android devices was Samsung Internet for Android (SIA). Wikipedia says the KitKat (4.4) version of Android was released in autumn 2013. The SGCP itself was first released in November 2014. Thus, it appeared that my phone used SIA as its built-in browser. (Note security concerns regarding SIA, above.)

The default SIA browser (i.e., the Internet icon) did not consistently provide a nav bar (short for “navigation bar,” reminiscent of the address bar on a PC, where the user could enter a URL address, click a Back button, and otherwise modify his/her browsing). Instead, it operated in full-screen mode. “Full-screen” did not mean an entirely full screen: the status bar remained visible. Concealing even the status bar mean switching from full-screen to immersive mode. To enable immersive mode, it was necessary to change the SIA settings. Unfortunately, SIA did not always display its menu, so as to facilitate that change. To get a brief glimpse of the menu icon (at the upper right corner) when SIA started, it was apparently necessary to start a fresh session (i.e., to go into the Recent button at the bottom left corner and swipe away the existing session). SIA > menu > Settings > Labs > Full screen enabled immersion. Once that was done, swiping down from the top of the screen brought up the nav bar; alternately, SIA > menu > Desktop View enabled the nav bar within immersive mode.

It appeared likely I would use a third-party browser. Google Chrome was the obvious first choice, since it came pre-installed. A Verizon video showed me that I could open new tabs within Chrome by selecting menu (upper right corner) > New tab. In the new tab, I could type the URL of the site to be visited (with the aid of the keyboard’s educated guesses), or could type something for Google to search for. Now I would have a number inside a box (e.g., 3) near the upper right corner, indicating the number of tabs open. Pressing on that number would display the tabs, one under another, so that I could choose among them. Swiping left or right (or tapping the X at the upper right corner) would close a tab; but swiping left or right on the address bar would merely switch to another tab.

Uninstalling Apps via Google Play

In Settings > Accessibility > Services section, I noticed an entry for MobileGo desktop notification service. The entry indicated that this service was turned off.

PC World (Cassavoy, 2011) explained that MobileGo was a Wondershare app. It did not show up in the Play Store list of my installed apps, however (on either the PC website or the SGCP), and I did not recall installing it. Possibly it came aboard when I tinkered with Wondershare’s Dr.Fone, or possibly TracFone preinstalled it; I had seen indications that carriers did bundle some potentially unwanted software with some phones.

The Play Store described MobileGo as a cleaning and optimization tool, which I definitely did not want, having encountered multiple remarks about the harm such tools could cause (and having experienced some of that with similar programs on the PC). Moreover, the PC World article raised the thought that this could just be a trial version of a paid app. I decided to uninstall it.

To uninstall MobileGo, a search led to Google advice that I go into Settings > Application Manager > scroll right to the ALL column > scroll down to the app > tap > Uninstall. That seemed to work: MobileGo was no longer listed.

Uninstalling Helium was another matter. As noted above, I uninstalled it on the phone. But for some reason, this uninstallation was not reflected on the Google Play webpage > My Apps. There, Helium was still listed. That was true in both Firefox and Chrome on the PC; it continued to be true after I rebooted the PC. It did not seem to be a mere delay in the Play Store’s database updating: the problem persisted 18 hours later.

The Play Store website did seem to recognize that Helium was uninstalled. When I went into Google Play > My Apps > Helium > click Installed button, it gave me a choice: Cancel or Install. Likewise, Helium was not listed in the Settings > Application Manager > ALL column. So why did the Store insist on showing it as installed? To resolve that, I would pursue what may have been a wild goose chase into Android emulators, as described in the following subsection.

Using an Android Emulator to Reset the Play Store

As just described, I was seeking to remove Helium from the list of installed apps appearing in the Play Store on my PC, having uninstalled it from the phone.

To assist in that objective, in a Google Play Help Forum discussion, Aryan advised that I go to SGCP > Play Store > menu > My Apps & Games > scroll rightwards to the ALL column. Unfortunately, I did not have an ALL column. I had only UPDATES, INSTALLED, and LIBRARY, and Helium appeared in none of those. As an alternative, Aryan suggested using “an Android OS emulator such as AndyOS on your PC.” A search led to 1 2 3 4 5 6 lists recurrently mentioning MEmu, Remix, Bluestacks, and Nox, as the best Android OS emulators. The concept appeared to be that, as far as Google Play could tell, I would be running another Android device, and thus should have access to my Google account’s list of installed Android apps.

After a brief review, I chose Nox: it was free, not ad-supported, reportedly ran well (in contrast to those that crashed or would not run on various machines), and emulated KitKat. I downloaded and installed Nox version (6/16/2017, 281MB). Aryan’s advice, here, was to start by accessing the Google Play Android app in the emulator. Nox featured a Google icon right on the desktop, and inside it I clicked the Play Store icon. I took the option to access an existing Google account, and entered my Gmail account name and password. I declined the opportunity to use the Google Play app to perform backup. The app vanished to the upper right corner of the Nox screen, with a funny icon hanging down. I clicked on that. Now I seemed to be in the main Play Store. I couldn’t get anything to work, so I just clicked on one of the games listed there. In response, Nox took me through some signup stuff (e.g., agreeing to abide by the Google Play terms of service). I decided not to install that game. Now I did have a link, at the upper left corner, to the Google Play Store. I clicked its menu > My Apps & Games. It still didn’t display an ALL column — apparently I should have chosen a different emulator, for a newer version of Android — but, unlike my SGCP, it did display most if not all of my apps in its LIBRARY column, correctly noting that they were not installed on this emulator.

Generally, my brief experience with Nox led me to see why those emulator reviewers were so big on choosing an emulator that actually worked. I tried again, this time looking for a highly ranked one that would run the newest possible version of Android. The best candidate appeared to be Remix, emulating Android 6.0 Marshmallow. I downloaded and unzipped the 64-bit version (1.0GB). (Note: they said Remix required an Intel rather than AMD CPU.) I ran its EXE file, designated its ISO when asked, and indicated that I wanted to install it on a USB drive rather than hard disk. I wasn’t sure whether it was going to wipe out the drive’s existing contents, but soon I would have that answer: it said, “All the data on your USB flash drive will be erased.” I went ahead with it. Next, it wanted me to reboot. But when I did that, I got an error:

Secure Boot Violation

The system found unauthorized changes on the firmware, operating system or UEFI drivers. Press [OK] to run the next boot device, or enter directly to BIOS Setup if there are no other boot devices installed. Go to BIOS Setup > Advanced > Boot and change the current boot device into other secured boot devices.

(I would find that that message did not appear when the USB drive was not inserted.) I hit OK. That took me to the next screen, where it looked like Remix was ready to go. The options included Resident, Guest, and Verbose modes. The last would save log files. The first would save data and apps; Guest wouldn’t. I chose Resident, the default, assuming that the data would be saved on the USB drive. It gave me some text messages, including one that looked like it was seeking my response. I just waited. Eventually it took me to the RemixOS splash screen. It seemed like it was hung, but I let it sit there, too, for a while. Eventually I decided it really was frozen, rebooted, and tried Guest Mode. That worked. It asked me several questions (regarding e.g., my preferred language) and then allowed me to activate Google Play. I accepted. That put me at the main screen. I double-clicked the Play Activator icon. That finished in a moment. I tried the Play Store icon. It gave me the option to back up data; I let that stay in default = Yes. That put me into the Play Store. I clicked the menu icon (upper left corner) > My Apps & Games > LIBRARY column. It showed the apps installed on the SGCP. Helium was not among them.

This suggested that the problem was not with the Play Store, but was rather in the cache or other information saved by the Chrome and Firefox browsers on the Windows 7 PC. I tested that by logging into my Play Store account on another PC. Correct: no Helium in my account as displayed there either. I removed the USB drive and rebooted the main machine. Now Helium was gone from my Play Store account there too.

These developments left me with several possible explanations. One was that the Play Store was just experiencing a lag, and snapped out of it without any effect from anything I tried. Another was that the computer needed to completely shut down — because that did happen, somewhere in this process. A third possibility, which I considered most likely, was that going into my Google account on the main machine, in Remix and possibly even in Nox, was indeed sufficient to reset the account on that machine as a whole. Next time, I realized, before doing all this rebooting, I should just try accessing the Play Store in another browser and/or another computer.

As a final bit of cleanup, I went into Google Play > gear icon (upper right corner). There, I saw that they had given me three devices, two of which were unnamed. They didn’t appear to have been created by the Android emulators: their registration dates were from a week earlier. In any event, I wanted to remove them. It was irritating that there was no way of doing so at that point. Following advice from a specialist in a Google Play Help Forum discussion, on the PC I went to Google > My Account > Sign-in & Security > Device Activity & Notifications > Review Devices > click on a device > Remove. It would not remove various “devices” that actually consisted of logins via different web browsers on a PC, and it also kept devices that it had seemed to remove. I wound up with six “devices” when I actually had one.

(Later, I realized that it might have been a lot easier to add an Android ISO (such as the Android-x86 4.4-r5 ISO) to something like a YUMI multiboot drive or a SARDU multiboot DVD, both of which I had used extensively in recent years.)

Uninstalling Built-In Apps: MDM

I saw that my phone had Mobile Device Management (MDM) installed. Like MobileGo, this, too, was of uncertain provenance. A search suggested MDM would be of interest to businesses. It didn’t appear in my PC’s list of Play Store apps. I tapped on its Apps icon on the SGCP. At that point, it said, “Welcome. Please insert a content card. The application is now active.” It did now appear, at least, in Settings > Application Manager > ALL column. There, I tapped on it. The only options I had were Force Stop (below) and Turn Off.

A search led to a ManageEngine page that seemed to recommend Settings > Security > Device Administrators > select Android Device Manager > Deactivate, then Settings > Application Manager > ALL column > select MDM > uninstall. I went through those steps, but at the last step there was still no uninstall option. Then I noticed that the icon for MDM had three concentric ovals, like the TracFone logo. It seemed likely that the app was built-in because TracFone needed it. I decided to leave it alone. I went back and reactivated Android Device Manager. (If needed, note the existence of more extreme methods of uninstalling apps (above).)

Uninstalling Apps via File Manager

Joy of Android (Yasir, 2014) described a half-dozen methods of uninstalling apps. I had already covered several of them: use the Play Store website via the PC; use the phone’s Play Store menu; use the phone’s Settings > Application Manager. Yasir said I could also use MobileGo (which I had just uninstalled, but could reinstall if the need arose) or the App Drawer (not available on older Androids).

One other approach was to use ES File Explorer. In that app, Yasir said, I could go to menu (top left corner) > Tools > App Manager > select one or many apps to be uninstalled > Uninstall. It appeared that Solid Explorer might also have this capability. I was not sure whether Total Commander did.

Organizing App Icons

When I installed Helium, I saw that it put icons on both the Home screen and the Apps list. I had already learned how to arrange Home screen icons into folders (above). I wanted new apps to continue to add icons to the Home screen, so that I could sort them into folders as desired. But if I had wanted to prevent creation of the Home screen icon, on the phone I could go to to Play Store > menu (hamburger icon, upper left corner) > Settings > uncheck Add Icon to Home Screen.

Now there was a question of how to arrange icons on the Apps screen. I would be getting a lot of them, once I started installing more apps. Unfortunately, as far as I could tell, the SGCP provided no way of grouping them into folders or otherwise sorting them out. The good news was, I hoped, that what people were saying was true: a good launcher app would help me with that.

From the app list (above), I chose Nova Launcher (4.6 stars). It was not entirely clear to me what it did, or how it would be helpful; it just seemed like the best of the lot. That impression was reinforced by the number of webpages offering tips on how to use and customize it (e.g., AndroidPit, 2017, calling it “the kind of Android launchers”). I was dismayed to see that it immediately wiped out my arrangement of folders and icons on the Home and Apps screens. There did not in fact seem to be a way to use it to create subfolders or anything hierarchical; just drawers in Apps. But then, false alarm: when I uninstalled Nova Launcher, my previous folder arrangement was back.

I tried again with Folder Organizer (FO) (4.5 stars, $1.49). I did try using its free, ad-supported Lite version, but it was essentially crippled for my purposes, so I bought the full version. I viewed its tutorials on how to create a Home folder and organize items using labels. It seemed FO had installed a FO widget, and it was available in a half-dozen different shapes . . . but wait! When I tried to select one of them, somehow I wound up with my Home screen distorted, in a perspective view, as if I were viewing it from somewhat to right of center. I had to screw around with it for a while before a tap of the right duration in the right place finally put me back to the Home screen. Long story short, I did like the promise, but I saw that other users shared my bafflement on various points. I couldn’t figure it out. I uninstalled it, got my refund, and was left shaking my head at the rating inflation that gave this app 4.5 stars.

I went back to Nova Launcher (NL). I tried to follow the advice from WikiHow (2017) to clear my default launcher: Settings > Apps > Application Manager > ALL column > TouchWiz home > Clear Defaults. In my case, that button was grayed, and there was a note: “No defaults set.” I guess that was why I didn’t get the question WikiHow anticipated, letting me choose a default launcher. I wanted to get on with creating folders or drawers or whatever Nova would do, so I bought the Prime version ($4.99, 4.8 stars), using the Play Store webpage on the PC. I proceeded to fiddle with NL for an hour. At the end of that time, I was still not sure how NL worked, but I did feel that it would work. For my purposes, probably the key point at present was that I needed to go into Nova Settings > App & Widget Drawers > scroll down to Drawer Groups > FOLDERS > click on + sign (upper right corner) > tap on Title to name a new folder > tap pen icon, to the right of the new folder name > Select Apps > Check to mark apps and folders that should go into this folder. (I didn’t check the “Keep apps in main app tab” option because I wanted to declutter the main Apps tab by moving icons into these folders. Deleting a folder would just return an app to the main Apps tab.) So, yes, I did figure out how to create subfolders and sub-subfolders, and that was what I needed, now, to handle the anticipated flood of new app icons, as I proceeded to install apps.

Unfortunately, it seemed that Nova Launcher had a bug. I had organized my apps into folders, and had put some of those folders into other folders. Then, for some reason, some of those subfolders ceased to be in those other folders. So now I had a mess. When I had originally set up this hierarchical structure, items had been hidden as soon as they went into other items. Now I couldn’t tell which apps were no longer being displayed. By that point, I was in the process of installing many other apps (below), so I just started over from scratch and hoped that wouldn’t happen again. To start over, following AndroidForums advice, I went into Nova Settings > App & Widget Drawers > Drawer Groups > Folders tab > press on folder > Delete.

Installing Apps on Phone or SD Card

With so many apps, there was the obvious question of whether to install apps on the phone or, instead, on the MicroSD card. At this point, Settings > Storage (see also Settings > Application Manager > bottom of screen) indicated that I had to allow 4.3GB of 8GB on the phone to the OS and related (e.g., cache) files. It seemed that other apps and adjustments would easily consume and overflow the remaining 3.7GB.

Thus, if possible, it seemed advisable to install apps on the SD card whenever possible. It seemed best not to risk screwing things up by running the SGCP with the SD card removed, though I also saw, somewhere, an indication that SD cards were best removed before system updates.

I wondered whether I could set the phone to install apps on the SD card automatically, or if I would have to redirect them there one at a time, manually. A search led to this statement by How-To Geek (Kaufman, 2016):

Android 6.0 Marshmallow lets you “adopt” your SD card as internal storage, automatically installing allowed apps to the SD card. Some pre-Marshmallow devices may let you move apps manually, but only if the developer allows it. If you want more flexibility than either of these options offer, you can root your phone and use an app called Link2SD to make it happen.

I wasn’t going to root the phone. Tom’s Guide (Riley, 2017) observed that even the manual method would not work with some apps. TechRepublic (Wallen, 2015) and Instructables (2015) explained how to work with apps that would not install to the SD card.

Riley also said that, for this purpose, it was OK that I was using a Class 10 or UHS-I SD card, but that ideally I would have bought a UHS-3. To change the default download location, Tom’s Guide (Jpishgar, 2017) steered me to Apps > My Files > menu (top right corner) > Settings > Set Home Directory. Unfortunately, my SGCP did not have that option.

If I hadn’t been planning to use Nova Launcher, I might have sprung for something like App 2 SD (a/k/a AppMgr III) (4.2 stars) to assist in the project, due to such features as “move apps to external storage” and “notify when movable apps installed.” But it sounded like App 2 SD could conflict with Nova’s management of Home and Apps screens.

I planned, instead, to follow the advice of 1 2 3 sources and use a hopefully simple ADB command to set the SGCP’s default app installation location. Reviewing the ADB discussion (above), the ADB steps at this point (having already installed ADB on the PC) were as follows:

  • Connect the phone to the PC via USB cable.
  • Enable Settings > Developer Options > USB Debugging and the “always allow” option. (For security, remember to turn off the “always allow” option later: Settings > Developer Options > Revoke USB debugging authorizations, but re-permit USB Debugging.)
  • On the PC, go to C:\Program Files (x86)\Android\android-sdk\platform-tools in Windows Explorer, then Shift-right-click on an empty space in that folder > Open command window here.
  • Enter this command: adb devices
  • Expect to see “List of devices attached” (may just be one device). I got that, but also got the “adb server version (31) doesn’t match this client (39)” message that I thought I had fixed by installing drivers (above).
  • Enter this command: adb shell pm set-install-location 2. (Some sources preferred adb shell pm setInstallLocation 2.)
  • Expect to be returned to the command prompt without error messages.
  • To revert back to default state, enter the same command except for an ending zero: adb shell pm set-install-location 0

Installing Many Apps

So now, at long last, the moment had arrived. I clicked on the links (above) for the desired apps on my list, not counting the ones that were already installed; I watched their Play Store webpages open; and I clicked on Install. The phone couldn’t keep up with me: I was able to tell the PC to install apps faster than the SGCP was able to download and install them.

When I finished clicking links and telling the Play Store to install apps, I went to Settings > Application Manager > Downloaded, and started looking at where individual apps were being installed. At first, I thought the ADB approach had not worked, because some apps installed on the phone. But then I saw that quite a few were installing on the SD card. From what some sources had said, I guessed that some apps were designed to override the ADB command, either because the developer wanted the app to run as fast as possible or because the app really did need (for reasons of security and/or functionality) to be on the phone.

For whatever reason, quite a few apps were installed on the phone rather than on the SD card. Heymen (2014) said File Expert (4.4 stars) and other file managers would allow the user to check-mark multiple apps for easy relocation to the SD card. I looked at both File Expert and Total Commander, but I didn’t see that feature. So I went down the list manually, at Settings > Application Manager > Downloaded, tapping one app at a time, moving to SD card whenever possible, bearing in mind the advice not to move to SD card those with sensitive contents (e.g., password data). Almost all Google apps were among those whose Move to SD Card option was greyed out, and thus could not be moved. This seemed piggish, but I wondered whether part of the reason was that Google wanted to make sure it could back up, on its servers, the data for its own apps.

After all apps were installed, I took another pass through the Downloaded list. I hadn’t taken an exact count prior to this mass installation effort, but it looked like I had installed about 73 additional apps in this effort, with a estimated total of more than 90 altogether. I still had 3.2GB free on the phone. It looked like I had used about 1.9GB on the SD card altogether. So this effort of moving apps to the SD card had apparently made a large difference in keeping space free on the phone. I was sure that apps and I would continue to eat into the phone’s free space for various reasons.

App-Related Performance Issues

After I began the process of configuring apps (below), I noticed that the phone was less responsive than it had been. There would often be a minor delay, and sometimes a substantial delay, before it would finally respond to my tap or gesture. To prevent the app configuration process from taking more hours than necessary, I turned aside, to learn more about this performance issue.

It did seem pretty clear that the performance problem was app-related. I had been tinkering with the phone for weeks, at this point, without any instances of serious slowdown; but now, suddenly, it all changed. Nonetheless, I flailed around a bit, before getting more clearly focused on app problems. For instance, a search led to a suggestion that I switch to Settings > Airplane Mode for a few seconds, then turn Airplane Mode off. Participants in one discussion traced their slowdown problem to an SD card, and suggested trying to run the app without it (which would entail making sure it was installed on the phone, not on the SD card).

Eventually, I came around to the Diagnostics and System Information apps (above). Simple System Monitor seemed especially useful for its Active Processes tab. It said I had 40 active processes. In its menu (upper left corner) > Settings > Active Processes Monitor > Update Interval, I changed Set Update Interval from 3 seconds to 5 seconds, so as to help me focus on the more continual drains on system resources. (I had to turn the phone to landscape mode to see the Done button.) But I wasn’t sure what to do with that information. Later, unfortunately, GSam Battery Monitor told me that Simple System Monitor was responsible for 6% of my battery usage during the past eight hours — and there had been a lot of battery usage during those hours. So I uninstalled it.

AndroidPit (Woods, 2017) suggested I look at Settings > Developer Options > Process Stats. Here, I saw a thick color bar that, according to Android Developers Blog (Hackborn, 2014), indicated the state of the SGCP’s RAM over a period of (typically) the last several hours. In Hackborn’s example, that bar was all green, and was accompanied by a statement, “Device memory is currently normal.” That wasn’t what I was seeing on my phone. I was seeing a bar that was maybe 50% yellow, 40% green, and 10% red, representing the situation over the last 4:38 (h:m), with the statement, “The status of your phone memory is currently Moderate.”

So, OK, something had been demanding a lot of RAM in the last few hours. But what? Hackborn said the percentages below the thick bar indicated how much a particular process had been running. The top bar was Google Play Services (persistent) (i.e., one of several Google Play entries). It showed 100%. This meant that it had been running constantly, throughout the last 4:38, as one would expect from a “persistent” process. The TracFone My Account app had been running 98% of the time — not surprisingly, since presumably TracFone would want to know if I had been making calls. Hackborn said the blue bars indicated “the relative computed memory load of each process.” For instance, an app might run constantly, but might not use much RAM.

PhonesAbout (2014) turned me on to the discovery that I could tap on a segment of the thick color bar at the top, and I would get an expanded explanation of what was happening there. So, for instance, when I tapped on the red segment, the blue lines and percentages below the thick color bar all changed. Now it looked like a few particular apps were active throughout the Red (i.e., highly memory-intensive) periods and were also using a lot of RAM during those times. Some of them seemed reasonable. But I noticed that Facebook had a long blue bar (indicating high RAM usage) and had also been active for 32% of the past 4:38. That was remarkable, because at this point I had never even used the FB app. I had installed it, but had not yet gotten down to that point on the list, to fire it up and see what it did. Evidently it was happy to go ahead without me.

That Facebook entry was pretty confusing. I say that because I went, then, to Settings > Application Manager > Running tab. It showed 21 running processes. Facebook was not among them. My guess was, Facebook would fire up at random; it would consume a lot of system resources, in order to make sure I was all set to view the latest video of funny cats; and then it would shut down, and thus would not appear in the list of Running apps unless I happened to tune in at just the right moment.

At the bottom of the Running app list, I saw a summary of the current situation with my RAM: 740MB used, 144MB free. That could sound like RAM was being overused at the moment, but I assumed this was like on the PC, where RAM usage could be irrelevant: the CPU would try to keep RAM nearly full of material that it thought it might need next.

I felt that I could shut down some of those running apps. I tapped on one. It said, “Service started by application. Stopping service may cause application to fail.” So, clearly, I would want to shut down the main app first. I went back to the Downloaded tab and tried there. There was an option to Force Stop the app; but when I tapped that, it said, “If you force stop an app, it may cause errors.” That didn’t sound good.

If I did go ahead and Force Stop an app, Woods (2017) advised having enough sense not to do things that would crash your phone, like killing Google Services or, yes, Android System. That was fine advice, as far as it went, but (a) I felt that the advice to have common sense was mostly preaching to the choir, insofar as the roster of individuals who think they have common sense is not reliably coextensive with that of those who actually do, and (b) not to cast myself into either such group, but there had been moments of discovery, when it turned out that I was mistaken on the question of what was safe to delete or kill or shut down.

It did appear likely that, as Woods said, a person could shut down Facebook, or some other third-party app, without too much risk of doing serious damage. AndroidAuthority (Sims, 2017) emphasized that an app could “misbehave”:

It might stop responding to certain events, it might get stuck in some kind of loop or it might just start doing unpredictable things.

In such cases the app might need to be killed off and then restarted. That is what Force Stop is for, it basically kills off the Linux process for the app and cleans up the mess!

That, too, clarified something that had puzzled me in Settings > Developer Options > Process Stats. I noticed that the PastNotifications app was showing high and persistent RAM usage. Going into that app now, I saw that it had logged an ungodly number of notifications, during the past several hours. Not to say this was a deal-killer, but as I reviewed those notifications, I also noticed that its ad bar, at the bottom of the screen, was flashing in such a distracting manner as to make me want to get rid of it in a hurry. I doubted the ad content was causing the performance problem, though that was possible; but for whatever reason, PastNotifications seemed problematic. I still had the Timeline alternative. I decided to uninstall PastNotifications. Next time I had a slowdown, I would take another look and see what else might be featured in Settings > Developer Options > Process Stats. By then, maybe I would also have an idea for what to do about Facebook.

Sims (2017) said that, if you kill an app but don’t uninstall it, you would also want to go into Settings > Application Manager > tap on the app > Clear Cache. This would be harmless, because the cache would not contain data crucial to the operation of the program. The data in the cache was just stored there for purposes of efficiency. The primary reason for clearing the cache seemed to be to make more drive space available and, perhaps, to make the system run a bit faster.

Note that the Clear Cache option was not the same as Clear Data: that would reset it to newly installed condition, wiping out app settings, preferences, and saved states. AndroidPit (Gordon, 2017) considered both of these potentially appropriate responses to a malfunctioning app, though of course Clear Data could mean a lot of work to reconfigure the app to the desired condition. There was no guarantee that any such step would help. Several sources agreed that Android would generally manage caches well, and that this sort of thing should be done manually, not entrusted to the black box of some Android-cleaning app.

Digital Trends (Hill, 2017) said that I could kill apps running in the background, but that I should be careful about doing so, because usually they would be doing things that they needed to do, in order to accomplish the purpose for which I had installed them. Hill said that a third-party app (as distinct from a Samsung, Google, or Android system task) could be a good target for a kill if it was using a lot of battery. KitKat didn’t provide app-specific information at Settings > Battery. Instead, How-To Geek (Summerson, 2016) pointed me to GSam Battery Monitor (4.5 stars). Specifically, the second of the four icons across the bottom of the GSam screen (i.e., the one shaped like an open laptop) led to GSam’s App Sucker calculation, indicating the amount of power used by various apps in the current period. (The third and fourth icons at the bottom allowed me to designed the preferred period and other settings.)

Summerson also recommended System Monitor Lite (4.3 stars), pointing especially toward its CPU Frequencies tab:

[I]f your phone has been lying on your desk for four hours with very little use, you want the top CPU state to be “Deep Sleep,” which means everything is working like it should be—there are no apps keeping the processor alive, thus keeping the phone awake and draining the battery.

Summerson said that, somewhat like GSam, the Top Apps tab in System Monitor Lite would shed light on the apps that may be using excess resources. I noticed that entries in that tab could be sorted by name, percentage of CPU usage, or MB of RAM usage. I could also tap on an app and be taken immediately to its Settings > Application Manager entry, displaying among other things its Force Stop and Uninstall buttons.

Hill (2017) said Force Stop would be grayed if an app was not running. He also said that Force Stop might only stop apps temporarily. To make sure the app would not start again, he recommended uninstalling it — or, in the case of a preinstalled app that could not be uninstalled, disabling it (both available at Settings > Application Manager). As with so many other things, he said there were additional options for rooted phones.

I suspected that the SGCP had become overburdened with apps, as I continued opening and configuring the many that I had just installed. This suspicion called into question the widespread claim that Android was usually very good about shutting down apps that are no longer in active use. It appeared that Android could actually take a while to figure out which apps could be most efficiently shut down — that it might dawdle in a deluge of demands, leaving the user to either shut down apps manually or walk away for a while and let Android catch up.

Trying Greenify to Control Apps

Hill (2017), among others, recommended against using task management apps. But by this point, I had encountered many references to Greenify, especially, as a means of controlling app behavior. The app’s Play Store writeup cited some of its awards circa 2013 (i.e., the era of the SGCP). When I started Greenify, it asked whether my device was rooted. Then it sought my permission to use Accessibility Service and Device-admin to achieve automatic hibernation of apps during hibernation (i.e., when the display went dark). For each of those two items, I provided permission by tapping on the red SETTING word and then turning on the indicated Greenify feature. After I provided permission, the X and the text in orange background were replaced, for each such item, with a green check mark.

When I finished with those startup steps, Greenify showed me its App Analyzer screen. I hit the menu (top right corner) > Show All. What followed was … confusing. I did not understand what the app was trying to do. It did not help that the SGCP itself was so unresponsive. I needed Greenify to behave in a logical manner, to help me start to control whatever it was that was slowing the system so dramatically. Instead — even when I put the phone down and came back hours later, hoping that this would allow the phone and Greenify and other apps to sort themselves out — the phone was still very slow, and Greenify was still baffling.

In more detail, it went like this. I went to Apps > Greenify. Instead of a sensible starting menu, I saw that two apps (i.e., AppLock and Sophos) were listed as hibernated. I did not want them to be hibernated when the phone was operating. I did not know why they were hibernated. No doubt I had pressed the wrong thing, hours earlier, when I was attempting to find my way around Greenify. The first problem was that there did not seem to be a way to persuade Greenify to let them go, so that I could return to square one and go down my list of apps sequentially. I tried Greenify’s menu (upper-right corner). Its options were Refresh, Put into hibernation now, Create hibernation shortcut, Settings, Troubleshooting, and About. I tried Settings. That did not lead to a list of apps that I could select or deselect for any particular treatment. I backed out and tried Troubleshooting. The options given there did not seem responsive to the situation.

A search led to a Quora answer (2016) that said I should be seeing the App Analyzer. I was able to get to that, from this screen listing those two hibernated apps, by pressing the + key at the top right corner. The Quora answer said Greenify divided my apps into four categories: Running in Background, Scheduled Running, May Slow Down the Device When,” and Show All. I didn’t have any Scheduled Running Apps. Also, I saw Show More, at the bottom of the list. I wasn’t sure whether the ones in Show More were a continuation of the May Slow Down the Device category. To get to Show All, I had to tap on the menu icon (top right corner). The May Slow Down category seemed to be explaining when a given app would slow the system. For instance, after Lock Screen Widget, it said, “Keyguard is unlocked. Network connectivity changes.” It seemed to mean that either of those situations would make Lock Screen Widget more active.

The Quora answer said I could select any apps I wanted, but it also said, “I wouldn’t recommend picking apps that you commonly use whose functionality relies on regularly phoning home.” It gave the example of Google Maps and weather apps. I think the answer didn’t literally mean “phoning” anyone; I think it just meant that I should probably not use Greenify to limit the running of apps that I would expect to run constantly. Google Maps would be a good example if I was often out and about and expected it to be responsive all the time. Otherwise, one would think I could just go out, see that it was not responding, and turn it on when needed.

The Quora answer referred to a checkmark icon in the upper right corner. Instead, as soon as I selected my first app, I had a checkmark in a green circle at the lower right corner. At this point, I began to grasp the nature of the situation. In PC-land, you have programs running in the foreground; you might have a few dozen programs and services running in the background (according to msconfig); but generally you don’t run stuff that you don’t need. When you need something, you start it up. If it needs to know system history, it reads logs generated by Windows. Something like that, anyway. But on the Android, there seemed to be two different worldviews. People might want to control what’s running, PC-style, but Android itself was not inclined to shut things down. It wanted to have them ready and waiting. And I had seen where that would lead: I would get a system that was trying to make everybody happy, and would ultimately not work very well. So, contrary to what people had said about Android being very smart about shutting things down when they were not needed, it seemed I would have to make some decisions about such matters myself, if I didn’t want a recurrence of the kind of slowdown I had just experienced.

In that light, the Quora instructions could be interpreted as saying, Use Greenify to control everything that you don’t absolutely need to run constantly, and adjust the list later if it turns out you’ve overcontrolled. Given the relatively slow CPU and relatively small RAM of this device, I would have to make hard decisions about putting a governor on even those system information apps that would be most helpful if they could show me how the system had been performing over the past several hours. I would have to come back to those and take them off the restriction on a case-by-case basis, as needed. I found, incidentally, that pressing Show More or Show All unselected everything I had selected to that point — so it was a good idea to Show All before beginning down the list. Show All ineptly duplicated the list of those in its main categories (e.g., Running in Background). I wasn’t sure what to do next, after selecting 71 apps, so I tapped the green checkmark. I got, “Unfortunately, Greenify has stopped.”

I decided to try my luck with other apps, and thus decided to uninstall Greenify. But when I went into Settings > Application Manager > Greenify, I saw that its Uninstall button was greyed out. A search confirmed that I was not alone in having this problem. An AndroidCentral discussion offered the suggestion that I go to Settings > Security > Device Administrators > uncheck Greenify Automator > Deactivate, then try the uninstall. That worked.

Using ShutApp to Control Apps

I tried ShutApp (4.4 stars). When I first ran it, it took me through a few steps to get itself set up. Step 2 said, “Find ‘ShutApp’ and turn its service on.” I tapped on ShutApp: Off. That put me at Settings > Accessibility. In the Services section, I saw that a bunch of my newly installed apps were listed but turned off. I went down to the ShutApp entry on that list > tap > turn On. Now ShutApp ran a calculation and told me that I had 27 apps running in the background, allegedly accounting for 30% of battery usage and 53% of data usage. I wasn’t sure what to do next, and didn’t want to do anything drastic, so I tapped the coffee cup icon in the upper right corner. It put me through to the AppCafé forum. Not quite what I was looking for. I tried again, this time tapping the big SHUT circle in the center. ShutApp proceeded to shut down those 27 apps. What was I saying about drastic? At the bottom, in very faint print that I could barely read with my phone in black (i.e., not white) mode, it said something about adding apps to the whitelist if I didn’t want them shut down. When the process was complete, ShutApp proudly informed me that I had saved the aforementioned 30% and 53%. I tapped on its big circle again. It said, “1 App running in background.” I tapped a few more times, and that one was shut down too.

Well, it was clear that I had needed to do something. Within the space of the last 15 minutes or so, battery power had dropped from 100% to 85%. And let me say the hemorrhage continued, even after ShutApp had done its deed: battery dropped further, to 74%, within the next few minutes, and the phone was still not very responsive. It seemed I had not yet found the culprit. Meanwhile, ShutApp itself was becoming a problem. Hours later, I decided I didn’t need it to run constantly. I went to Settings > Application Manager > Downloaded tab > Force Stop. But then I saw that, in Settings > Application Manager > Running tab, there were now two services related to ShutApp. I tapped on each and stopped both of them. But now there was another. Ultimately, I had to uninstall it to get it to stop.

Closing Apps Manually; LastPass and KeePass

Now Settings > Application Manager > Running tab listed only a few items that I did not want running, including Google Play Music, Facebook, Samsung Push Service, Samsung Updates, and (ironically) ShutApp. I started with Google Play Music. When I tapped on it, I got a warning: “This app cannot be stopped safely. If you stop it, you may lose some of your current work.” I didn’t think I had any current work, so I stopped it.

Next, Facebook. I had already heard and seen that Facebook was a resource hog; so now it occurred to me that I didn’t really need the app; I could just browse to FB via web browser when I wanted it. To verify that, I went into Chrome and typed It put me at the Facebook sign-in page. Now I needed to remember my password, or else use LastPass. This seemed like an excellent opportunity to get LastPass started on the SGCP, so I went to Apps > LastPass and started to log in.

I got to the part where they were asking for my LastPass password, and I paused. Was I really sure I trusted the Android platform with key passwords? Granted, I had removed my banking passwords from LastPass; those were in my head. But surely someone could still do damage, if they gained access to my password list. I was aware that LastPass had been breached in the past — that is, hackers had gained access to user login credentials. Perhaps that would never happen again; perhaps it would never happen to Dashlane — or perhaps it would keep happening to those tools. They seemed more vulnerable, to me, because they were cloud-based and proprietary.

KeePass differed: the login credentials it stored were kept within the program itself, not synced on servers elsewhere. I could save, on KeePass, only those passwords I would need for sites I would use on the SGCP. Even if someone got access to its contents, the damage would be limited. KeePass was reportedly the only major open-source password manager, which meant it was among the few that were free and whose workings were subject to public scrutiny. I felt the community of security-oriented coders tended to be paranoid and, as such, might do a better job of providing up-to-date security.

There was no official Android version of KeePass. Instead, there were Android versions created by individual programmers or groups, as offshoots of the official KeePass project. Among these, there was a set of Keepass2Android options: Keepass2Android Password Safe offered a cloud sync option like LastPass and the others, while Keepass2Android Offline (4.6 stars) was strictly local. I chose the latter.har

Configuring Apps

I went to the phone’s Apps list and opened each app that I had not already explored (above). This seemed advisable, to make sure apps were functioning. It also gave me a chance to become somewhat acquainted with them. Along the way, apps called for various responses. I did not log all of the steps that various apps took me through, but here are some examples of what I encountered at this point:

  • Many apps took me through optional or mandatory introductory or explanatory screens (calling for swipes or button presses in order to advance), or required me to agree to Terms of Use.
  • Some apps offered upgrades to premium versions.
  • Some apps knew who or where I was automatically; some required me to enter identifying information.
  • The AAA app asked if I wanted to receive push notifications. My search led to a quote from TechTarget (Rouse, n.d.) that persuaded me to answer yes:

An important advantage of push notifications in mobile computing is that the technology doesn’t require specific applications on a mobile device to be open in order for a message to be received. This allows a smartphone to receive and display social media or text message alerts even when the device’s screen is locked and the social media application that is pushing the notification is closed.

  • Most apps had menu > Settings options that I could configure to make them work as desired.

Some apps had problems, or required more complicated actions or decisions. Here are a few examples of the kinds of issues I ran into. I did not attempt to log them all:

  • AAA’s app had tabs with nothing on them, and after I clicked on a few of its tabs, it said something like, “Unfortunately, AAA has stopped working,” and I found myself back at the Home screen. The app also asked for my AAA membership number. It made sense to enter that now. I didn’t think a thief could do much with it, and I would rather have that already set up if I needed AAA to come rescue me.
  • Google Calendar gave me an option to sync with my PC, but did not explain how to unsync — which, I thought, might be best at the start, until I was sure I would not accidentally be wiping out Calendar settings. The solution was to go to Settings > Accounts > Google > listed account (in my case, my Gmail account) > uncheck the Sync Calendar option.
  • The first time I tried, Amazon Kindle did not run. Both times I ran it, I got long delays after tapping its icon. The first time, that ended with a message indicating that it was not running. Kindle required me to enter my phone number and Amazon password. Since the latter was linked with a charge card, I stopped at that point. Amazon Shopping, by contrast, gave me an option to skip sign-in.
  • AppLock started by requiring me to draw an unlock pattern, like the lock screen option (above). Then it gave me a list of installed apps, and the option to toggle each between locked and unlocked status. For example, next to the Incoming Calls icon, there was explanatory text: “Prevent others from taking incoming calls.” Once I did that, AppLock responded to every new app installation with this question: “Do you want to lock [app]?” I assumed it was asking if I wanted to have to enter that unlock pattern every time I wanted to use that app.
  • I briefly installed Backdrops (4.3 stars) and then decided to uninstall it. I shouldn’t have installed it: I got “Uninstall unsuccessful.” Someone advised that I go into Settings > Application Manager > select Backdrops > Force Stop. But that led to the puzzling discovery that Backdrops no longer appeared there. I tried reinstalling and uninstalling again. That worked. To reduce the risk of more such problems, I powered the phone down and powered it up again.
  • It occurred to me that I did not necessarily need separate apps for some commonly uesd websites: I could just save bookmarks to them in Chrome. This was a particularly helpful decision for those that used a lot of system resources and battery, notably Facebook, which I generally tried to visit just once a day. The eBay app (4.3 stars) was another example, especially since I did not think I would be doing much of my shopping on the phone. Other examples: Google Maps (4.3 stars), Amazon Shopping (4.3 stars), Walmart (4.5 stars)

The process of going through all these apps was quite time-consuming. Actually, it could have gone on indefinitely. At a certain point, though, I began to settle into a set of apps that I seemed to be using more often, and I got rid of some of the others.

Hardware & Accessories

Previous sections have mentioned some items of hardware that, at least for my purposes, seemed integral to the full use of the SGCP. My TracFone SGCP came with a USB cable, enabling external connections to PC and recharger as described above, and it also came with a SIM card (though evidently some don’t). It did not come with a Micro SD card; I had to buy that on my own. Now the question was whether I could and should acquire other kinds of hardware to be attached to and/or used with the SGCP.

External Drives

It seemed that many sources confusingly described a cellphone’s Micro SD card as “external.” Granted, it was not built into the phone’s sealed hardware. But then, neither were many PC add-on cards (for e.g., improved graphics); yet nobody considered those cards, plugged directly into the PC motherboard, to be “external.” My phone’s Micro SD card was obviously internal to the phone and, as I found, it was not easy to remove.

Unlike the internal Micro SD card, there appeared to be genuinely external drive options for Android devices. One option, explained by How-To Geek (Hoffman, 2016), involved connecting a phone to a properly formatted external USB flash drive. (Presumably it could also work with an independently powered hard or solid state drive mounted in an external drive dock.) Hoffman said Android would recognize FAT32 or exFAT file systems, but not NTFS. Hoffman (2017) indicated that exFAT was Windows-compatible and did not suffer from the FAT32 limitation of 4GB per file.

To connect the phone to the external USB drive, one would need a USB OTG cable. This was simply an adapter — male MicroUSB on one end, to plug into the phone, with a short cable leading to a standard (i.e, not mini or micro) female USB-A (i.e., the blade-shaped USB connector, not the box-shaped one) on the other end.

The more problematic requirement was that the phone be capable of serving as an on-the-go (OTG) host. On that, a search led to a Beebom (2016) article explaining that OTG would enable an Android device to power and control USB peripherals (e.g., keyboard, mouse, external drive). Beebom said that one way to verify that a phone supported OTG was to install Easy OTG Checker (3.7 stars at Google Play), connect a USB OTG device, and see whether the Checker said it was OTG-compatible. Alternately, CNet (Broida, 2014) suggested USB OTG Checker (3.7 stars). Given the less-than-superb rating of these apps, and the desire to avoid buying a USB OTG cable and device to find out, I wished for an alternate source of insight. In that case, InfoWorld (Raphael, 2015) said that an OTG-compatible Android would tend to have an option to Mount USB Storage at the bottom of Settings > Storage. Mine didn’t have that. Beebom said I could also look for the “Certified USB On-the-Go” logo on my phone’s packaging or in its product description. Mine didn’t seem to have anything like that. Mine was also not included in Beebom’s list of OTG-supporting devices. Beebom said a majority of newer Android phones did support OTG; but if mine didn’t, I could get that capability by rooting the phone (above). Broida (and also Hoffman, 2016) offered guidance in doing that.

I wasn’t planning to root the phone. That, however, was not necessarily the end of the discussion. Greenalien (2014) said that, on his device running KitKat, OTG was working until he upgraded the OS to KitKat 4.4.2; then it stopped working. It was possible, in other words, that some other (presumably older) version of KitKat could be installed on the SGCP, and that this would enable OTG. It was also possible that the right commands to the phone via ADB (above) would solve the problem. But I didn’t intend to research any of that now.

Otherwise, it seemed the remaining option was to try a wireless external drive. While the wireless connection might still be roughly half as fast as a USB cable connection, the relatively direct link between device and external drive (i.e., not involving uploading to the Internet) would tend to make it much faster than cloud backup. CNet (Broida, 2017) offered further discussion and examples of this option.

There was, finally, the option of using the PC itself as a large external drive for the Android. This perspective would not be as obvious from the PC side, where a view of the USB- (or wirelessly) connected Android in Windows Explorer would make the phone appear to be just another storage device. But it seemed that an Android file manager (at least ES File Manager, and presumably others) could provide that perspective from the Android side. It appeared that treating that PC as an external drive might also be feasible without the USB cable, using something like SuperBeam WiFi Direct Share (4.3 stars) with Wi-Fi Direct (a/k/a Wi-Fi P2P). According to the User’s Manual, Wi-Fi Direct was available via Settings > Wi-Fi > menu (upper right corner) > Wi-Fi Direct > let it scan for available devices > select a device > confirm on other device.

Mobile Wireless Hotspot

For purposes of security and availability, the traveler would not necessarily have to rely on public WiFi. One alternative was to use a phone or some other device to serve as a portable WiFi router that would provide a private WiFi connection (for e.g., one’s laptop). The User’s Manual said that the SGCP had this capability: Settings > Tethering and Mobile Hotspot. But there was no such option on my phone. Evidently TracFone disabled that capability.

There were alternatives. According to Patterson (2012), a mobile WiFi hotspot device would tap into a cellular network, just like a smartphone, and thus enable other WiFi-enabled gadgets nearby (within a radius of maybe 30 feet) to go online. Several current sources (i.e., PCMag, AndroidAuthority, Lifewire) listed devices they considered best. Among the names listed by these sources, Verizon and AT&T seemed to dominate domestically, and Huawei internationally; but for data only (which would presumably be the desire of someone owning my TracFone), Lifewire liked the Sprint Pocket WiFi, reportedly available for free with a two-year ($7.50/mo.) contract offering no data; data was $110 for 30GB. Unfortunately, Sprint’s own page said this device was out of stock — which may have been just as well, because 21 raters on that page gave that device an average of about 2.5 stars.


The SGCP had a headset jack, for a wired headset (i.e., headphones plus microphone), as well as Bluetooth (i.e., wireless) capability. Which was better?

It appeared (above) that using Bluetooth would make a smallish difference in battery life. One source (above) suggested disabling Bluetooth, so that thieves would not be able to use it to locate my phone, and perhaps that was still good advice, but SoftonicApps (Pewter, 2016) said that at least “outsiders” would not “be able to tap into” Bluetooth 4.0 (the version used in the SGCP, above).

In terms of usability, The Verge (Goode, 2016) argued that Bluetooth headphones were annoying: it was convenient not to have a cord, and the sound was good, but they had drawbacks. She repeatedly mentioned needing to charge them, or finding they were dead. Consistent with that, MakeUseOf (Long, 2017) praised a $30 pair of AYL Bluetooth headphones for their “commendable seven-hour battery life,” and the Plantronics M55 Bluetooth headset for its “colossal 10-hour battery life.” Similarly Guiding Tech (Tinari, 2017). Technical Tips (2017) suggested the typical range was five to eight hours of use (though some said up to 15-20 hours for a few expensive units), and two to four hours to recharge. For a heavy user and/or someone who abhorred the thought of (a) running out of Bluetooth juice or (b) carrying a wired backup set of headset earbuds, those values could mean recharging the Bluetooth headset every night — and would almost surely mean taking the Bluetooth charger along when traveling. Consistent with that — and, again, speaking of headphones rather than a headset — BHPhotoVideo (Bockrath, 2017) expressed appreciation for Bluetooth units that came with a backup cord for when the battery died, and echoed the sense of frustration when the battery died. Bockrath preferred the ergonomics of the controls in wireless units (sometimes offering e.g., the use of sensors to mute the microphone when the unit is removed from the head).

The New York Times (Schmidt, 2014) said, “Bluetooth headsets . . . are great if you spend a lot of time on the phone. But for those who make only an occasional call, in-ear headphones are more convenient and generally more comfortable.” Focusing on audiophiles, Decibullz (Herb, 2017) said that wireless headphones were more likely to encounter audio interference and would generally struggle to match the audio quality of a wired set — but cords were also a hassle, needing to be wound up every time a user moved from one location to another, not being ideal for working out, and requiring the user to be very close to the sound source (in this case, the phone). Sensear (Goldthwaite, 2014) noted that potential sources of wireless interference were many: microwave ovens, baby monitors, wireless speakers, and so forth.

There was a question of whether Bluetooth technology would be unsafe due to its use of radio frequency radiation so close to the user’s head. The Los Angeles Times (Healy, 2016; accord LiveScience, 2016) said that experts felt the levels of radiation from a Bluetooth headset were too low to have a health impact — whereas at least some experts felt that holding the cellphone itself near one’s head had “possible” carcinogenic effects.

There was also a price issue. Lifewire (Hyde & Popolo, 2017) did characterize the HAVIT Bluetooth 4.1 Headset (currently $15 at Amazon, with 130 ratings averaging 4.3 stars, boasting 13-hour battery life) as “a quality headset at an affordable price,” but most of the Bluetooth headsets recommended by that source and others were considerably more pricey. For example, the PCMag Editor’s Choice headsets (Segan & Colon, 2017) were in the range of $72 to $199 (similarly AndroidAuthority, 2017). On the other hand, it appeared that a fair number of the best-selling, highest-rated Bluetooth headsets at Amazon cost only $25 to $40 — though that was still more than some very inexpensive, well-received corded headsets, such as a Panasonic set for $14, that would also have stereo capability for listening to music.

In response to some comments on those and other offerings, I decided to test the option of using a pair of stereo earbuds to hear, and using the phone’s own microphone to speak. I had rarely used earbuds, preferring an over-the-head type of headset, so this was an opportunity to become reacquainted with snarly little cords and such. I was able to verify that this would work, technically speaking: plugging in the stereo headphones, with three distinct metal elements on their plug (unlike the four elements I saw in the ads for earbud headsets with mic), did not disengage the phone’s mic. To verify that, I called a test number.

If I did get a Bluetooth headset at some point, the User’s Manual (p. 66) said that I would need to go into Settings > Bluetooth > turn Bluetooth on > let it scan > select the device that I wanted this phone to pair up with. Unpairing involved Settings > Bluetooth > tap the gear icon next to the device to unpair > Unpair.

Power Options

Charging the phone at home or work was fine: as described above, I could plug in the charger, or connect the USB cable to a computer, and the phone would charge. But what if I did not have access to a computer or wall outlet?

I was not in that situation presently, so I did not plan to explore this in detail at present. But, briefly, one possibility was to carry a second, backup battery for the SGCP. Samsung said the original battery had a capacity of 2000 mAh. Various sources offered those, starting at about $6. It would also be possible to buy an extended version of that battery. These seemed to be available from Amazon and possibly other merchants in a variety of capacities. According to the User’s Manual (p. 69), the stock battery contained a built-in NFC antenna (above); one would want the replacement battery to have similar characteristics, so as not to lose that functionality.

Another possibility was to expand the range of charging options. It would sometimes be feasible to recharge from wall outlets in restaurants and libraries or (perhaps with the aid of an extension cord) from an external AC power outlet, sometimes encountered on the outside walls of buildings. The car was the most common power non-building power source, and USB cigarette lighter adapters were the most common means of tapping that power. Various sources indicated that, as long as the car’s battery was in normal health and the car was being driven with reasonable frequency (so as to recharge the battery), the miniscule draw from a USB adapter and/or a phone would not bother it.

In another post, I described how I had used a deep cycle marine battery to power my laptop for many hours on a camping trip. (The marine battery had more capacity than the car battery, was built to be discharged more deeply than a car battery should, and could be run down without imparing my ability to drive away from the campsite.) In that case, I had used an inverter to turn the 12V battery current into 120V AC power, so as to run the laptop’s charger; and then that charger had converted the 120V AC into whatever the laptop needed. Those conversions (and the mini-fan on the converter) involved a lot of wasted energy; even so, I got 85 hours of computing out of a single charge of the marine battery. A USB cigarette lighter adapter, connected directly to that marine battery, would presumably entail much less waste, permitting that huge marine battery to run that little cellphone for a very long time before needing to be recharged.

Of course, there were also less massive battery packs, also known as power banks or bricks. Multiple (e.g., 1 2 3 4) sources listed a number of such devices. In my brief scan, these generally seemed to offer capacities in the range of 4,000 to 7,000 mAh (i.e., enough to recharge a smartphone once or twice) — but in a few cases going as high as 30,000 mAh — at prices of roughly $35 to $80 (though some were under $20), typically requiring two to five hours (but in a few cases much more) to be recharged.

Instead of lugging a battery pack (or to keep it recharged), there was the option of using a solar charger. Amazon offered a couple dozen highly rated solar chargers with micro USB connectors suitable for the SGCP, mostly in the $20-50 price range. There were also a few non-solar generator alternatives, though most of these still appeared to be in the conceptual or early commercial stage, and as such were not in the same price range as the solar chargers. I was disappointed that bike generators did not seem to have progressed much in the past half-century, but I was also heartened to observe one tinkerer’s DIY handlebar-mounted fan-driven phone charger. Then I found an article by MakeUseOf (Brookes, 2015) listing some modern-day bike dynamos, along with a couple more DIY options. Finally, MakeUseOf (Smith, 2013) introduced me to a hand-crank charger and a camp stove capable of charging USB devices.

Case, Stylus, and Screen Protector

I decided to get a case for the SGCP. The one I chose was $7.69 and, as shown in the photos at Amazon, it would open and shut like a checkbook, with a magnetic clasp that seemed less worrisome in this post-floppy disk era and was probably (hopefully) not strong enough to harm the contents of any hard drives it might come near. The clasp was somewhat in the way — I had to bend it back and hold it with my hand when using the phone. An energetic soul could probably slit apart the clasp and replace the magnet with Velcro. Simply removing the clasp would leave the case more willing than a checkbook to flap open — that is, left halfway open, it had a slight tendency to want to close. The material had stiffness comparable to non-corrugated cardboard (e.g., two or three layers of cereal-box cardboard). It would not be as protective (nor, perhaps, as thick) as a hard-sided case. This case appeared to have all the holes needed to allow access to the phone’s buttons, ports, microphones, and other orifices. The rubber material forming a socket to hold the phone was good-fitting, easy to wrap around (and unwrap from) the phone’s edges. Contrary to complaints by a small number of reviewers, it did not seem to me that either the phone or the rubber were likely to fall apart, crack, or otherwise fail, within coming months and probably years. If the phone fell, and depending on how it fell, I believed the case would offer some protection. I noticed that the case held heat, which was not good, when the phone heated up due to some intensive process; but, so far, that did not seem to be happening very often. I did not intend to add credit cards or other materials, and for that reason did not get more of a wallet-type case, partly because I didn’t want the extra thickness and partly to avoid creating high points that would exert extra pressure upon a small area of the phone’s screen, should I or anyone else happen to sit or step on it or bump it the wrong way. The case had a crease lengthwise down the back, so that it could be folded back to create a 45-degree viewing stand — again, as shown in the Amazon photos. I was not confident that the material’s stiffness would tolerate being bent that way endlessly without becoming sloppy, but it would be easy enough to prop up if it did. The Amazon photo showed the clasp as getting in the way if the case was in fact used as a viewing stand, but that was not necessary: the clasp could be bent back in the other direction, and thus kept out of the way. Overall, I liked the case.

The case came with a stylus — that is, a little plastic pen with a rubber tip. It worked well for typing on the unit’s keyboard and other small spaces. The case did not have a place for the stylus. The stylus was attached to a little rubber plug that would probably stay inserted into the headphone jack during travel. Sticking the stylus into the main crease, where the case hinged open or shut, did not work: the stylus was too thick. It would prevent the case from closing properly. It was also not feasible to wedge the stylus inside the clasp. A thick rubber band, coupled perhaps with the headphone jack plug, could serve to hold the stylus in place and maybe also replace the magnetic clasp. Maybe there would be a place for Velcro here too. There were other kinds of styliartistic ones, for example — and accompanying apps. It didn’t take too long for me to tire of the short little stylus. A search led to numerous very inexpensive alternatives. These pen-sized alternatives would have to be carried along somehow or left behind.

I was not sure whether to get a screen protector. These were made of glass and of various plastics, and the best ones seemed to cost around $8 to $12 (e.g., Lifewire, 2017), though there were cheaper ones to be had. AndroidAndMe (Barnard, 2015) contended that screen protectors were problematic: they were difficult to add without introducing air bubbles; they could feel wrong (e.g., too grippy); they could become discolored with age; and they seemed unnecessary, because phone manufacturers made a point of using materials that would wear well. I felt that some of the liquid-skin products selected by Lifewire would probably respond to most of Barnard’s concerns, but I agreed with the view that they were not necessary. Barnard, evidently not using a case either, said he put his phone into a designated pocket where there would be no keys, sand, or other extraneous objects or materials that could scratch the display. Readers commenting on Barnard’s article (including someone who claimed to work at a phone repair shop) tended to argue that the display’s original coating would wear off, tiny scratches would accumulate, and generally a screen protector was a good idea. They seemed especially fond of the ones made of tempered glass. I decided this was an inexpensive phone, already protected by a case, accompanied (as I recalled) by complaints that it (i.e., SGCPs owned by others) had died after a year or two, apparently not resaleable under TracFone’s terms, not likely to be in constant use, and as such probably did not need a lot of expensive additional protection. Nonetheless, given an opportunity to buy five pieces of plastic guard film for a dollar on eBay, I decided to try that.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.