summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* v15.0.1 beta 2Nathan Freitas2015-06-25
|
* Enable support for app selection to work with VPN mode on Lollipop+Nathan Freitas2015-06-25
| | | | For now we will re-use/overload the app selection transproxy UI in Settings
* update to sdk 22Nathan Freitas2015-06-25
|
* don't try to build external folders in eclipseNathan Freitas2015-06-25
|
* update tun2socks binariesNathan Freitas2015-06-25
|
* update submodule pinNathan Freitas2015-06-25
|
* enable background starts by default only for Service intent callsNathan Freitas2015-06-22
|
* update manifest for v15.0.1 beta 1Nathan Freitas2015-06-22
|
* Merge branch 'the-big-start-stop-makeover' of ↵Nathan Freitas2015-06-22
|\ | | | | | | | | | | | | | | https://github.com/eighthave/orbot into eighthave-the-big-start-stop-makeover Conflicts: src/org/torproject/android/OrbotMainActivity.java src/org/torproject/android/service/TorService.java
| * on start, check for running tor daemon, and if TorService stopped, then startHans-Christoph Steiner2015-06-17
| | | | | | | | | | | | | | 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.
| * init file path variables (tor, polipo, etc) when the app startsHans-Christoph Steiner2015-06-17
| | | | | | | | | | | | | | | | 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.
| * "Allow Background Starts" prefs also controls the old START_TOR IntentHans-Christoph Steiner2015-06-17
| |
| * remove delayed handling of Intents in OrbotMainActivityHans-Christoph Steiner2015-06-17
| | | | | | | | | | | | 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.
| * prevent a status request from starting TorServiceHans-Christoph Steiner2015-06-17
| | | | | | | | | | | | | | | | 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
| * when OrbotMainActivity starts, query TorService for current statusHans-Christoph Steiner2015-06-17
| | | | | | | | | | | | 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.
* | Merge branch 'eighthave-the-big-start-stop-makeover'Nathan Freitas2015-06-22
|\ \
| * | fix handling of foreground intent starts, and set bg start off by defaultNathan Freitas2015-06-22
| | |
| * | improve status request/callback interaction and status UI layoutNathan Freitas2015-06-22
| | |
| * | update tor to 0.2.6.9Nathan Freitas2015-06-22
| |/
| * include all status messages with "start" in them in the starting sequenceHans-Christoph Steiner2015-06-12
| | | | | | | | | | | | 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.
| * drive main screen UI updated entirely from TorService status updatesHans-Christoph Steiner2015-06-12
| | | | | | | | | | | | 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.
| * set STATUS_STARTING in TorService.onCreate(), that's where it beginsHans-Christoph Steiner2015-06-12
| | | | | | | | | | | | | | | | 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.
| * rename TorStarter to IncomingIntentRouter, it handles all IntentsHans-Christoph Steiner2015-06-12
| | | | | | | | TorStarter does lots of things besides starting Tor
| * announce Orbot is ON once the first circuit is completeHans-Christoph Steiner2015-06-12
| | | | | | | | | | | | | | 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.
| * include dynamic proxy config info in ACTION_STATUS repliesHans-Christoph Steiner2015-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This includes extras in the Intents that are sent as replies to the two different requests to start tor (ACTION_START and ACTION_START_TOR). These extras give all of the current SOCKS and HTTP proxy settings, so that the app can dynamically use the correct settings. Sometimes there are port conflicts, so apps should dynamically adjust in order to reliably find tor. closes #3612 https://dev.guardianproject.info/issues/3612 refs #4419 https://dev.guardianproject.info/issues/4419 refs #3690 https://dev.guardianproject.info/issues/3690 refs #3687 https://dev.guardianproject.info/issues/3687 refs #3859 https://dev.guardianproject.info/issues/3859
| * use constants for setting default ports, and variables when runningHans-Christoph Steiner2015-06-11
| |
| * standardize network port constant variablesHans-Christoph Steiner2015-06-11
| | | | | | | | use consistent naming and types for code clarity
| * let the requesting app know that the user has disabled starting via IntentHans-Christoph Steiner2015-06-10
| | | | | | | | | | | | | | | | | | 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 #3117 https://dev.guardianproject.info/issues/3117
| * create a new pref: "Allow Background Starts"Hans-Christoph Steiner2015-06-10
| | | | | | | | | | This lets the user disable the new ACTION_START Intent, in case they have more sensitive needs.
| * on receiving ACTION_START, only send status reply if EXTRA_PACKAGE_NAME setHans-Christoph Steiner2015-06-10
| | | | | | | | | | | | 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.
| * expose start action via a BroadcastReceiver that any app can send toHans-Christoph Steiner2015-06-10
| | | | | | | | | | | | | | This allows any app to broadcast an Intent to Orbot in order to make Orbot start in the background. closes #3117 https://dev.guardianproject.info/issues/3117
| * a couple tweaks to make the long press feel more responsiveHans-Christoph Steiner2015-06-10
| |
| * force all UI status updates through mStatusUpdateHandlerHans-Christoph Steiner2015-06-10
| | | | | | | | | | | | | | | | | | | | 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
| * make updateStatus() more closely match the state given from TorServiceHans-Christoph Steiner2015-06-09
| | | | | | | | | | | | | | | | | | | | 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.
| * purge unused code from OrbotMainActivityHans-Christoph Steiner2015-06-09
| | | | | | | | | | | | | | | | | | 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
| * use the same action string for local and broadcast statusHans-Christoph Steiner2015-06-09
| | | | | | | | | | | | 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.
| * purge unused OrbotLogActivityHans-Christoph Steiner2015-06-09
| |
| * strictly target local broadcastsHans-Christoph Steiner2015-06-09
| | | | | | | | | | | | 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.
| * rename mMessageReceiver to mLocalBroadcastReceiverHans-Christoph Steiner2015-06-09
| |
| * use "SIGNAL HUP" to request Tor re-read its configHans-Christoph Steiner2015-06-09
| | | | | | | | | | | | | | | | | | 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
| * use context.stopService() to shutdown TorService instead of custom messageHans-Christoph Steiner2015-06-09
| | | | | | | | | | | | | | 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.
| * rename mHandler to mStatusUpdateHandlerHans-Christoph Steiner2015-06-09
| | | | | | | | Hopefully this will make the code a little easier to follow...
| * broadcast Tor state to any app that might want to knowHans-Christoph Steiner2015-06-09
| | | | | | | | | | | | | | | | 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.
| * only set mCurrentStatus in sendCallbackStatus(), the one stop shopHans-Christoph Steiner2015-06-09
| | | | | | | | | | Make sendCallbackStatus() the one thing that updates the all of the bits related to running status.
| * rework start/stop procedure to have clear points for ON, OFF, STARTING, STOPPINGHans-Christoph Steiner2015-06-09
| | | | | | | | | | | | | | | | | | 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().
| * rename startService() to sendIntentToService() to reflect what it doesHans-Christoph Steiner2015-06-09
| | | | | | | | | | Even though this method is a wrapper around startService(), it is really used to send various Intents to the Service, not only starting it.
| * mark TorService methods from EventHandler as overriddenHans-Christoph Steiner2015-06-09
| | | | | | | | This keeps me from getting confused...
| * rename status to STARTING and STOPPING since it also starts/stops daemonsHans-Christoph Steiner2015-06-09
| | | | | | | | | | The CONNECTING status also is starting up daemons as well as connecting to the tor daemon.
| * on start and tor daemon not running, kill all daemons before starting againHans-Christoph Steiner2015-06-09
| | | | | | | | | | To make sure there are not any other daemons still running when trying to start the whole thing again, kill all daemons before starting tor afresh.
| * rework killing all daemons to continue trying after a failureHans-Christoph Steiner2015-06-09
| | | | | | | | | | Before, it would quit the process on the first exception while killing. This makes it keep on trying each daemon.
generated by cgit v1.2.1 (git 2.18.0) at 2024-02-08 07:42:50 +0000