These file path variables can be set at the very start, OrbotApp.onCreate()
and they will not change during the lifetime of the app, so represent them
as globally accessible static variables. This is needed for things like
OrbotMainActivity detecting whether the tor daemon is still running, even
though TorService is not.
If OrbotMainActivity gets killed while TorService is running, then when
OrbotMainActivity starts again, it needs to get the current status from
TorService to correctly represent things to the user.
The very first place that the whole tor start sequence starts is from
TorService's onCreate(), so that is where STATUS_STARTING should be
announced from. The open question is whether Intents besides ACTION_START
ever cause TorService to start. In theory, TorService should already be
running when any Intent is sent besides ACTION_START.
Before, it was announcing tor was started when it had completed starting
the daemons. But that does not guarantee that Tor is actually connected
and working. So instead, this waits for the first circuit to be built,
then announces Tor is ON.
In order to receive a targeted reply, an app has to send its packageName to
Orbot as an String extra in an ACTION_START Intent. Also, when Orbot
internally uses ACTION_START, it shouldn't receive replies.
This sets an action for each kind of local broadcast, and uses the action
to choose how to handle it. Before, it was a mix of the action and which
extras the Intent included.
The tor daemon supports both "SIGNAL HUP" via its control port or the UNIX
signal `kill -HUP` via the terminal as a way to trigger the tor daemon to
reload its config. This is needed for new bridges and hidden services. It
is not necessary to restart everything to add those.
https://stem.torproject.org/faq.html#how-do-i-reload-my-torrc
Since running stopService() automatically triggers Service.onDestroy(),
there is a nice way to hook in and run the shutdown procedure. This
provides an obvious point of entry as well as simplifying the shutdown
procedure.
In order for apps to follow the current state of Tor, this broadcasts the
state both locally, since global broadcasts are insecure, and globally, for
any app to receive. The internal workings of Orbot need to use a local
broadcast, otherwise any app could trigger stop, start, etc or DoS in other
ways.
In order to send reliable information to any app using Tor, Orbot itself
needs reliable state broadcasts. Before, there the ON/OFF/STARTING state
were being set multiple times during the process, and sometimes not even in
a useful order (i.e. STARTING ON STARTING ON ON).
This reworks the start/stop procedure into startTor() and stopTor().
As of android-9, java.io.File has native methods for setting permissions,
inherited from Java 1.6. Using these will help deal with compatibility
across devices, since some devices might not have chmod installed.
The code was using global variables that were refreshed from the prefs on
certain occasions. That means that the global vars could easily get out of
sync with the actual values. Instead, just read the prefs directly when
the values are needed, and they will always be up-to-date.
Following the Android system naming convention, this uses constants for
the action and extra names for Intents. This makes it much easier to track
which "log" is which, since there are "log" actions, extras, and messages.
There are a couple of different times when Orbot will be unable to kill the
running processes. One example is when Orbot is running, then uninstalled,
then installed again.
closes#5254https://dev.guardianproject.info/issues/5254
- If you paste bridge addresses from Gmail, you get some strange
characters that were causing problems. This looks for that, and
other formatting related gotchas.
- This also moves all configuratino to the torrc.custom file
instead of using the control port. These changes require you to
restart anyhow, and using the torrc.custom is more reliable as it
affects the tor process on launch, and not post control port interaction.
We now refresh the VPN and tun2socks interfaces when the network
type switches, and we do so in a way that does not cause traffic to leak.
The new interface is established before we close the old one.
You can use Bridges with VPN "App Mode" proxying
On Pre-Lollipop this uses a local loop back SOCKS server to flag outbound sockets as not for the VPN network
On Lollipop+ this uses the "disallow app" feature to set anything in the Orbot process to not be sent through the VPN
Nathan Freitas
Hans-Christoph Steiner