that might be, but what if we change the format of teh cache content,
what if we get another category of apps that behave the same... i belive
invalidating the cache after system upgrades is a good thing to prevent
us from any such possibilities
--
You received this bug notification because you
My understanding of how the QML cache works is that if a QML file has
changed, the app’s cache is invalidated and regenerated. If this doesn’t
work, this is a bug in the cache mechanism itself. That said, with the
latest image upgrade, webbrowser-app and webapp-container didn’t change
(there was
Olivier and I had a chat already on IRC about this, to sum it up:
This situation happens because there was no change in the actual QML
files, however an underlying QML plugin did change. In my opinion, this
change comes with an ABI break and there was no version bump for it. Had
there been a
below upstart job for lxc-android-config (untested yet) that should be
shipped as /etc/init/boot-hooks/wipe-qml-cache.conf:
# This allows wiping of the complete QML app cache on OTA upgrades
start on boot-hooks WHEN=new-version
pre-start script
rm -rf /home/*/.cache/QML/Apps/*
end script
teh above should be sufficient as a quick fix to wipe the cache on every
OTA
** Changed in: android (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc-android-config in
Ubuntu.
We actually have logic in place to smartly remove the cache when an app
gets updated, this is just a bug that seems to happen with webapps in
general.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc-android-config in
6 matches
Mail list logo
