This was making proguard complain and refuse to continue. This fix should not
alter how F-Droid works, it's just to make the tests function with proguard
enabled.
Right now, turning on HTTPS really just prevents things from working. It
is not fully required, since swapping is only local connections, so not
easily susceptible to mass eavesdropping, though it would be nice. I'm
leaving the rest of the plumbing for this here intact for when we come back
to getting swap always using HTTPS.
closes#378https://gitlab.com/fdroid/fdroidclient/issues/378
When using locales that use different calendars, like Farsi, Arabic,
Hebrew, etc. there was a crash in spongycastle's X.509 generation because
it was trying to parse a Farsi date string as English.
fixes#334https://gitlab.com/fdroid/fdroidclient/issues/334
Here's the original stacktrace:
java.lang.IllegalArgumentException: invalid date string: Unparseable date: "ñõðøòñðóñõõóGMT+00:00" (at offset 0)
at org.spongycastle.asn1.ASN1UTCTime.<init>(ASN1UTCTime.java:115)
at org.spongycastle.asn1.DERUTCTime.<init>(DERUTCTime.java:23)
at org.spongycastle.asn1.x509.Time.<init>(Time.java:67)
at org.spongycastle.cert.X509v3CertificateBuilder.<init>(X509v3CertificateBuilder.java:40)
at org.fdroid.fdroid.localrepo.LocalRepoKeyStore.generateSelfSignedCertChain(LocalRepoKeyStore.java:301)
at org.fdroid.fdroid.localrepo.LocalRepoKeyStore.generateSelfSignedCertChain(LocalRepoKeyStore.java:281)
at org.fdroid.fdroid.localrepo.LocalRepoKeyStore.<init>(LocalRepoKeyStore.java:136)
at org.fdroid.fdroid.localrepo.LocalRepoKeyStore.get(LocalRepoKeyStore.java:73)
at org.fdroid.fdroid.net.WifiStateChangeService$WaitForWifiAsyncTask.doInBackground(WifiStateChangeService.java:124)
at org.fdroid.fdroid.net.WifiStateChangeService$WaitForWifiAsyncTask.doInBackground(WifiStateChangeService.java:62)
On certain locales, F-Droid would crash at startup due to #334.
This isn't a proper fix, but rather a workaround that logs what happened and
links to the issue, instead of making F-Droid crash entirely.
Add timeout for Http request
The timeout of HttpURLConnection is 0, which means the request would never return if either connection or read timeouts, and the code would never catch these exceptions.
This patch set explicit timeout value (10s for connection timeout and 40s for read timeout), so the code would catch and handle timeout exceptions as you would expect.
Best,
See merge request !117
Prompt for beta updates
Ready to get merged. 👍
~~This MR is ready to get merged, the last thing that needs to be fixed is [this](72ed814a73 (note_1726274)).~~
This closes#313.
See merge request !112
Integration branch containing both MR 102 and 107
Given both MR !102 and !107 both stood on eachothers feet to some extent, this branch contains all commits from both in an integration branch. If both @Nutomic and @eighthave are happy that it faithfully kept their changes during the minor merge conflict resolutions, then we can merge this instead of those two branches.
* !102 changed download progress from events + listeners to broadcasts + receivers.
* !107 made use of download progress events + listeners to show a downloading UI that was embedded in the activity, rather than shown as a modal dialog.
The conflicts which arose while I merged these branches together were in `AppDetails`. I made it so that, to the best of my ability, it uses broadcast receivers instead of progress listeners when updating the progress bar. Other than that, the only other conflict was both trying to store a reference to the main button from the UI. The only changes were in naming (mainButton vs btMain) and also in the place where the local variable was assigned (onCreate() vs setupViews() which is called during onCreate() anyway).
After merging, I did some minor cleanups. This is because in the process of checking that my conflict resolution compiled, I thought it best to remove a bunch of warnings from `AppDetails` and others. Turns out that by doing so, I found a bug due to the integration (to do with the `AppDetails` querying the downloader for status in `onResume()` rather than waiting for a broadcast event) so I'm glad I did so.
Let me know what you think, and then after the next stable, we can go ahead and merge this if people are happy.
p.s. I have no idea why GitLab is showing @eighthave's commit at the top of the list of commits, after my integration related commits.
See merge request !114
AppCompat no longer supports progress indicators in the action bar. So
this is not your everyday "Deprecated, but sure, keep using it" job.
Rather, it is "deprecated, and no, we wont even let you use it."
Also removed unused argument and extended AppCompatActivity.
To make things less confusing, this disables the main button on AppDetails
when something is running. During install, it also changes the text of the
button to "Installing..."
This removes lots of boiler plate, makes it much easier to get the info
where it is needed, and puts the code in line with rest of FDroid. The
ProgressListener pattern was forcing a lot of passing the listener
instances around through classes that never used the listener even.
