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.
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
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.
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.
- 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.
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