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().
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.
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.
The Languages utility class merges the techniques from ChatSecure and
Courier. It fetches the supported locales from the APK itself, and fetches
the native names of the languages from the system.
Hans-Christoph Steiner
n8fr8