Installing Watchfaces/Apps fails when GadgetBridge is installed fresh.
When trying to install a watchface/app to a pebble on an Android 5 (nexus 4) phone, the following exception is thrown:
06-27 11:25:23.000 10564-10564/nodomain.freeyourgadget.gadgetbridge E/nodomain.freeyourgadget.gadgetbridge.devices.pebble.PBWInstallHandler: Installation failed: no writable external directory foundjava.io.IOException: no writable external directory found at nodomain.freeyourgadget.gadgetbridge.util.FileUtils.getExternalFilesDir(FileUtils.java:104) ~[na:0.0] at nodomain.freeyourgadget.gadgetbridge.devices.pebble.PBWInstallHandler.onStartInstall(PBWInstallHandler.java:136) ~[na:0.0] at nodomain.freeyourgadget.gadgetbridge.activities.FwAppInstallerActivity$2.onClick(FwAppInstallerActivity.java:149) ~[na:0.0] at android.view.View.performClick(View.java:4780) ~[na:0.0] at android.view.View$PerformClick.run(View.java:19866) ~[na:0.0] at android.os.Handler.handleCallback(Handler.java:739) ~[na:0.0] at android.os.Handler.dispatchMessage(Handler.java:95) ~[na:0.0] at android.os.Looper.loop(Looper.java:135) ~[na:0.0] at android.app.ActivityThread.main(ActivityThread.java:5254) ~[na:0.0] at java.lang.reflect.Method.invoke(Native Method) ~[na:0.0] at java.lang.reflect.Method.invoke(Method.java:372) ~[na:0.0] at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903) ~[na:0.0] at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698) ~[na:0.0]
The permission android.permission.WRITE_EXTERNAL_STORAGE" is required to fix this. Possibly the authors have not deinstalled and cleanly installed a fresh copy of gadgetbridge, leading to their copy still holding the WRITE_EXTERNAL_STORAGE permission even though this is no longer part of the manifest.
The permission is not needed as long as we write to our OWN directory.
And that is what we are trying to do.
Strange bug indeed.
If you can build from source, could you please test if the log contains some more useful information after the latest commits?
Please be aware that current master fetches health data in a test database that will be wiped!! So uncheck the preferences related to activity tracker data fetching if you value those.
I currently cannot reproduce it. It occurred when I was using "Clean and Rerun'app' in studio, which I do not want to do right now as that would destroy my app cache.
What do you mean with app cache? "Clean" should remove the class files on your PC. Not sure if it affects the app cache at all. But even then, cleaning the app cache does not delete your activity data, preferences or anything else, just things like which activity was last used, etc.
That said, for this specific case we should actually use the "internal" files directory with
Context.getFilesDir(), not the "external" one.
AFAIU the files are not meant to be looked at by the user, so need not be made available via the external directory.
I'm having the same issue on a Android KitKat 4.4, and GadgetBridge 0.18.4 version from F-Droid. I cannot add new watchfaces, and I cannot see the default apps on the Pebble, among other things (no screenshots, etc….).
If I add the WRITE_EXTERNAL_STORAGE permission to the GadgetBridge Manifest, everything works great. It also solves #153 .
This may explain why the behaviour contradicts the Android SDK documentation:
I just set up a Pebble 2 HR connecting to GadgetBridge 0.29.1 running on Android-x86 7.1r2 in VirtualBox. I had the exact symptoms described in this bug report: no system apps or watchfaces (in fact nothing at all listed in the app manager) and any time I tried to add an app or face, it would start loading on the watch and then fail after the progress bar had moved just a little, and it wouldn't show up in the app manager either.
What finally got it to work was vlopezj's suggestion of adding WRITE_EXTERNAL_STORAGE to the manifest permissions. In my googling I didn't see a rash of complaints related to this, so I don't know how many people it's affecting, but I'm posting here to chime in that I'm affected too, it wasn't a fluke, and in fact hopefully it should be easily reproducible now since it's happening on a fresh VM install and a factory reset watch.
Deleting a branch is permanent. It CANNOT be undone. Continue?