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.
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 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.
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.
When clicking on "Wizard" from the menu, then clicking back, it gets stuck
in a strange back stack purgatory, and then randomly changes the language.
So purge the wizard stuff for now, and add back the parts that are still
needed once that is all figured out.
This also simplifies the refactoring of the Intent handling.
https://stackoverflow.com/questions/13291578/how-to-localize-an-android-app-in-indonesian-language
Note that Java uses several deprecated two-letter codes. The Hebrew ("he")
language code is rewritten as "iw", Indonesian ("id") as "in", and Yiddish
("yi") as "ji". This rewriting happens even if you construct your own
Locale object, not just for instances returned by the various lookup
methods.
This leaves the default Locale unchanged, i.e. Locale.setDefault(). This
also will immediately change the language after the user selects it in the
pref.
The recommended way to send a START_TOR Intent is using
startActivityWithResult() so that the sender knows when Tor is actually
started. The return includes an Intent that can also include the config
info for the proxies that Orbot runs. Right now, this is based on the
app defaults, but ultimately, it should dynamically get the port numbers
for cases like Samsung devices where there is a port conflict.
Nathan Freitas
Hans-Christoph Steiner