Do not load orphane plugins on Android

Review Request #124561 - Created July 31, 2015 and submitted

Dennis Nienhüser

Qt's plugin loading mechanism is unable to load plugins from the assets virtual file system they're bundled in (via the .apk). The current workaround in PluginManager is to copy the files from assets:/ (the system plugin path) to the local plugin path. A similar approach is done by Qt internally. Our app's private storage is organized as follows:
f/.local/share/marble/maps/earth/ // Downloaded map tiles etc
f/.marble/plugins // Marble plugins
r/qt-reserved-files/plugins // Qt plugins
r/qt-reserved-files/qml // QML plugins including QtQuick Android controls
r/qt-reserved-files/android-style // Graphics resources

I can't tell how the r/ files are handled during package upgrades (can anyone help out?), but the ones in f/ stay untouched. Therefore we can end up in the following scenario:
- Marble Maps version n installs plugin foo
- Marble Maps version n+1 does not ship foo anymore, or has foo renamed bar
- User updates from n to n+1. f/ files stay intact, so foo stays around
- User starts n+1, foo is loaded
This can have all sorts of undesired effects, from having foo around although we don't want it to crashes or random runtime behavior due to ABI changes.

The patch fixes this by generating a whitelist of plugins shipped in the current version, then refusing to load any other plugins it encounters. Given the path structure outlined above it should be safe to delete such orphane plugins even (currently not implemented, just a comment in the code).

checking qDebug output on a Nexus 4 with adb logcat.

Dennis Nienhüser
Review request changed

Status: Closed (submitted)

Change Summary:

Submitted with commit 520558da3f0b48ac77c6f95851e509d5ab05f681 by Dennis Nienhüser to branch master.