I got two Android-variant phones working without a Google account and without Google apps that spy on you. For the moment I am assuming that Android purely as an OS isn't the privacy culprit--that is, the core Android Open Source Project is not the problem; I address that assumption below. The problem is the Google account and Google apps that specifically ask you to sign away not just your firstborn child but all of them. (Unfortunately, that is not much of an exaggeration if any.)
The Android variant I installed was LineageOS. The second and last installation was on a Motorola Moto G7 in January, 2020. I rooted the phone, too.
A related product is the Freedom Phone for $500. That's not a recommendation; I haven't looked into it. It's the only example that I remember the name of.
This is a "how to" for Lineage installation. If you don't want to do it yourself, I would sell you a Lineage OS phone for roughly $250. I'd have to ask you exactly what you want and think about it to come up with a definite price. My contact info is on my resume.
There is probably a business in this. It's not the sort of thing I would jump into on my own, but I might be so motivated. Below I switch between "I" and "we" because I got paid to explore the possibilities. The exploration was a success in that we demonstrated a working phone without a Google account and pre-installed Google apps. The exploration didn't fail; it just petered out because my business partner got distracted.
I had barely started packet sniffing Lineage to start the long process of seeing if core Android--minus the Google account and apps--ran home to mama Google. The results were promising. The phone still used Google servers simply to check for a network connection, but that would be relatively easy to change. However, it would take a long time to be more and more sure that core Android doesn't have gotchas.
I remember reading about one Android "fork" that was aggressively researching this question and making changes. Google Search might not find it, but DuckDuckGo might.
A couple of parting thoughts for this intro that I'm rewriting in December, 2021: Getting a non-stock Android working on your existing phone is unlikely, even if I were doing it. I go through the if-thens below because our first thought was to help people convert their current phones. However, the focus of the project moved towards the assumption that you'd have to buy a new phone.
On a related point, it took me 5 attempts to find a phone that would allow a Lineage installation. (For the record, I succeeded on Feb 22, 2019. It was a happy moment.)
The following hasn't changed since early 2019.
First, a very simple list, then elaboration. This list hopefully gives you an idea of when Lineage is easy to install. There are possible harder routes that I discuss further below.
This "easy" list will be hard to satisfy. It's a list of supposedly easier installs, not an easy list to satisfy. Hopefully I can widen it as I get deeper into the project.
NOTICE: The LG G5 H830 currently has flashing locked!At this point in the project, that stuff is OUT.
You will need to use a tool to get around this limitation. At the moment, Team Win nor myself cannot provide anything for this.
Samsung made (and probably makes) a lot of phones for AT&T, and the AT&T phones don't seem to want you doing anything off their path. Beyond AT&T, it seems that the Samsungs that might work are too old to be supported by Ting, and, with the newer phones, only the international (especially Korean) phones MIGHT work.
Thus, sourcing non-US Samsung phones is worth investigating.
In the original version of this page (Jan. 2019), I listed LGs that specifically allow unlocking via an LG dev account. That is still worth investigating. However, some of the phones listed as unlockable still seemed to be problematic when reading the XDA threads.
The H830 and others go on to say that hacking / cracking / rooting tools exist that will theoretically let you install stuff. As of February, 2019, I consider that beyond the project scope, but it will probably come up--I will try those--in later phases of the project. Also, given that Android is essentially Linux, I find it very ironic and frustrating that most of the Android hacking is done on Windows machines. So far, I refuse to run Windows. I may have to condescend for this project at some point, though.
For the most part, I followed the Lineage and TWRP directions and phone #5 went anticlimatically easily after the previous 4 phones. Below are some non-obvious issues, though.
The irony that the first phone to work was a Google-branded phone is not lost on me.
For the Nexus 6, TWRP has this to say:
Note many devices will replace your custom recovery automatically during first boot. To prevent this, use Google to find the proper key combo to enter recovery. After typing fastboot reboot, hold the key combo and boot to TWRP. Once TWRP is booted, TWRP will patch the stock ROM to prevent the stock ROM from replacing TWRP. If you don't follow this step, you will have to repeat the install.
That may have had me chasing my tail if I hadn't read it. With phone #5, I didn't need to Google anything, though. In bootloader mode, there are a clear series of prompts using the 2 volume keys and the power key that let you boot into recovery mode and thus load TWRP. Phone #5 (the Nexus 6) did indeed replace TWRP before I booted into recovery the 2nd time around. That is, if you don't boot into recovery after flashing TWRP, the phone will boot normally and TWRP is erased and has to be re-flashed.
TWRP will only back up to the phone's internal storage or an SD card. Internal storage is wiped during the next step in the process. I am not sure about SD cards being wiped. In any event, I had to go hunting for where TWRP saves its backups. From the Android shell, the backup goes to your equivalent of /data/media/0/TWRP/BACKUPS/ZX1G227JGT/2019-02-22--16-59-10_N8I11F . That shows up in the Linux file manager as TWRP/BACKUPS/ZX1G227JGT/2019-02-22--16-59-10_N8I11F
When I first tried the "wipe" TWRP step, TWRP said the device / file / partition is "busy." I had to reboot while holding the down volume button (OK, maybe I did have to Google for this step.) back into recovery / TWRP and then "wipe" again.
You have to explicitly put TWRP into sideload mode before doing the sideload. If I didn't, adb sideload complained.
You have to explicitly go back into TWRP sideload mode to load SU or whatever else after Lineage. I successfully rooted phone 5 at the same time as I installed Lineage.
Before I did the final reboot out of TWRP and into Lineage, TWRP warned me, "no OS installed," but that was a false alarm that could be ignored.
I found the hard way that unlocking the bootloader is necessary but not necessarily sufficient. The next problem is that you often get into "dm-verify" or bootloader "secure" or "signed" or some sort of encryption. The system won't let you install stuff that isn't cryptographically signed by the phone manufacturer.
With that said, we got some advice that needs to be on the project record:
If you search around a bit, its easy to find good Android phones with unlocked or easily unlockable bootloaders. Here is a site: Android.GadgetHacks...
Since you will flash "pure" Android locally compiled onto it -- it really doesn't matter if the carrier has touched it or not. The much bigger risk you are taking in your philosophy is that you are using Android which is written by Google.
My experience is that the carrier does matter, such as AT&T seemingly being infamous for the encryption / signature issue.
The person who gave us that advice had expert reason to be concerned about Android "being written by Google." However, I'm not so sure--we need to research this more. My old Coolpad Arise with Android 4.4.2 specifically said it was an Ubuntu kernel. I'm otherwise pretty sure that Android is a huge percentage pure Linux. So how much has Google done at the OS / kernel level? We don't know yet.
As of Feb 25, I have not looked at that list because I'm not sure it's relevant. I'll probably poke at it later, though.
You activate developer mode in Lineage the same way as Android. Under developer options, you can / have to tell Lineage it's ok to adb as root. Once that's activated, then you run "adb root" from Linux. Then you're root every time you "adb shell". As an update, I believe that resets with every reboot of the phone, so you have to do adb root relatively often. The opposite is "adb unroot" to adb shell as a standard (non-root) user.
So far, I have not found the "XT1103" model number from the Lineage GUI. So far, I have only found it with:
shamu:/ # getprop | grep sku [ro.boot.hardware.sku]: [XT1103]
I'm told that in the original Android before Lineage, that info was under "Regulatory Labels" or "Regulatory information." Republic Wireless says:
Tap Apps Tap Settings Tap About phone Tap Regulatory information Look for this model number: XT1103
at Republic Wireless "bring your own phone"
I noticed that the Wikipedia Nexus 6 entry says "Model XT1103 (Americas) / Model XT1100 (International)." I mention this because the exact model number is so important. I didn't occur to me that WikiP might verify the model.
This is the somewhat absurd command to get the IMEI from the adb shell / Android command prompt:
shamu:/ # service call iphonesubinfo 1 | awk -F "'" '{print $2}' | sed '1 d' | tr -d '.' | awk '{print}' ORS=
The Republic Wireless advice to "Tap Regulatory information" to confirm the XT1103 does not seem to work. Again, I haven't found the model number from the GUI / front end. With that said, sellers on Swappa seem to know to use the model number; perhaps it's on the original box. Note that "unlocked" as usually used by sellers is not wholly relevant to us. The sellers mean "network unlocked," not bootloader unlocked. Even if they meant bootloader unlocked, there is still the "verify" / encryption issue.
You may see this:
$ adb devices List of devices attached ABC22123 no permissions (user in plugdev group; are your udev rules wrong?); see [http://developer.android.com/tools/device.html]
In some contexts, this may mean you need to run on the desktop side as root / sudo-er. However, I believe more often you need to do this:
$ lsusb ... Bus 001 Device 026: ID 18d1:4ee7 Google Inc. ...
Create a file called something like: /etc/udev/rules.d/51-android.rules This will be a text file with the following content:
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee7", MODE="0660", GROUP="plugdev", SYMLINK+="android%n"
Where vendor and product come from the lsusb command.
After creating the rules file, unplug and replug the phone from the desktop (or laptop). There may be a 2 - 3 second delay before "$ adb devices" works. However, you may also get multiple entries. To clean up the mess:
$ adb kill-server $ adb devices List of devices attached * daemon not running; starting now at tcp:5037 * daemon started successfully ABC123 device
You can see the Linux permissions before and after you create the rules file:
$ lsusb $ ls -l /dev/bus/usb/001/030 crw-rw-r-- 1 root root 189, 29 Mar 13 20:31 /dev/bus/usb/001/030 The above is "before." When the phone is plugged back in, it probably gets a new device path, so do lsusb again: $ lsusb $ ls -l /dev/bus/usb/001/031 crw-rw---- 1 root plugdev 189, 30 Mar 13 20:33 /dev/bus/usb/001/031 $ groups adm cdrom sudo dip www-data plugdev lpadmin sambashare
The "groups" command makes sure your user is in the plugdev group. To add the user (substitute your actual user for [user]):
$ sudo usermod -a -G plugdev [user]
Thanks to Janos Gyerik for these plugdev instructions.
I have taken steps to activate cell service for phone #5. In the category of "nothing is ever simple" (Sword of Truth series and of course a broadly quoted concept), I had some strange "stuff" happen regarding the SIM card, the ICCID, and activation.
I was trying to activate with TING because TING is a la carte--I can pay something like $15 a month for a few minutes and few texts and a few MB. I'll I'm trying to do is prove that the phone works. First TING asks for the IMEI and then the SIM card number, aka the ICCID. The IMEI passed just fine, but it kept telling me that the ICCID was invalid both as a GSM and CDMA.
There is most certainly a SIM card in phone #5. However, one oddity is that the IMEI number is printed on it, not the ICCID. I am reasonably sure that the ICCID is not printed on it. Another oddity is that the ICCID didn't show up in any of the menus along with the IMEI. The phone gives mixed signals as to whether it reads the SIM. When I eject the SIM, it says "no SIM"; when I insert it, that message goes away. I found a shell command to get the ICCID:
shamu:/ # service call iphonesubinfo 11 | awk -F "'" '{print $2}' | sed '1 d' | tr -d '.' | awk '{print}' ORS=
That generated a 19 digit number. It seems ICCIDs are either 19 or 20 digits. The number started with 8901260, which is 89 for telecom industry, 01 for US, and 260 I believe was T-Mobile (probably through Republic Wireless). So it was, as best I could tell, a valid number.
In any event, I ordered a SIM card from Ting for $9.63 including shipping and taxes. The moral of the story is don't assume the existing SIM card will work even for a service that seems as flexible as Ting does.
Ting referrals: it looks like Ting gives you a $25 credit if a current Ting user refers you (send you a link with their referral code), and the current Ting user may get $50. We need to remember this.
Ting worked just fine with the new SIM card. The process was easy. It's working too well in that I'm getting voicemails and texts from a previous phone number's "owner," though. I wonder how long the number I got was inactive?
Ting offers both GSM and CDMA. I'm using Sprint CDMA / 4G LTE.
I had some interesting results when I started pinging this web site from Ting / Sprint. First I realized I needed to take my own advice on Orbot indicators and turn it off so that I could take TOR out of the equation. Those pings were something like 4s as in 4 whole seconds or 4,000ms.
Then my first few pings without TOR were still around 1s. When I took 2 minutes to get my pre-Lineage T-Mobible CDMA / 4G LTE phone, the Sprint pings went way down. This makes sense as the network "learns" a path to kwynn.com. When I put the phones next to each other and pinged at the same time, I got Sprint min / avg / max: 80 187 405. 405 was the first time, which is typical that the first time is slowest. I got T-Mobile 84 / 112 /145.
Next batch Sprint: 138 / 170 / 242. T-Mobile: 73 / 110 / 337.
The referrals worked just fine. I asked a friend who uses Ting for a referral code, and it did indeed give me a $25 credit. I know my friends got a credit, but they didn't confirm $50.
GSConnect (writeup) allows one to connect a phone wirelessly to Ubuntu Linux in order to use the desktop to type on the phone and such, and presumably see the phone display on the desktop. I have NOT looked into it yet, but I may.
I was telling a friend about this project. He has an engineering master's degree, and he's in his early-to-mid 70s, but he's in very good physical and mental shape. He's reasonably computer literate. I'm going to quote a bit because it may add to the "to do" list, as I'll explain:
It sounds like work is "OK," but could be better $$$. I followed the link in your third email [this page] and found it way, way over my head! That project should bring in a good bit of money based in complexity alone.
Seems like we may need to explain this project better and be far more encouraging to readers. I would imagine he could install Lineage if he were motivated. And, of course, if he had the right phone. I use "we" again in this case because I'm not certain I'm the one to explain it better. This all bears some thought.
Signal. To check the certificate: APKs are ZIP files, although the Ubuntu / Gnome file manager doesn't recogize that for "extract here." So I copied the file, renamed it to blah.ZIP, unzipped it, and then:
cd META-INF keytool -printcert -file SIGNAL_S.RSA
META-INF is what the ZIP file unzips to. The output of keytool matches what is on the Signal site. Then:
jarsigner -verbose -verify Signal-website-release-4.34.8.apk
That verifies the ZIP file against the RSA file. There are some warnings, but given the chain of evidence, I'm not worried about them.
And then:
adb install Signal-website-release-4.34.8.apk
And there is Signal on the phone! Woo-hoo!
Signal did update itself days after I installed it from Signal's site. You have to give permission for the app to update itself, though. It asked for that permission as a notification--an active update request as opposed to passive.
First, a list of relevant sites:
Then I cross referenced the Orbot and Orfox Google Play Store entries with the versions on the raw download page. In the Play Store entry, under "READ MORE," after the first few reviews, you'll see the latest version. Orfox requires Orbot.
Phone 5 is "armeabi-v7a" compatible. My reading indicates that the adb shell command "cat /proc/cpuinfo" shows "thumbs," which means it's armeabi compatible. As for the exact version (v7a), appearntly it's compatible because the app works.
F-Droid is a comptetitor to the Google Play Store for FOSS (free and open source software). It looks like I could have installed Orfox and Orbot through F-Droid. The Guardian Project recommends F-Droid. You can install F-Droid and browse / search installable apps.
You can download an app / APK from a site such as Signal's. Then go to "Files" and click / double click the APK. You'll be asked to give permission to install apps from the browser. Then you can install. I haven't figured out how to revoke that access, though--to install from the browser.
To avoid the Play Store, you can use a "sacrificial" phone to get apps from the Play Store, then you pull them, as below. You do NOT need a rooted phone to pull apps.
$ adb shell pm list packages
That gets you the technical / precise name. Use that:
$ adb shell pm path com.audible.application
That gets you the path used next:
$ adb pull /data/app/com.audible.application-EkICVPUZ9PFv3CdKnynANA==/base.apk
You then may want to carefully rename "base.apk" for your archives. Then you can copy to the phone and "double click" / tap on the app in the Android File(s) manager or "adb install" as shown above.
I hereby open my APK library with APKs I've "pulled."
Lineage will prompt / notify you with Lineage updates. That is, it will within the same Lineage major point version--Lineage 15.1-201902... will notify you to update to 15.1-201903... I don't think it will go to 16, however, even though 16 has been released. I believe 16 was released in the last few weeks. Lineage 15.1-2019... is based on Android 8.1.0. I don't know what 16 is built on. I know this because the versions are under "Settings / System / About phone."
Orbot is the whole-phone-level equivalent of a TOR VPN. In other words, it's not just the equivalent of the TOR browswer but it routes all phone traffic through the TOR network. I find its status-indication symbols somewhat confusing. To, to clarify: if Orbot is installed (and running, by default), you see the onion symbol in the top left. However, for all-traffic, you need to see the key symbol in the upper-right. Also, to know that Orbot is all-traffic, you can go to Settings -> Network / VPN, and you'll either see Orbot or "None."
Orfox won't connect at all if Orbot isn't running. Orfox will only use Orbot even if Orbot is not in whole-phone VPN mode.
Meanwhile, the Protonmail app will work "in the clear." So, for privacy, make sure you see the VPN key symbol before starting Protonmail.
Protonmail seemed very, very slow the first time, and then it sped up, but it's still sometimes slow. The VPN slows things down; I'm not blaming Protonmail.
You can confirm your VPN status by checking your IP address and using a "whois" service. You should find that your IP is not from your ISP. Perhaps I'll elaborate on this later.
Yes, Amazon is showing their evil side in the last few days (as of March 16, 2019), and QAnon tells us that Amazon was a CIA project from the start.
With that said, I'm not ready to break up with Amazon yet. I wanted to see how its software works on Lineage.
First of all, you do have to sign into Amazon to use their app store. That's all the more reason to use F-Droid and install from the creator and install from pull.
I had some problem with the "install app from 'disk' / unknown sources" process the first time. I don't think that had anything to do with Amazon. It was simply using that process the first time. I seemed to get stuck in an infinite loop between giving permission and the app waiting for permission. The two screens--need permission and give permission--kept stacking instead of exiting. I don't remember exactly what I did to resolve this. I might have rebooted, 1980s style. Seems like I did more mucking about. The point being that the first time may give you some trouble, but it will work.
Then the Amazon Audible app works just fine on Lineage.
I had some trouble seeing the Audible data directory at first. Downloading a book may or may not have been enough. I think it's a known problem that sometimes you don't see new directories before you reboot. (Then again, the problem may have been in my head. I mention the possibility of a problem, though, in case it helps anyone.)
FYI, once you can see the Audible directory, from the Linux (desktop) file manager, it's Nexus 6 / Internal shared storage / Android / data / com.audible.application / files. You can copy books that you own to that directory rather than download them. You may have to kill ("force stop") the Audible app for Audible to see the new book, though. You do not need (phone) root access to see those app data directories from desktop Linux.
From the adb / phone / Android command line, the directory is /mnt/user/0/primary/Android/data/com.audible.application/files You DO need root to get beyond '/0'.
Under "Settings / Connected devices / USB," you can tap on "USB" to switch the USB connection from adb mode to "Transfer files" / show up in Linux desktop file manager. ADB isn't explicitly a mode under USB. The screen simply shows "Charging this device" when the USB connection is in adb mode.
The question was about the possibility of forking Android. The only reason we'd do that is if we discovered that Android "proper"--the OS itself--had (terms of use / user approved) spyware. That question is of course up in the air.
There is a mid-Feb list above.
I would hope there is useful info on my original page from January, 2019.
For the moment, the source will remain anyonymous, but regarding this project:
I love this idea. This sounds like an amazing idea. I guarantee there is a market here. I am totally onboard. When you get further details let me know. I am VERY interested.
I'm the one actively running with this project. I'm writing these pages, but I didn't start the project, and it's not only my project. There are others involved, and that's all I'll say about that for now. I mention this because it annoys me when people use a fictitious "we."