| Selection | Checkout | Setup | Apps | More Info | Top |
Stealan APK File
Pairing with other cellphone: Worked for transferring data from the old phone to the new one (though other issues prevented the data from being used).
Pairing with Xena (Linux laptop): Works. Procedure: Make Selen
(cellphone) discoverable. Start the setup wizard on Xena. Xena
shows a random number, Selen shows the same number. Click on
Pair
on both devices (if the number is the same).
OBEX push: Selen does not have an OBEX server unless you install
an app that includes one; I'm using
Bluetooth File Transfer
(it.medieval.blueftp). From the phone, Share via
Bluetooth
. The laptop will pop a dialog asking if you want to
accept the transfer. The file lands in the laptop's preconfigured
download directory and a completion notice pops up. From the
laptop use Blueman's OBEX client. Similarly the phone will pop
a notification asking if you want to accept. The file lands in
/sdcard/bluetooth and there's another notification when it
finishes. Bluetooth file transfers are a lot slower than SCP
or equivalent over Wi-Fi.
Pairing with Think Outside
keyboard: Works. The HID and
the onscreen keyboard keycode (or keysym?) streams are merged so
you can use both within the same app (editor) session.
Procedure to pair: Unfold the keyboard. Press Ctrl-Green-Blue (at
the same time) until
the keyboard's green light blinks (near the T key).
Tell Selen to scan for devices. When the keyboard appears,
click its line item. Selen pops a box, type a sequence of
numbers (4 is known to work, probably more is OK) and hit Pair.
Then type the same numbers on the keyboard (use blue Fn key to
get numbers) and press enter. It will pair.
Pairing with 66 BT Sport headphone: Works. Procedure: Hold down the headphone's call control button until you get the turn-on beep and keep holding another 5 secs or so until it gives a double beep at a lower pitch. It is now discoverable. On the cellphone, hit Scan For Devices. The headphone will first appear as just the MAC address, but soon the brand name and device class will be discovered. Click on its line item. It will pair with no further user interaction.
When you turn off the headphone it is easy to accidentally initiate a call to your most recent voice chat partner (embarrassing). To avoid this, use the settings for the headphone to suppress using HSP/HFP, only A2DP (audio).
HSP-HFP with 66 BT Sport: Works, and HFP (call control button) is obeyed. It will pause music that is playing at the time.
A2DP audio quality: Adequate. Comparing the same headphone
(evaluated with a Motorola HT820) doing Bluetooth A2DP vs. wired
(3.5mm jack), the wired quality is noticeably better. A similar
difference is seen on Android-1.5 Cupcake
, Android-2.2
Froyo
, and Linux bluez-4.88, suggesting that the problem is
in the headphone or the A2DP algorithm. It's hard to be sure what
the difference is, but I have the impression that the sub-bands in
the midrange are not getting matched up perfectly by the headphone.
There is a new amendment to the A2DP specification: other codecs can be negotiated beyond the sub-band codec, including MP3 and MPEG-4 (audio only of course). It's hard to tell if CM12 or the 66 BT Sport are using these codecs, but the sound quality does seem better than before.
If your cellular signal is poor, more power is needed to talk to the tower, and when the signal drops out the phone has to scan for another tower. My HTC Dream could only do this for about 6 hours before emptying the battery. Cure: fire the weasels and get a mobile operator that gives you a decent signal. If you're temporarily in a location with poor or no cellular signal (like an airplane), put the device in airplane mode, or at least shut off the cell radio (if you want to use Wi-Fi).
If you are away from your home or work Wi-Fi, the phone has to scan frequently for a Wi-Fi provider that it's allowed to connect to. Running the radio frequently and for a long time on each try eats battery. Cure: turn off Wi-Fi when you know there's no service. In CyanogenMod, flick down the status bar and you will find a control icon for Wi-Fi, which you click on. A long press will open the corresponding Settings page.
If you do location-based social networking, it needs to determine your location frequently. Cure: turn off GPS until you need it for map navigation or for finding a specific person. Use your status bar control icon. The position inferred from cell towers should be good enough for many purposes, e.g. picking a restaurant.
If you are inside a building of steel and concrete construction, which blocks the signal of the satellites, the phone will run the GPS for a long time before giving up, repeating each time your location is needed. Steel and concrete also reduce your cellular signal. Cure: turn off GPS until you are under clear sky. Turn on airplane mode if your cellular signal is uselessly low.
With a LED (AMOLED) display it takes zero power to show a black pixel, and so you should use a theme with a dark background. But the power is independent of the color with a light valve (backlit) display like the Pioneer has, or with a transflective display.
Turn down the display brightness. If you have an ambient light sensor, use it to automatically reduce the display brightness indoors (and brighten it outdoors).
Some web pages have active and expensive client-side scripting; for example I ran into one with animated snowflakes that pegged my CPU. Cure: load a more friendly page, and beg Google for a browser setting to suppress client-side scripting.
Apps with push notification have to keep the CPU and radio active all the time to receive the notifications, which uses significant battery power. Mitigations in the apps vary in effectiveness. If you aren't going to respond to the notifications, e.g. at work, you should turn them off. If the app doesn't have a convenient control for this, you could force-close it. App categories that are likely to do push notification are mail readers, social networking, and VoIP (for receiving incoming calls).
DUN is the acronym for Dial-Up Networking, a Bluetooth profile (higher level protocol) for making a point-to-point network link between paired Bluetooth peers. Dialing, as in PSTN, is not a required component. Typically one peer is a general purpose portable computer (laptop or cellphone) and the other is some kind of network router or a modem, which in the old days would connect to another remote peer over PSTN by dialing.
A cellphone, like the Pioneer, can make its cellular data uplink available
to its peers over Wi-Fi (or Bluetooth); the feature is called
tethering
or a Wi-Fi Hotspot
. But after upgrading from
Android-9 Pie
to Android-10 Quiche
, quite a number of users
with various equipment complained that their hotspot feature stopped
working. Including jimc. A key symptom on the phone is a small X in the
lower right corner of the mobile data bar triangle. This means that data
transport is interdicted by something. As seen on the peer (laptop),
it connects to the phone, but cannot connect to the Internet. The most
likely step to produce an error message is DNS resolution: We're having
trouble finding that site…
This
forum thread titled After updating to Android 10, Wi-Fi hotspot feature
has no internet connectivity
(OP Justin Piggott, 2019-04-09 or
2019-09-04, on support.google.com/pixelphone) describes the problem and
a working solution. Respondent Rayan Aravinda Jayakody says: Under
Modifica Punto di Accesso (Edit Access Point) tab, to APN Type
add ",DUN". For him: Tipo APN = default,mms,DUN . This solution is
confirmed by a lot of users, at least 10.
Jimc says: the full path is Settings - Network & Internet - Mobile Network - Advanced - Access Point Names - Click on the one that you're already using (for me, T-Mobile US LTE) - you get to Edit Access Point. APN Type (near the bottom) says (for me) default,supl,mms,ia . To fix the problem, add ,DUN. I can't tell if it's case sensitive; I avoided tempting fate. (Update: 'dun' was accepted.) Then put the phone in airplane mode, or otherwise shut off cellular data, and then turn it back on. The X is gone from the mobile data bars, pinging a known IPv4 address gets replies both on the phone and on the client (laptop), and the client can use the Internet normally.
I've found that this setting is volatile: an unknown event can revert it to the default — possibly rebooting the phone.
Jimc has no idea why a Bluetooth profile has anything to do with Wi-Fi, nor why the cellular data access point cares about it, nor why the phone's routing infrastructure takes any notice of the feature codes being passed to the APN.
The Wi-Fi driver for the Pioneer can be put into master mode, allowing your pocket computer to act as a Wi-Fi access point. In documentation this is referred to as Wi-Fi Tethering, or as a Wi-Fi Hotspot. Check your cell plan's terms of service carefully to determine if you need to pay extra to do this.
See the previous section about DUN for a prerequisite.
You need to configure it: Settings - Network & Internet - Hotspot & Tethering - WiFi Hotspot. Tell it the SSID (name), access control type (open, WPA PSK, WPA2 PSK, which is recommended), and the pre-shared key (password). It can turn off if unused (make it stay on). Choose the 2.4GHz or 5GHz ISM band. It does not broadcast its SSID so the client doesn't show it when scanning. Configure the same parameters in the client, and it will be able to connect. Nowhere do you specify the channel or the IP range; for me it used 192.168.43.x (RFC 1918). Nor does it ask for the DNS server; presumably it's using the carrier's server, though I have my own recursive DNS server with DNSSEC enabled.
Normally with the Wi-Fi hotspot you want client traffic to exit via the cellphone's mobile data (cellular) connection. But the Pioneer can do master mode with a client at the same time that it's doing managed mode with a nearby Wi-Fi access point. If this is going to cause confusion, e.g. for VPN testing, you need to turn off Wi-Fi in the cellphone. Not all phones can do master and managed mode simultaneously.
It uses IPv4; it doesn't give the client an IPv6 address.
Bad news: at some point at or after the upgrade to LOS-17.1 (Android-10), the hotspot has started misbehaving. The same set of symptoms is seen on a variety of hardware and on various vendors' stock images as well as LOS. Specifically:
LTEnext to the mobile signal level bars. It may take a few seconds to get logged in. LTE is not required; it fails equally on HSPA (code H or H+) and Edge (E).
As a wild attempt, I activated USB networking, but it didn't help. To turn it on: connect the USB cable from the phone to the laptop, first. Settings - Network & Internet - Hotspot & Tethering - USB Tethering (it's greyed out if no connected client). Turn on. Behavior was the same as for the Wi-Fi hotspot, i.e. no default route.
Tidbit: the Pioneer has two Wi-Fi radios with different MAC addresses
(locally administered
). The dual radios probably are why it's
able to do master and managed mode simultaneously. In the transition to
Android-10 it swapped the one used for the default route, with baleful
consequences in my firewall and with fixed IP assignments via DHCP.
The unlock procedure wipes the phone. Does that include the SD card? The Sony instructions say it doesn't, but for paranoia I'm going to remove my card. Easier said than done.
Turn off power, hold the phone with the back up, and remove the cover over the slots, to which the SIM tray is attached. It's at an upper corner of the phone on the side opposite the power button. The SIM sits in its tray by gravity, contacts up. Be careful not to drop and lose it.
Various forum postings and help pages give a variety of methods to remove the SD card, obviously describing different models, none of which are the Pioneer.
The SD card is in a tray like the SIM. Scotch tape on the contact side won't hold, and now I see why: behind the outside wall is a void space where you could get traction with a fingernail. Maybe the tape would have grabbed if placed on the other side between the tray and the identifying numbers card, but that's not what I did. No, I tried that later, and couldn't get the tape into the gap.
My fingernail wouldn't reach, and instead I used a micro screwdriver to
coax out the tray. But the plastic of the front wall is thin,
and the therapeutic index
between effective and destructive is
small.
How to Enable Split Screen on Android Pie? by Steve Kelly (2019-06-13). First (so he says) you need to turn on gestures: Settings - System - Gestures - Swipe up on home button (turn on). The result is that the formerly round home button changes to a sausage, and the square history button vanishes. A big swipe upward from the bottom opens the app drawer (as it used to) and a quarter height swipe starting on the home button opens the history list. The author says you have to enable gestures to do split screen, but I'll bet it's optional, assuming your launcher (Trebuchet in LineageOS) gives you a history button. Update: I confirmed that it's optional.
Now for split screen:
I haven't noticed this for years: to turn on the speakerphone, make a call, and when it starts dialing and during the call, the screen will include an icon of a speaker. Hit it, to toggle the speakerphone feature on or off.
There's also an icon of a microphone, which is the mute button.
Formerly I never found a way to remove a user or CA certificate,
e.g. if expired. Click on Settings - Security & Location - Encryption
& Credentials. Turn to User Credentials and click on one of the items.
Click on Remove to remove it. Apparently the item
is a set including
what came out of a PKCS#12 file, in my case a key, the user cert, and one CA
cert; I don't know why the intermediate cert is not listed. Is this CA cert
sufficient for authenticating a TLS connection to a host whose host cert is
signed by that CA, without separately installing the local CA cert? I suspect
it isn't.
When Firefox opens
a CA certificate or a PKCS#12 file (with a user
key, certificate and trust chain), it stores the resulting content in its own
trust storage and never uses the system trust storage. To get credentials into
system storage, use curl, AndFTP, etc. to download a DER or PKCS#12 file
somewhere on your internal flash (or SD card? not tested), then open Settings -
Security & Location - Encryption & Credentials - Install From SD Card.
Navigate to and select the file you downloaded. Give it a friendly name
that's short but that uniquely identifies the subject, and end with the
expiration year.
Tidbit: adb shell bu help -- command is "backup". Output file is on command line. You can include APKs or omit (default). Also restore, of course.
How to control Phase Beam live wallpaper: Settings - System - Developer Options - Running Services - Y.a.PhaseBeam (find and click on the app's line item) - Settings. However, this takes you to a choice of wallpaper selection apps: Wallpapers (icon of mountain), Wallpapers (icon of flower), Live Wallpapers (icon of mountain snowing), Gallery (I suppose the icon is mountainous). The product page on Play Store shows alternate colors, but I haven't found yet how to configure them.
How to create a QR code with your Wi-Fi SSID and password: Generate the code using QR Code Generator by Ykart. It has a format for Wi-Fi setup. (Include Ykart in the search terms; at least one similarly named app lacks the Wi-Fi data type.) Either save the resulting PNG file on your phone and/or print it out. To use it, an iPhone with iOS 11 can take a photo, and the camera app will recognize the content and feed it to the Wi-Fi settings app. On Android, use a scanner app; the author recommends QR Scanner by Kaspersky, and Barcode Scanner works for me. I've seen a mention that the AOSP camera app can also recognize QR codes and can dispatch the payload according to its mime-type. but it didn't work for me.
Stealan APK File
There's a very old game called Lexic
from Android-2 that nobody
under 60 would be caught dead playing, and that has vanished from the Play
Store. It's installed on the old phone and I would like to install it on the
new one.
See this
forum post on StackExchange, OP kBisla (2014-07-02, old).
Suggestions: install Android assistant
which can do this.
Also ES File Explorer.
Respondent L.D. James (2014-07-03) gives the most useful suggestions (so says
jimc). The key item is:
Connect the USB cable for ADB debugging on the old phone.
adb shell pm list packages -f | grep lexic
Found it, the output is:
package:/data/app/net.healeys.lexic-1/base.apk=net.healeys.lexic
The following has changed since 2014; use adb pull
to retrieve
the APK file into your directory on the host (line folded for readibility):
adb pull /data/app/net.healeys.lexic-1/base.apk \
bkupdir/net.healeys.lexic-1.apk
Got it, 273Kb
Connect the USB cable for ADB debugging on the new phone, then install
the stolen APK file:
adb install bkupdir/net.healeys.lexic-1.apk
It's installed, it works, except for an annoying message when you launch it about a back version ABI, which might kill a more sophisticated program, but this one avoids using non-backward-compatible features.
The VPNs (see the next section) have an issue with
DNS which I hope to solve by overriding the DHCP provider's DNS server.
However, non-rooted Android since version 9 Pie
does this by letting
you specify an overriding DoT server. Which therefore has to be able to do
DoT. Which I therefore need to set up. The details are off topic, but here
is a brief summary:
On my directory servers I created a separate instance of Unbound configured for DoT. While the documentation of the configuration file seems to imply that one instance can do all of DoT, TCP and UDP (standardly on ports 853 and 53 respectively), I tried hard but failed to get this to work; I could do one or the other. Similarly I need separate instances for the recursive and authoritative servers: in theory I can be authoritative for the internal LAN and recursive (with DNSSEC if requested) for everything else, but to serve SSHFP I need DNSSEC, which it can't or won't do for a zone for which it is authoritative. So I have three instances of Unbound on each directory server.
dig
cannot do DoT, and I was not able to locate any other
such tester program with DoT. So I wrote my own. With Perl's
Net::DNS::TLS this should have been easy, but the key item that I
missed was, when sending via TCP including DoT, the DNS protocol packet
must be preceeded by its length as a 16bit int in network byte order,
whereas when sending via UDP the length is not wanted.
To my collection of service test scripts I added one for DoT that calls the above program. The tests are identical for the recursive resolver, the authoritative server and DoT, and I have one tester that just switches ports, socket classes and protocols according to which one is being tested. (It can also test named.) The tests are:
Arecord for the host running the test, on each port, looking for the IP extracted from /etc/hosts?
To make Android-9 Pie
or newer use DoT, navigate to Settings
- Network & Internet - Advanced - Private DNS. My first attempt
was to select Private; I gave it the hostname of the server, using a
SAN which is certified by the cert which the DNS server will proffer.
This worked for public servers like Cloudflare's
1dot1dot1dot1.cloudflare-dns.com. However with my server it
couldn't connect
, because it would not believe in my LAN's root
cert: It's installed as a user cert, see Settings - Security -
Encryption & Credentials - Install From SD Card, and then Trusted
Credentials, User tab. I succeeded by switching to my publicly
certified (letsencrypt.org) domain name and server host cert.
A functioning alternative is to set Private DNS to Automatic (which
is the out-of-the-box default). I'm not sure which server is used (it
doesn't say), but forum posts suggest that it's either Cloudflare or
Google's 8.8.8.8. In this
Google help writeup they say that in Automatic mode Android's DNS
service will try DoT to the DHCP-provided DNS server IP on port 853 and
on failure will fall back to UDP on port 53. Clearly the Android
device does not know the name of the DNS server and so its
cert cannot be checked. This behavior is consistent with what I
observe, using my local LAN cert on the DNS server. (Is
consistent
means that I didn't observe any behaviors inconsistent
with this scenario, not that the scenario is confirmed.)
How to get StrongSwan (IPSec) to connect:
Conclusion: with Private DNS set to either off or Automatic, most HTTP traffic eventually connected, with these exceptions and issues:
Tidbit: This blog post by Enno Rey (2015-05-09) about IPv6 Router Advertisement flags and other configuration conflicts has a link to a paper documenting empirical tests of how various (ancient) OS versions react to various IPv6 configuration possibilities.
In a
blog post by Joe Nefille (2018-11-13) about DHCPv6 on Android he gives a
link to an issue on Google's bug tracker in which a zillion people over many
years have asked for DHCPv6 and Google has finally sawed it off with a
won't fix
judgment.
A report on acquiring and setting up the new phone may seem like a strange place to record results of maintenance on CouchNet's VPNs, but whenever I get a new phone it's always traumatic to get it talking to the VPNs, particularly since I've forgotten what I did however many years ago, and this looks like a good and findable place to record the process.
I'm not doing National Security stuff, or the business equivalent, but
when I communicate from off-site to home, specifically from the new pocket
computer (phone), I often need normal
access to the local LAN, while
avoiding to offer such access to the global hacking community. I'm also
using communication facilities that I cannot audit for security, e.g. at
airports, but that I can reasonably expect are infested by or in collusion
with hackers, so my communication method needs to protect privacy and
integrity (injection of tampered traffic).
CouchNet has a total of four VPNs, as follows:
IPSec: Technically it uses deeply embedded features of the kernel to do crypto. The IPv6 protocol includes IPSec support intrinsically; in fact IPSec was developed for IPv6 and later was backported to IPv4. With StrongSwan for Linux on the server, desktop and Android phone, it appears to be competently designed and to provide good security, useability and availabiity, once correctly set up.
On the payload packets, IPSec is just another layer of mangling, and whatever net interface the encrypted packets come in on, the same packet turns into a payload, having arrived from the same interface. This distinction is not visible to the user, but is important for setting up the firewall.
IPSec does require IKE (key management) on port 500/udp or (with NAT) 4500/udp, and on IPv4 it needs ESP (protocol 50) for the payloads, and a majority of public Wi-Fi nets block all of these. Actually they block everything except a very short list of ports such as 53, 80, 443 and occasionally 587.
OpenVPN on port 1194/udp: This is another widely used and well-regarded VPN service. Crypto is all done in user space. Unlike IPSec, OpenVPN uses a tunnel device for decrypted incoming packets, as well as outgoing ones. Since there are more moving parts it probably uses more CPU per packet than IPSec, though it's hard to get objective evidence for this and I will never have enough network traffic that CPU efficiency would be significant.
TCP/IP expects that if a packet goes out, either the peer will receive it or the loss will be noticed and acted upon as a fatal error. It's a fact of life that packets get trashed, so TCP/IP has a reliability layer so non-received packets can be retransmitted. Of course there are limits, and the connecton will collapse if too many packets are lost. In its normal UDP operating mode, OpenVPN (and IPsec) sends bearer channel packets unreliably. It expects that the client's TCP reliability layer will retransmit any lost packets. For key management, OpenVPN also multiplexes a TLS stream over the bearer channel, and this stream has its own reliability layer provided by OpenVPN.
Like IPSec, OpenVPN's port is very often blocked by unfriendly public networks.
OpenVPN on port 443/tcp: This uses a TLS stream (TCP/IP) as the bearer channel, and encryption is handled by the SSL/TLS libraries. Setup and operation is otherwise mostly the same as for OpenVPN on UDP. OpenVPN can be configured to recognize a TCP connection with a foreign fourth layer protocol, which on 443 would be HTTPS, and to divert it to a different server program, like your webserver.
Public Wi-Fi networks would be useless if they blocked port 443/tcp, so it's guaranteed that this VPN connection can go through. In a repressive regime the Network Police can do packet inspection, can recognize non-HTTPS traffic (just like OpenVPN does), and can mount an unpleasant response, but that is not the kind of threat I am trying to evade. My issue is with airport or hotel Wi-Fi with a cheap router that is set to block everything that the hotel staff has never heard of.
A serious problem with any tunnel over TCP, including OpenVPN on 443, is the dreaded TCP Meltdown syndrome. When a packet is lost, both the bearer channel and the client's TCP reliability layer will ask for it to be retransmitted (the bearer channel pushes another copy of the encrypted packet while the client resends the unencrypted packet). It's easy to calculate that if more than half the packets get lost, the number of retransmissions will diverge without limit. Fortunately such an awful net connection is rare, and a VPN that works except for occasional meltdowns is a lot better than one that doesn't work at all because it's blocked.
OpenVPN on port 4294/udp: One of the CouchNet machines is a cloud server (560km north of the rest of the net). It has a place on the internal net via a separate OpenVPN link, which the phone does not interact with. See A Server in the Clouds (2019-01-31) for what it does and why.
So what is the current state of the VPNs; are they working?
genericpeer is Holly, a Raspberry Pi as a desktop replacement.
| Client | Wi-Fi AP | VPN | Generic | Websvr | Gateway | Cloud | Outcome |
|---|---|---|---|---|---|---|---|
| Phone | Jacinth | No VPN | IPv4 | Claude6 | IPv6 | IPv4 | OK |
| Phone | Jacinth | IPSec | IPv4 | Claude6 | IPv6 | IPv4 | OK |
| Phone | Jacinth | OpenVPN | IPv4* | Claude6* | IPv6! | IPv4! | Bypass* |
| Phone | Jacinth | OV 443 | IPv4* | Claude6* | IPv6* | IPv4! | Bypass* |
| Phone | Cell | No VPN | DNS | Claude6* | Claude/4 | Claude/6 | OK |
| Phone | Cell | IPSec | DNS# | IPv6 | DNS# | DNS# | Wild side DNS |
| Phone | Cell | OpenVPN | IPv6 | IPv6 | IPv6 | IPv6 | OK |
| Phone | Cell | OV 443 | Claude6 | Claude6 | Claude6 | Claude6 | OK |
| Laptop | Jacinth | No VPN | IPv6 | IPv6 | IPv6% | Claude/6 | OK |
| Laptop | Jacinth | IPSec | IPv6 | Claude/6 | IPv6$ | Claude/4 | OK |
| Laptop | Jacinth | OpenVPN | IPv6* | IPv6* | IPv6*$ | IPv6* | |
| Laptop | Jacinth | OV 443 | IPv6* | IPv6* | IPv6*$ | IPv6* | |
| In this section the phone is on cellular data with no VPN. Unfortunately the test could not be finished because the Wi-Fi Hotspot feature flaked out. | |||||||
| Laptop | Phone | No VPN | TO | TO | TO | TO | OK |
| Laptop | Phone | IPSec | TO | TO | TO | TO | No transport |
| Laptop | Phone | OpenVPN | |||||
| Laptop | Phone | OV 443 | |||||
| In this section the phone is on cellular data, the laptop uses no VPN, but the phone uses the indicated VPN. | |||||||
| Laptop | Phone | No VPN | |||||
| Laptop | Phone | IPSec | |||||
| Laptop | Phone | OpenVPN | |||||
| Laptop | Phone | OV 443 | |||||
Overall outcome: No fault is seen in the VPN apps on the phone. But other issues make the outcome less than perfect. Particularly, the problem with the Wi-Fi Hotspot really prevents an important use case. Another problem, that I've had in all previous versions, is that the server's DNS server suggestions are not honored, particularly with IPSec, and to set the DNS server manually requires root access.
Tidbit from The Droid Review
(no author, 2015-03-17). This article is a bundle of three tricks for avoiding
net restrictions. They don't say the Android version, but per the date,
Android-5 Lollipop
was then the current version. Their instructions:
Settings - Wi-Fi Options - (long press on network name/SSID) - Modify Network - Advanced. Change IP Settings to Static. Fill in the DNs server's IP in DNS1, and optionally a fallback in DNS2. Hit save. Disconnect from that network and reconnect.
How it works on LOS-17.1 (Android-10) as of 2020-05-14: Settings - Network & Internet - Wi-Fi - hit gear icon - Advanced - Well, it will tell you your DNS server, but doesn't let you change it. Also, this is for Wi-Fi, not cellular data, for which you also may need to override DNS.
Another method: Settings - Network & Internet - Advanced - Private DNS -
select Private, enter hostname. You have to do this when you're capable of
resolving that hostname to an IP address: suggestion, turn Private DNS off
before setting or changing the hostname. Private
DNS means DNS over
TLS on port 853/tcp, and the correct hostname is required for Server Name
Indication; the IP will not do, and Android will reject it. Its main
attraction for users is that snoopers cannot tell which hostnames you are
trying to connect to.
| Selection | Testing | Setup | Apps | More Info | Top |