- some users run their own iptables transproxy scripts with AFWall and need Orbot to have these ports open by default. There is no risk to enable them by default, so we'll them on for now, and think about how to better make this a user option in the future.
This builds the jtorctl java with the rest of Orbot's java. The process of
making a jar breaks when external/Makefile is run with frozen time using
faketime. That is needed to get reproducible native bits.
Samsung devices like to use 9050 (Since their hardware model is i9050!). Tor likes to use port 9050. This new code looks to see if port 9050 is available, and if not, change the setting to 'auto' so Tor can find another port.
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
Nathan Freitas
Hans-Christoph Steiner