| Age | Commit message (Collapse) | Author |
|---|
|
Last refactor, introducing ButterKnife and all those things, I forgot to
update this layouts.
|
|
|
|
|
|
|
|
|
|
Beware! https://code.google.com/p/android/issues/detail?id=80074: Wrong VpnService.prepare() behavior after re-installation of the VPN app on Android 5.0
"The following steps will cause incorrect behavior of the VpnService.prepare():
1. Establish VPN connection using any VPN app. VpnService.prepare() will return an intent for the "Connection request" system activity. Once user accepts it, VPN connection can be established successfully.
2. Uninstall VPN app.
3. Re-install the same VPN app.
4. Now VpnService.prepare() returns null, as if the VPN service has been already prepared.
5. Now VpnService.protect() returns false and VPN connection fails.
Device reboot is needed in order to be able to establish VPN connection again."
|
|
Refactored the new provider dialog too.
|
|
Removed the sign up dialog, log in one is enough with the third button I
added some time ago to sign up.
Removed classes we don't need due to the libraries I have recently
introduced.
|
|
|
|
|
|
|
|
It shows just one provider, and it's not the one that gets configured if
selected.
|
|
|
|
|
|
|
|
|
|
|
|
Update gradle to 2.2.1.
|
|
One more onReceiveResult for Dashboard, that method needs a rethink: a
statemachine class, and a simple "next()" method? The reality is that
the onReceiveResult specifies a linked process, and that should have a
better model than a series of if/else cases with strings comparisons hehehe
|
|
|
|
|
|
|
|
ProviderAPI from debug build uses an invalid certificate the first time
it tries to download a new cert, just to test this.
|
|
|
|
|
|
Reproduced the refactoring done in debug.
|
|
Reuse EipServiceFragment's stopEip and startEipFromScratch in Dashboard.
|
|
Fix a typo in the debug source of ProviderAPI.
|
|
|
|
Always. Previously we didn't do so if EIP hadn't been started before.
Fix a small bug introduced during latest refactoring, authentication did
not work because the final result variable wasn't assigned.
|
|
Authenticate and Register methods are now renamed and split. It's much
more readable, the new emacs-default indentation helps to that too.
|
|
|
|
Fixed notifications too (forgot to do it in another branch, it's #5964).
|
|
|
|
|
|
|
|
|
|
It's enough to reflect the fact that the button leads to a dialog from
which the user can both log in or sign up.
|
|
It takes for granted that the certificate is valid from the very same
date it's downloaded.
|
|
|
|
I've also fixed another message: if a file to be downloaded is not
found, we say the entered provider isn't a LEAP provider. This is based
on the fact that if provider.json doesn't exist/contain valid
information, then the url isn't pointing to a LEAP provider.
|
|
We don't assume ca.crt is in /ca.crt anymore, but fetch the complete url
from provider.json.
We also signup against users.json file instead of simple "users", which
worked for *.bitmask.net domains.
|
|
Functionality copied to the Release build.
|
|
This has the problem of localized messages. irc log questioning:
May 8th 2014
08:12 <@parmegv> mm, I was thinking... I was rephrasing the error messages given by our api during authentication
08:13 <@parmegv> I thought why should I rephrase it and think twice
08:13 <@parmegv> so now I'm just "pretty printing" the error message given by the api
08:13 <@parmegv> but that has a problem: they aren't localized
08:14 <@parmegv> would implementing a localized version of our error messages be useful?
|
|
A bit of refactoring too, sendM1 much simpler.
|
|
|
|
There is some problem in the maths, because the server says it's ok but
login doesn't work from Android app nor from webapp.
|
|
|
|
'bug/provider.json-isn't-downloaded-without-danger_on-set-to-true-#5568' into develop
|
|
Removed the default danger_on = true in the debug build.
|
