a couple of fixes, including enabling lint errors to fail the CI build!
Three fixes, including enabling lint errors to fail the CI build! Comments in the commit message. 09eea0d40bcf6b7a5612ef719177fd4ab2d2193b should be cherry-picked into stable-v0.100 for 0.100.1. Its already in my repo as fb70aada63029e430f2b4f2fb68427e719b63753.
See merge request !341
This is currently baffling me as to how it can happen. This isn't a pretty
fix but it is better that letting F-Droid crash. db9bdc31 was supposed to
make it so that only one thread at a time ever updated the static vars on
FDroidApp.
closes#690
UpdateService.onHandleIntent() starts with a time check for whether an
update is actually scheduled. Before, UpdateService put up a notification
when it started. This changes it so that the notification is put up after
the check, so it should only show the notification if UpdateService is
actually going to run, and no longer when it is just waking up to check the
time.
!307#662
The spongycastle issue is taking a long time to get resolved, has not yet
affected us, and would be a lot of work to fix in a different way. So the
'InvalidPackage' error is just disabled for now.
Provide content Uris to downloaded apks via FileProvider
* moves apk verification back inside the Installer class
* uses support libs FileProvider for content Uris
* move apk file caching and storage methods into ApkFileProvider class
Some of the ugly version checks for Android N can be removed after Android N has been released. Unfortunately Google decided to keep SDK version at 23 for Android N dev preview and only change the CODENAME, thus ``Build.VERSION.SDK_INT <= Build.VERSION_CODES.M`` returns true on Android N preview :/ , see https://commonsware.com/blog/2016/03/17/backwards-compatibility-n-developer-preview.html
Tested on Android N dev preview 3 emulator, Android 6 stock and Android 5.1 rooted with priv extension.
See merge request !331
Tests + Refactorings in preperation for #564 (Filter anti features)
As described in #564, there is a small amount of ground work to be done in order to support a UI for filtering anti features. This is the first stage of that. A subsequent MR will add a database migration to put anti features in their own table, and have a join table between apps and anti features. See commit messages for more detailed descriptions.
See merge request !339
The two helper methods alleviate the need for copious null checks. They also provide
consistent behaviour when there are zero elements (i.e. they return null, rather than
an empty string or empty array, as was the case before).
This is a combination of:
* `String[].split(",")` and
* `TextUtils.join(",", values)`
It seems a bit wastefull to have our own implementation of these two things
which lightly wrap this code, and produce a datastructure which is non standard
and foreign to Java developers.
* moves apk verification back inside the Installer class
* uses support libs FileProvider for content Uris
* move apk file caching and storage methods into
ApkCache class
Extracted new API styles dependent on API 16 and 17 into values-17.
This involved the typical Android design pattern of a "Base" style in
`values/styles.xml`, then the an empty normal style which uses that Base style
as a `parent` also in `values/styles.xml`, and finally any API specific
styles in another version of the normal style in a `values/styles-v17` folder.
Same was done for android:actionBarStyle moving it into into values-v11.
This time, didn't worry about the base style, because there was not much to be
gained. by doing so.
Fixes#582.
See merge request !335
We missed an off-by-one in my previous DB change:
90467bf8bf2f8e4a46cb1db563154df4035bf746
This causes the installed app parsing to happen on each start when on any
build that is on db-version/56. Its not a big deal since the broken code
was not shipped at all, even in an alpha.
In order to avoid having null guards making the code ugly, use a "blank"
instance of Apk which will work for the various comparisons. This fixes
this crash:
fixes#688
java.lang.NullPointerException
at org.fdroid.fdroid.installer.InstallManagerService$4.onReceive(InstallManagerService.java:243)
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:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5001)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
at dalvik.system.NativeStart.main(Native Method)
Improve order by/selection logic for database layer.
This was extracted from the postponed !311.
The order by stuff previously only allowed specifying a particular field. We should also be able to sort based on arbitrary expressions, and such expressions will require the ability to bind arguments using the "?" syntax. This change provides a Java abstraction for the order by, and improves the handling of selection arguments that need to bind to "?" so that both the selection (i.e. `WHERE` clause) and the `ORDER BY` clause can provide arguments as required.
See merge request !329
Make sure to query package manager for `PackageInfo` when required.
A previous commit accidentally pushed the code which queries the
`PackageManager` to a different method, but then still used the
`packageInfo` which was supposed to be populated by that code.
This change rectifies this, and in the process also clarifies/documents under
what circumstances the `PackageManager` needs to be queried, rather than
relying on the incoming intent.
Fixes#686.
See merge request !336
A previous commit accidentally pushed the code which queries the
`PackageManager` to a different method, but then still used the
`packageInfo` which was supposed to be populated by that code.
This change rectifies this, and in the process also clarifies/documents under
what circumstances the `PackageManager` needs to be queried, rather than
relying on the incoming intent.
Fixes#686.
This involved the typical Android design pattern of a "Base" style in
`values/styles.xml`, then the an empty normal style which uses that Base style
as a `parent` also in `values/styles.xml`, and finally any API specific
styles in another version of the normal style in a `values/styles-v17` folder.
Same was done for android:actionBarStyle moving it into into values-v11.
This time, didn't worry about the base style, because there was not much to be
gained. by doing so.
The order by stuff previously only allowed specifying a particular field.
We should also be able to sort based on arbitrary expressions, and such
expressions will require the ability to bind arguments using the "?" syntax.
This changes provides a Java abstraction for the order by, and improves
the handling of selection arguments that need to bind to "?" so that both
the selection (i.e. WHERE clause) and the ORDER BY clause can provide
arguments as required.
Ask for all fields from the content provider.
**To be cherry-picked into `master` as well as this merge into `stable-v0.100`**
Fixes#684.
Ask for all fields from the `ContentProvider`.
It is not a particularly expensive operation in the scheme of things. When we are going to the database, the bottlneck is in disk access for the actual query of the database tables (looking up indexes, performing joins, etc). The difference between retrieving two columns or all the columns when the query is for a handful of apps is inconsequential.
Thus, it is better to be safe than sorry and just ask for all the things so that our value objects are correctly populated. There are indeed suitable times to only request specific fields, but I'd suggest that they are probably only when we need to ask a question about thousands of apps at a time, and then the heap space becomes a concern.
See merge request !328
It is not a particularly expensive operation in the scheme of things. When we
are going to the database, the bottlneck is in disk access for the actual query
of the database tables. The difference between retrieving two columns or
all the columns when the query is for a handful of apps is inconsequential.
Thus, it is better to be safe than sorry and just ask for all the things so
that our value objects are correctly populated.
Translators:
Adrià García-Alzórriz Catalan
Daniel Martí Catalan
Enol Puente Asturian
ezjerry liao Traditional Chinese
Jonatan Swedish
Miss Min Persian
Nutchanon Wetchasit Thai
Sergio Oller Catalan
Permissions UI in AppDetails
* Removes the "m" prefix and some unnecessary TODOs
* Re-uses the permission list from the privileged installer for the list in AppDetails:
See merge request !332
include targetSdkVersion in Apk
In order to work well with the Android 6.0+ permissions, the client needs to know whether an APK has been built against android-23 or higher.
@pserwylo @dschuermann how does this look?
See merge request !323
Check permissions for unattended installer
This PR introduces the class ``ApkVerifier`` which checks the permissions of the downloaded apk file against the expected permissions from the F-Droid listing (``Apk`` class).
* I removed ``AndroidXMLDecompress`` because everything which it has been used for can also be done with ``PackageManager.getPackageArchiveInfo()``, to the best of my knowledge. I even asked in at a similar project why ``PackageManager.getPackageArchiveInfo()``may not be enough: https://github.com/jaredrummler/APKParser/issues/3 It turns out in our case it should do everything we need.
* The code responsible for sanitizing the local apk file and making it world readable has also been moved into ``ApkVerifier`` for now. This can change in a later PR when I introduce the FileProvider for downloaded apks.
We still need to check the target sdk version (see TODO in ``ApkVerifier``). This depends on https://gitlab.com/fdroid/fdroidclient/merge_requests/323
See merge request !322
Remove first-time dialogs for extension installer
The root mechanism will not be useful in 5.1 and later and has been shown to be error prone.
See merge request !330
Port most tests to JVM via Robolectric library
Fixes#607.
This ports all but one of the tests from `app/src/androidTest` to `app/src/test` to be run on the JVM.
I would've liked to port the final one, but it must be run on Android because we are testing the ability of an Android OS to perform symlinks. Also, it is not a bad thing in itself to have tests run on an emulator, just that those which _can_ be run on the host JVM should be. In the future, there will no doubt be other tests which are required to run on the JVM. At the very least, we should be able to run tests on faster emulators now because we are not constrained by the failing provider tests.
This branch required only very minimal changes to the client code, but resulted in the removal of a whole bunch of crappy mocking code that I had to add in order to support testing of the content providers (i.e. navigating around all of the final/hidden/etc apis in Android).
See merge request !327
