Currently translated at 99.8% (549 of 550 strings)
Translated using Weblate: Albanian (sq) by Besnik Bleta <besnik@programeshqip.org>
Currently translated at 100.0% (3 of 3 strings)
Translated using Weblate: Albanian (sq) by Besnik Bleta <besnik@programeshqip.org>
Currently translated at 99.8% (547 of 548 strings)
Translated using Weblate: Albanian (sq) by Besnik Bleta <besnik@programeshqip.org>
Currently translated at 99.6% (546 of 548 strings)
Translated using Weblate: Albanian (sq) by Besnik Bleta <besnik@programeshqip.org>
Currently translated at 99.8% (545 of 546 strings)
Translated using Weblate: Albanian (sq) by Besnik Bleta <besnik@programeshqip.org>
Currently translated at 99.0% (541 of 546 strings)
Translated using Weblate: Albanian (sq) by Besnik Bleta <besnik@programeshqip.org>
Currently translated at 100.0% (544 of 544 strings)
Translated using Weblate: Albanian (sq) by Besnik Bleta <besnik@programeshqip.org>
Currently translated at 100.0% (541 of 541 strings)
Translated using Weblate: Albanian (sq) by Besnik Bleta <besnik@programeshqip.org>
Currently translated at 100.0% (536 of 536 strings)
Co-authored-by: Besnik Bleta <besnik@programeshqip.org>
Translate-URL: https://hosted.weblate.org/projects/f-droid/f-droid-metadata/sq/
Translate-URL: https://hosted.weblate.org/projects/f-droid/f-droid/sq/
Translation: F-Droid/F-Droid
Translation: F-Droid/F-Droid metadata
Was experiencing some problems with local repo keystore on Android 2.3.4.
Previously, the local repo keystore could fail to create, but would still
return a LocalRepoKeyStore instance to be used. Now it throws a checked
exception, and is dealt with in the relveant places.
Also cleaned up some calls to "e.printStackTrace()" and replaced with
more informative logging messages.
Fixes issue #111. This is a workaround rather than a full solution,
but it solves the problem. There is a bug in Lollipop, whereby including
spongycastle as a security provider causes problems verifying .jar files.
As a result, it is now disabled when actually performing verification,
so that the libraries provided by Android do the work, and then re-enabled
afterwards.
There is an ever so slight chance that the period when this is disabled
may align with the period when spongycastle may actually be required
(i.e. for signing a local repo index). This is a risk which I cnanot
see how to avoid, and will likel7 cause either the signing to fail
due to the unavailability of the relevant security classes. However
this is very minimal, hard to reproduce (I couldn't get it to happen)
and also has the effect of the local repo failing, rather than the updating
of apps failing (which is arguably more important) and so is worth it in
my opinion.
See comments at https://gitlab.com/fdroid/fdroidclient/issues/111
for much greater detail.
Previously the update silently failed, and even showed "No Repository has any package updates". The commit relays one error message per repo and adds a localized message when only a part of the repo updates failed. Also, the error message for more severe errors is made more verbose.
Also removed the "errmsg" variable.
When electing to "Swap Apps" from the main menu, and a LocalRepoService
is already running, then it jumps straight to the wifi QR fragment.
However, it didn't play nice when pressing the "back" button. This is
now fixed, by manually recreating the backstack in this situation.
It also fires up the NFC push message if NFC exists.
Added a "Cancel" button to the swap QR code screen.
Also changed how the LocalRepoService deals with onDestroy(). Previously, it
would invoke `stopNetworkServices()` on the UI thread, blocking for a
significant portion of time (enough to cause ANR messages on my devices).
Now, it does this on a new thread.
As for the QR code size, it was getting quite small on my nexus 4,
which I think has a large screen (even though there is much larger about).
As a result, it couldn't be scanned properly using barcode scanner.
This is the first major diversion from carries mockups, in that the qr
view is now in a scroller, which means the "Open QR Code Scanner" button
may well not be visible on the main screen on small devices. Not sure about
how to manage this tradeoff between biggish qr code but everything
viewable on one screen.
Previously it would direct to the LocalRepo screen, then when that code
was ported to the swap workflow, it did nothing :( Now it does as one
might expect, and actually directs the user to the swap screen.
I had a couple of months of changes which I rebased over master.
It made me sad. After doign what I thought was required to resolve
conflicts, I've now gone and fixed a few bits here and there.
This arose because I didn't try and compile after each merge conflict.
I'll take the lesson onboard and try to remember to do this in the
future :)
Previously, we would redirect to the main list of apps. Now, the swap
thing will show the specific apps in the "LocalRepo" category. It also
shows the "Swap complete" message with a nice icon carrie designed.
Instead of always showing "swap", sometimes it shouldn't be shown
at all (i.e. on the first and last screen) and on the NFC screen,
it says "skip".
There is a translated string called "skip_button_label" available
in the AndroidPreferenceFragment library, but I don't want to rely
on that. Prefer to have our awesome translators be in charge of
that label.
Previously, swap would only enable this if the user hadn't previously
said "Don't show NFC message again". However, we really want people
to be able to swap regardless of whether the actual UI message is shown
or not.
Refactored NfcBeamManager to NfcHelper, to allow extra utility methods
to live there. Specifically, the process of sending a URI over NFC.
Removed some superfluous debugging calls to Log.i().
Took a while to figure out, but the problem was that the support
libraries ListFragment would only ever use getActivity() when
creating widgets. What we really needed was the ability to use
an alternative context, namely a ContextThemeWrapper. If this is
passed to the constructor of a widget, it is themed appropriately.
To make it work, we now create our own list view in onCreateView()
(which is really a copy of the code from the android list_content.xml
file anyway). There are also some workarounds for a bug in the
support library with regards to using your own view.
I did the same as some previous code which copied code from the zxing
library and put it in the com.google.zxing namespace (but left the license
in tact - is this okay for Apache 2.0 stuff?). The reason was that they
encourage copying the relevant two files into your project and modifying
as neccesary. In this case, it wasn't about modifying for functionalities
sake, but rather for android support libraries sake. The upstream version
doesn't support android.support.v4.app.Fragments, only android.app.Fragments.
Hooking up the intent integrator from zxing almost removes the need for
the refactoring which made FDroid.java responsible for handling "new repo"
intents. However, there is still the one case of the user not using
the QR code, but rather a web browser to connect to a swap. That is, they
will click a link on the other phones web browser, which directs them to
initiate the swap. Thus, we still need FDroid.java to be able to distinguish
between a "swap" new repo request, and a regular "add repo" new repo request.
In the process, I also commented out the "It's not working" button.
Listen for a new intent, show a screen to the user mentioning
they are about to start a swap. Make FDroid receive repo intents,
then dispatch to relevant Activity.
Previously manage repo always got the intents. Now FDroid does, and
chooses whether to give to ManageRepos or Client connect.
Not sure if it is required to do it this way or not, but it seems to
work.
I had a bit of an issue getting the "Welcome to F-Droid" string to
fit on one line, because it was breaking on the hyphen. That is still
not resolved in this commit.
Still need to:
* Show error messages instead of the "connect" description
* Jar signing seems not to work when connecting to other repo.
In order to handle returning to F-Droid after connecting (or saying no)
I tagged the intent with a "handled" extra value. That way, I can ignore
trying to connect to a repo if we've already handled that event.
Finally, I also fixed an issue regarding downloading of signed
index.jar files with an uppercase fingerprint.
The fingerprint from the jar differed from that in the swap url,
in that one was upper case and the other was lower case.
This uses an .equalsIgnoreCase check instead. It also adds an
extra guard in case the repo doesn't have a fingerprint. Although
it may not even use the signed repo updater if both the pubkey
and fingerprint are null, it is nice to have the extra assurance.
Fixes issue #19.
I also left some more TODO's around. I should put them in issues,
but I'm in a bit of a hurry.
By starting the repo in the activity, both the NFC and wifi fragments
have access to it. In the future, it will make it easier to move some
of the static stuff from FDroidApp (to do with "selected apps") into
the SwapActivity, as it will not really be needed anywhere else.
The back button will take you back through each step of the swap
process now, and remove the swap Activity completely if you press
back from the first screen. Also, when the WiFi QR code is shown,
the local repo manager actually starts the relevant service.
The website now also has icons which it needs to worry about copying
across to the webroot, so I refactored the "symlink webroot to other
folders - such as /fdroid and /fdroid/repo".
Along with a bunch of networking stuff, a lot of UI to do with selecting
apps to swap was also moved. The background on the list is transparent,
which allows blue to shine through. Also, the text on the list items is
white, which will not work with a white background.
I've temporarily dropped support for searching this list too, until
I get some feedback from carrie et al.
NOTE: This stuff was written before hans fixed apcompat problems with
LocalRepoActivity, but then rebased over it later. As such, it doesn't
contain his fixes. Will need to do that before a stable release. i.e.
Still has a bit of a dependency on API 11 which needs to be resolved.
The Fragments and an Activity which tie all of the swap views together
has begun. The first bit of implementation is to get the current
wifi network displayed, which worked out alright.
This commit contains a lot of theme related stuff, particularly
involving taking assets from carries mockups and making them suitable
to use as drawables. The process for doing this is a story for another
day, but I'll document it and put it on the wiki in the future. carrie
showed me a script that a mate of hers used on another project, and
I've adapted it a little to make it work nicely here (note - it isn't
in this commit).
The button is blue, and always shown with associated text in the
ActionBar. This required a custom drawable which was set as the
background in the styles.xml.
Fixes this crash:
dalvikvm W threadid=1: thread exiting with uncaught exception (group=0xb68df4f0)
AndroidRuntime E FATAL EXCEPTION: main
E java.lang.RuntimeException: Unable to resume activity {org.fdroid.fdroid/org.fdroid.fdroid.views.ManageReposActivity}: java.lang.NullPointerException
E at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2120)
E at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2135)
E at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1668)
E at android.app.ActivityThread.access$1500(ActivityThread.java:117)
E at android.app.ActivityThread$H.handleMessage(ActivityThread.java:931)
E at android.os.Handler.dispatchMessage(Handler.java:99)
E at android.os.Looper.loop(Looper.java:130)
E at android.app.ActivityThread.main(ActivityThread.java:3683)
E at java.lang.reflect.Method.invokeNative(Native Method)
E at java.lang.reflect.Method.invoke(Method.java:507)
E at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
E at dalvik.system.NativeStart.main(Native Method)
E Caused by: java.lang.NullPointerException
E at org.fdroid.fdroid.views.ManageReposActivity.checkIfNewRepoOnSameWifi(ManageReposActivity.java:466)
E at org.fdroid.fdroid.views.ManageReposActivity.addRepoFromIntent(ManageReposActivity.java:455)
E at org.fdroid.fdroid.views.ManageReposActivity.onResume(ManageReposActivity.java:144)
E at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1150)
E at android.app.Activity.performResume(Activity.java:3832)
E at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2110)
E ... 12 more
Rather, only show 25 progress events. I went with "25 events" rather
than "every X apps" because then it will be nice for both large repos
(e.g. F-Droid will update every ~50 apps) and small repos (something
with 20 apps will update for every one, but not add much overhead).
On my testing with an API 11 emulator here, it went from ~32s to
process ~1100 apps to ~20s. When no progress events are sent, then it
also takes ~20s, so this essentially is a 50% improvement for this part
of the update process.
Saves the new data for the repo at the end of the update process to enable the user to re-trigger the update in case the update exited prematurely.
Fixes#84.
When the user updates the repo and all packages are recent, the update dialog exited so fast, that some users might have thought that the repo didn't update. To notify them that no new updates were found, the user now gets a toast.
This reverts to only using standard HTTPS verification based on Certificate
Authorities. This means that self-signed certificates will not work at all
since that is what MemorizingTrustManager was providing. It seems to me
that this was originally working because MemorizingTrustManager was not
correctly validating. I couldn't figure out why PinningTrustManager alone
was not working. But we need to get good stable release out!
I'm leaving all the plumbing in place because this stuff should be included
once its all fixed and working properly. You can see where it was added
here: 254327f9a7
refs #80https://gitlab.com/fdroid/fdroidclient/issues/80
The problem arose when we start with no categories other than the
three defaults, then add a repo with multiple categories. The exact
issue was that although the category spinner itself was updated,
the listener for onChange was referencing the list of categories
from before (with only three categories). Changed it to use data
from the category spinner adapter, that way it is always up to
date.
Also fixed some warnings in the file. Instance access of a static
object, and deprecated method warning.
The superuser shell has a timeout that can be specified. The timeout
was set to 5 seconds, thus the exit code from the shell is -1 (a
reserved exit code used by libsuperuse to indicate timeout).
By my estimate, it is more likely that a user will hit this error
message and get annoyed, compared to actually hitting a genuine timeout
because of some issue with superuser. Especially when we factor in slow
devices and large apps to install. Thus, the timeout has been bumped
to a more generous 30 seconds.
Replaced progress indicator methods with their "support" equivalents.
Also, it seems that on Android 4.0.4 and 4.0.3 if you request a
progress indicator in your ActionBarActivity (from the support
library), that it is set to visible to begin with. At least, that is
the conclusion I have come to, seeing as the only places it is set to
visible is on installApk() and removeApk(). Setting it to hidden in
onCreate seemed to do the trick (Couldn't use onResume, because we come
back from the "Request super user permissions" dialog, which causes
onResume to be invoked).
This commit uses alpha to make the category menu button appear darker to
match the rest of the dark theme. Since the background is black, the alpha
makes it darker. It is only used on the dark theme since alpha would
lighten the menu button on the light themes, and that would make it a worse
match.
If there is an unknown HTTPS certificate, MemorizingTrustManager puts up a
prompt to ask whether the user wants to trust the certificate. It comes at
a weird time in the lifecycle of the dialogs, so the previous dialog might
be null. Therefore add a null check.
This situation should probably be improved and better integrated.
