Available on stores/repos?

[Mr-Bajs]

So what are the plans for making it available on app stores or app repos?
Google Play?
Fdroid reproducible build?
Accrescent?

[matejdro]

Definetely not Play Store, don't want to bother with Google's bullshit.

I might take a stab at the F-droid at some point. Until then, you can use Obtainium to get auto updates (it's already linked in the readme).

[ItsHarper]

I'd love to see this on IzzyOnDroid, ideally with reproducible builds. See #83 for slightly more info.

[matejdro]

From what I can see, both F-droid and Izzyondroid require pretty complex manual process of opening a PR/issue and then manually talking to people to include the app, instead of just a web interface to manage this (like the Rebble/Pebble store). Sorry, I'm not willing to deal with this. But if anyone wants to go ahead, I give my full approval and am willing to help with the metadata / building.

[mid-kid]

The reason why it's so manual is because their app inclusion policies are necessarily somewhat strict. You will have to have a bit of back and forth regarding how to best include metadata in your repository and make it buildable using open source toolkits, making sure no proprietary libraries of the sort are used.

Izzyondroid is a bit more lax, so I submitted the app there: https://codeberg.org/IzzyOnDroid/repodata/issues/372
But I'm not an android developer, so I will need some assistance to check whether the app complies with their policy and any other requests they may make.
I will do my best to mediate wherever possible.

[IzzySoft]

And it involves "talking to people to include the app" as we have a quite thorough review process. Which currently would need one of the devs here to take off – ideally, questions would be answered in the linked AIR (App Inclusion Request), which later is linked with the app for full transparency, but let me copy-over the current part which needs to be addressed:

---

Our scanner yelled about

Android Signing Block verification:
-----------------------------------
* Google blocks:
  * Has "Dependency Info" block (0x504B4453): Yes

which would just need a few lines to be added to your build.gradle:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs (for IzzyOnDroid/F-Droid)
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles (for Google Play)
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. in our documentation on Signing Block Checks at our website, and in our blog article Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

Apart from that, scan results look fine – just short explanations on the following permissions would be nice (they are listed with our repo browser then, so if someone thinks a given permission looks "suspicious", they can clearly tell what it is needed/used for with this app):

Manifest verification:
----------------------
* Dangerous permissions
  * android.permission.ACCESS_COARSE_LOCATION
  * android.permission.ACCESS_FINE_LOCATION
  * android.permission.ACCESS_BACKGROUND_LOCATION
  * android.permission.BLUETOOTH_SCAN
  * android.permission.QUERY_ALL_PACKAGES
  * android.permission.READ_CALENDAR
  * android.permission.READ_CALL_LOG
  * android.permission.READ_CONTACTS
  * android.permission.READ_PHONE_STATE
  * android.permission.RECORD_AUDIO

(note: none of these raises any suspicion with me – I'm a Pebble and Gadgetbridge user for 10+ years 😉) You are free to specify explanations for the other permissions as well if you wish, for maximum transparency. Examples (copied from Gadgetbridge):

android.permission.ACCESS_FINE_LOCATION: e.g. for calculation of Sunrise/Sunset times
android.permission.ACCESS_BACKGROUND_LOCATION: e.g. for calculation of Sunrise/Sunset times while the app is in background
android.permission.BLUETOOTH_SCAN: to find devices to connect
android.permission.QUERY_ALL_PACKAGES: e.g. to apply app specific settings
android.permission.READ_CALENDAR: to sync calendar events to the gadget
android.permission.READ_CALL_LOG: to report caller details
android.permission.READ_CONTACTS: to add contact information to call/SMS notifications
android.permission.READ_PHONE_STATE: to report incoming calls

---

Next, we'd need the app metadata (description, icon, screenshots) in a Fastlane tree. We're just working on a tool making that easy; it's not yet live (hopefully will be later this week), but you can clone https://codeberg.org/IzzyOnDroid/tools-fastlane and just open its index.html locally if you want (works totally without any server).

---

And the last thing for now would be precise build instructions. I've looked at your GigHub Actions, but I 1) cannot tell if you use those for your releases, and 2) it's not 100% clear to me which steps we would really need to produce an APK identical to yours.

Thanks in advance for your help! 🤗

PS, and Re Policy: you don't use any LLMs for coding here, correct?

[mid-kid]

Thanks for reaching out!

As for the permissions, the gadgetbridge examples look identical to what they're used for in this app. I believe besides weather, the fine location is also used for some navigation applications. QUERY_ALL_PACKAGES, I imagine is used for third party applications wishing to expose functionality to the watch. RECORD_AUDIO, I'm sure is used for voice recognition from the watch.

I'll give the author time to reply to this, they can probably give more accurate descriptions, but if need be I can dig into the code and try to figure it out. Same with the metadata, I'm open to try creating a PR for that, but I think the author will know best how to present their app.

PS, and Re Policy: you don't use any LLMs for coding here, correct?

I scanned the commit log, and explored the codebase a little, and can't find any obvious traces. To me this repo seems clean.

[IzzySoft]

Thanks @mid-kid! Maybe once the point is reached, you could write a "sum up comment" over at your AIR, so we can pick up? I'm not sure I can follow all the steps here (drowning already), but of course will do my best to help where questions might come up.

[matejdro]

Permissions:

Manifest verification:
----------------------
* Dangerous permissions
  * all location permissions - So watchapps/watchfaces can access location for weather etc. data
  * android.permission.BLUETOOTH_SCAN - scanning for watches
  * android.permission.QUERY_ALL_PACKAGES - needed to list all apps in the notification settings menu 
  * android.permission.READ_CALENDAR - syncing of the calendar to the watch
  * android.permission.READ_CALL_LOG - needed for the call alert popup on the watch
  * android.permission.READ_CONTACTS - needed for the call alert popup on the watch
  * android.permission.READ_PHONE_STATE - needed for the call alert popup on the watch
  * android.permission.RECORD_AUDIO - needed for the voice recognition from watch

To produce a release apk you simply run ./gradlew assembleRelease in the root of the repo (with the Android SDK set up, of course). Although one issue here is that you are missing the RELEASE_KEYSTORE_PASSWORD environment variable, which is private, to sign releases on Github. A different release keystore can be swapped in (or debug keystore used) to make your own release apks.

you don't use any LLMs for coding here, correct?

Not for this repo specifically, but I think Core does make liberal use of the LLMs in the libpebble3 repo, which is included as a submodule. Not sure what the implications are here.

[mid-kid]

Thanks for elaborating!

Not for this repo specifically, but I think Core does make liberal use of the LLMs in the libpebble3 repo, which is included as a submodule. Not sure what the implications are here.

Crud, this might be an issue. I have re-reviewed the app inclusion policy and while it's not explicit about the use of AI in libraries, it's very broad and seems mostly aimed at morality, rather than preventing low-effort contributions or similar. I reckon the amount of code made using AI might be relevant here. I know libpebble3 is one of the main building blocks of this app, but can you give a rough estimate of how much of this project is libpebble3 vs the rest of the app? 20%? 50%?

I also hope @IzzySoft can help clarify these rules.

If it can't get into izzy, I might attempt f-droid, but preparing the metadata sounds complicated and I've never tried before.

[IzzySoft]

I can at least offer some help with the metadata. How about our Fastlane Builder, for starters? Just went live a few days ago, together with our IconMaker, should you need that, too.

Regarding libpebble, I've just put the question to our team what path might be possible there. Thing is, not much you can do about that lib (except using a replacement, if there is any) – but the point is, it would nevertheless bring GenAI stuff into our repo (and if you just look at the commits at PebbleOS, you might think the folks there cannot even visit the toilet without using an LLM – no offense meant, and apologies for the drastic comparison, but I think one of my hands will have enough fingers to count the commits not co-authored by Claude there).

The fact that you cannot even tell what dependency a dependency might drag in tomorrow, does not really make it easier…

Just asked for orientation: would there even be any possible (and feasible) alternative to libpebble?

PS: a quick search for libpebble3 in the Gadgetbridge repo seems to indicate they wrote their own implementation. Not sure if that is something you could adopt, but still want to mention it as reference. One never knows…