Tor's DNS port doesn't work well with the VPN mode, so we
will use PDSND to resolve DNS over Tor using OpenDNS. This is
a hack/solution that we learned from SocksDroid.
If Orbot was killed when the tor daemon was running, the tor daemon will
still be running when Orbot starts again. OrbotMainActivity then checks to
see if tor daemon is running while TorService is stopped. If so, TorService
is started so that the state of everything is in sync.
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.
This is a leftover bit from the old structure, it should no longer be
needed and it causes the status updates to be noticeably delayed so when
OrbotMainActivity is started after being killed, it flashes OFF then ON.
If some internal bit of Orbot is requesting the status of TorService, it
should not cause it to start. So only request status from TorService if it
is running, otherwise keep status as OFF.
the big imports change is because of the Android auto-formatter
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.
Before, the startup sequence showed "Orbot is starting..." for a long time,
then quickly showed the final tor percentage messages. This adds a few
more messages to provide useful feedback.
Now that STATUS_STARTING is sent in TorService.onCreate(), the response
time is snappy enough that we don't need hacks in OrbotMainActivity to
show that long press happened.
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.
If an app is using ACTION_START to start Orbot in the background, but the
user had disabled that using the allowBackgroundStarts pref, then the app
will want to know about that so it can fallback on prompting the user to
bring up Orbot itself for the user to manually start it.
refs #3117https://dev.guardianproject.info/issues/3117
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.
The Handler is a message queue for the main thread, so it should help keep
the UI working while status updates are coming in.
* This removes the constants in TorServiceConstants because the Handler
messages are only for OrbotMainActivity
* this uses the handy shortcut msg.obj for the status message
This aims to make the UI more tighly in sync with the data coming from
TorService. It is not currently perfect in the UI, but it means that the
UI will represent the status bugs in TorService. This is important because
that status info is now broadcast to any app that wants it. So the visible
part of Orbot should show want the apps are seeing to aid debugging. And
status report bugs should be fixed in TorService so that everyone gets the
correctinfo.
mItemOnOff no longer exists, there is no more start/stop button on the menu
and this code was trying to update menu.getItem(0), which is currently the
settings button.
onSharedPreferenceChanged() was entirely empty, and the prefs are all
handled in their own Activity
No need to have separate action strings, using the LocalBroadcastManager
enforces the local-only messaging, and Orbot does not claim the global
broadcasts in any kind of receiver.
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().
Nathan Freitas
Hans-Christoph Steiner