On some devices this can take some time (i.e. a second) and the UI needs
to be disabled for that time. This should stop users quickly stopping and
starting regularly, queuing up many "start jmdns, stop jmdns, start jmdns"
calls.
These are already in its layout-v11 version. And as lint points out,
these need v11:
?android:attr/buttonBarStyle requires API level 11 (current min is 8)
?android:attr/buttonBarButtonStyle requires API level 11 (current min is 8)
Translators:
agilob Polish
Hsiu-Ming Chang Chinese (Taiwan)
Nathan Follens Dutch
Perry Verheij Dutch
Robin van der Vliet Dutch
Robin van der Vliet Esperanto
Verdulo Esperanto
Wathiq Qajar Arabic
Translators:
Coucouf French
Danial Behzadi Persian
Green Lunar Hebrew
Licaon Kter Romanian
M2ck French
Marian Hanzel Slovak
Verdulo Esperanto
Verdulo Polish
Translators:
fabrizio maggi Italian
Gabriele Pau Italian
Irvan Kurniawan Indonesian
Karola Marky Latvian
Patrik Kretic Slovenian
riotism Chinese (Hong Kong)
Translators:
bd339 Danish
Danial Behzadi Persian
David Koňařík Czech
Massimiliano Caniparoli Italian
Olexandr Nesterenko Ukrainian
Sebastiano Pistore Italian
Tobias Bannert German
Tong Hui Chinese (China)
As reported by a user via ACRA:
java.util.UnknownFormatConversionException: Conversion: I
at java.util.Formatter$FormatToken.unknownFormatConversionException(Formatter.java:1399)
at java.util.Formatter$FormatToken.checkFlags(Formatter.java:1336)
at java.util.Formatter.transform(Formatter.java:1442)
at java.util.Formatter.doFormat(Formatter.java:1081)
at java.util.Formatter.format(Formatter.java:1042)
at java.util.Formatter.format(Formatter.java:1011)
at java.lang.String.format(String.java:1988)
at android.content.res.Resources.getString(Resources.java:355)
at android.content.Context.getString(Context.java:350)
at org.fdroid.fdroid.UpdateService$1.onReceive(UpdateService.java:210)
at android.support.v4.content.LocalBroadcastManager.executePendingBroadcasts(LocalBroadcastManager.java:297)
at android.support.v4.content.LocalBroadcastManager.access$000(LocalBroadcastManager.java:46)
at android.support.v4.content.LocalBroadcastManager$1.handleMessage(LocalBroadcastManager.java:116)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5136)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:525)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:740)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:556)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
at dalvik.system.NativeStart.main(Native Method)
Translators:
Adam Magnier French
Adrià García-Alzórriz Catalan
Adrià García-Alzórriz Spanish
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
Dominik george French
Dominik george German
Enol Puente Asturian
Jean-Baptiste French
M2ck French
Marcelo Santana Portuguese (Brazil)
Massimiliano Caniparoli Italian
Mladen Pejaković Serbian
Nam Mai Hoang Vietnamese
naofum Japanese
Nick Bishop Greek
riotism Chinese (Hong Kong)
Sérgio Marques Portuguese (Portugal)
tacsipacsi Hungarian
ultrapeer Turkish
Андрій Бандура Ukrainian
Дмитрий Михирев Russian
Translators:
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
hrskrs Albanian
Kalle Lampila Finnish
Mladen Pejaković Serbian
Persian: fix format strings Daniel Martí
Tobias Bannert German
Someone introduced lots of %I and and other weird format issues like %!.
Fixed all of them.
We normally catch these via Android's lint, but it appears that %I went
under its radar.
Fixes#530.
Translators:
Adrià García-Alzórriz Catalan
ageru French
Ajeje Brazorf Sardinian
Allan Nordhøy Norwegian Bokmål
Enol Puente Asturian
Erwin Scheuch-Heilig German
Karola Marky Japanese
Ldm Public French
Marcelo Santana Portuguese (Brazil)
Massimiliano Caniparoli Italian
naofum Japanese
Reiner Herrmann German
riotism Chinese (Hong Kong)
Tobias Bannert German
ultrapeer Turkish
Styling the default dialog was difficult and it doesn't obey some
of the guidelines provided by the Android design docs:
https://www.google.com/design/spec/components/dialogs.html#dialogs-specs
(see "Content Guidelines")
This change introduces a custom dialog extending the base ACRA reporting
activity. Specifically, it introduces a padding of 24dp around the dialog
contents.
Translators:
Adrià García-Alzórriz Catalan
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
Allan Nordhøy Norwegian Bokmål
Enol Puente Asturian
Kalle Lampila Finnish
Marcelo Santana Portuguese (Brazil)
Mladen Pejaković Serbian
naofum Japanese
Tobias Bannert German
Андрій Бандура Ukrainian
Саша Петровић Serbian
Translators:
Ajeje Brazorf Sardinian
Green Lunar Hebrew
Ldm Public French
lucnsy Chinese (China)
Massimiliano Caniparoli Italian
Mladen Pejaković Serbian
naofum Japanese
Nordlenningen Norwegian Bokmål
Sérgio Marques Portuguese (Portugal)
Tobias Bannert German
Vdragon, Ｖ字龍 Chinese (Taiwan)
Search as the user types
Fixes#323.
This does away with the separate `SearchResult` and instead applies the search to the currently viewed tab on the main screen (Available, Installed, Updates). When filtering the Available list, it filters the currently selected category.
Note however that there are still times when the old style `SearchDialog` will be shown over the top of the action bar rather than the `SearchView` within the action bar. These times include:
* When a user with a hardware keyboard starts typing from the main screen.
* On older devices with a "search" hardware button.
* Probably some other cases (I think when there is not enough screen real estate, but haven't seen that happen).
In cases where this dialog is shown, filtering the lists as you type does not seem to be an option. I tried to figure out how to do that, but failed. If someone else figures it out, that would be great. However, when the search is submitted, it will hide the `SearchDialog` and populate the `SearchView`, focus it, and apply the search appropriately.
There is a script in the `F-Droid/tools/` subdirectory which will consecutively send various intents to F-Droid relating to search. This includes Play, market, Amazon search links. For good measure, I also made it send intents to do with viewing app details. This should probably be made into a proper instrumented test at some point, but I didn't have the time to figure out how to do that. Maybe a project for future @pserwylo.
One unknown is the performance implications. There is no problems on my Nexus 4 with Android 5.0. My Chinese/ebay/$30/Android 2.3.4 device seems good enough too.
See merge request !177
The system's are sometimes wrong, e.g. unexpected names. This also helps
our support across different Android versions without having to worry as
much about the system's language support.
Fixes#503.
Translators:
Dario Tordoni Italian
Elia Argentieri Italian
Enol Puente Asturian
halcyonest Korean
M2ck French
relan Russian
Tobias Bannert German
Дмитрий Михирев Russian
In addition, added a @Nullable constraint on the categorySpinner
and a null guard when resuming the fragment to handle possible
null cases (though I don't think there will be any).
This caused the entire list view to e animated when navigating
back to the Available tab. Tried switching the `animateLayoutChanged=true`
to a child view only containing the category spinner, but this is not how
the animation handling works. It needs to animate both the thing being
hidden/shown, and also the next sibling of that thing to work properly.
Thus, moving the spinner to its own child and leaving the list didn't work.
Translators:
agilob Polish
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
Daniil Stryukov Ukrainian
Enol Puente Asturian
Jaroslav Lichtblau Czech
Ldm Public French
lucnsy Chinese (China)
Marcelo Santana Portuguese (Brazil)
Mladen Pejaković Serbian
naofum Japanese
relan Russian
Fix 324 : Out of memory errors while updating repos.
Fixes#324, but in the process makes the updater take a lot longer. My benchmarks tell me that an update which used to take approx 30 seconds on my Nexus 4 now takes about 50-55 seconds. This is because it first inserts the apps into the database (in a temp table) and then subsequently copies that table to the actual table. This means there is a lot more disk access than before.
I'm open for discussion on whether this tradeoff is worth it - however I'll caution that there is always going to be a tradeoff between faster and more memory vs slower and less memory. This is the case with all software, and perhaps more so with memory constrained devices such as phones. Also, as the repo index grows (until perhaps we are able to extract the app descriptions in the future), this will become more of an issue.
I'd also like this to be CR'ed properly before merging, because it changes some important code around the repo updater. It is important because security, and it is also important because it is the main thing that F-Droid needs to do (get a list of apps to show the user).
See merge request !173
