Versioning

[IzzySoft]

Just wondering, I see there are 3 releases, but the newest one still has versionCode set to 1:

package: name='com.logger.app' versionCode='1' versionName='1.3.0'

As Android tells versions apart by that, this would not be considered an update to the previous ones (Android would simply consider it being the same version as the one installed). Could you please increase versionCode with each new release? Thanks in advance!

PS: That would be done here in pubspec.yaml, it's the integer after the + sign.

[Sanmeet007]

Whoops! I completely missed bumping the versionCode for releases. Thanks a bunch for pointing it out! This ensures the Android recognizes it as a proper update. Lesson learned for next time. 😅

[IzzySoft]

Thanks! Next: take care tag names match the version 😜 At v1.3.0, the APK currently identifies as

package: name='com.logger.app' versionCode='3' versionName='1.3.1'

(though I guess that was rather a one-timer from updating the versionCode).

Adding your app to my repo then. While running it through the sanners, the following popped up:

! repo/com.logger.app_3.apk declares sensitive permission(s): android.permission.READ_CALL_LOG
  android.permission.READ_EXTERNAL_STORAGE android.permission.MANAGE_EXTERNAL_STORAGE
  android.permission.READ_PHONE_STATE
! repo/com.logger.app_3.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

android.permission.READ_CALL_LOG is clear of course. But why the extensive storage permissions? Wouldn't access to a single directory to place the exports into suffice, which could be done via Storage Access Framework (SAF) and thus require no explicit storage permission? Further, what is READ_PHONE_STATE needed for?

DEPENDENCY_INFO_BLOCK is easy to avoid:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        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.

So for now, your app will show up here with the next sync around 6 pm UTC, and look like this:

Be welcome to pick a badge linking there e.g. from your Readme if you like 😃 Looking forward to your reply on the permissions so we can "eat the chocolate" (get the highlighted "sensible permissions" explained – or (partly) removed with a future release.

[Sanmeet007]

Wow that was an Outstanding Investigation

Ok so I have implemented Storage Access Framework (SAF) to grant users granular control over storage access. This eliminates the need for the overly broad MANAGE_EXTERNAL_STORAGE permission and improves user privacy. Additionally, dependency information blocks have been excluded from the APK.

Overall, these changes significantly reduce the app's footprint on user data and enhance its security posture.

The Permissions

<manifest ...>
    <uses-permission android:name="android.permission.READ_CALL_LOG" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    // the above listed permissions are all the permissions app uses now ( as of v1.4.2 )

And about the READ_PHONE_STATE , this permission is required for accessing device state, including SIM card info, used by the call_log plugin to differentiate between SIM 1 and SIM 2 usage. ( and is only required by early android versions )

Here's the link to official flutter plugin in case you want to investigate
https://pub.dev/packages/call_log

[IzzySoft]

Wow that was an Outstanding Investigation

Oof… eh, err… thanks! Well, how to put it without making it look like self-praise… That's part of the checks I do before including apps to the IzzyOnDroid repo… But really glad you liked it! And even more glad and … impressed how fast you applied the suggestions, thanks!

I have implemented Storage Access Framework (SAF)

Yay! That's great. As your app has minSdk set to Android 5, you could then drop all storage permissions (unless you need to access media storage or Downloads on higher Android versions). But please test before you release, to make sure that doesn't break "some other place".

improves user privacy

definitely, thanks for that! 🤩

Additionally, dependency information blocks have been excluded from the APK.

Yay!

And about the READ_PHONE_STATE

Thanks! That currently makes:

Here's the link to official flutter plugin in case you want to investigate

I'm not an Android or Flutter dev, sorry. But thanks for mentioning it! I wonder why it doesn't show up in the library listing; I'd have expected sk.fourq.callog there. But it seems some obfuscation is in place there, seeing a lot of obfuscated names.

No reference to that in your project, though – but a hint in the callog library; ProGuard is usually taken for such job. 🤷‍♂️ Not much you or I could do about that I guess.

[Sanmeet007]

Finally, dropped support for older Android devices running Android version 9 or below fixes the permissions issue permanently, though it increases the application size from 20MB to 43MB !

Anyhow its a flutter thing and I published new readme check out the linked badge

PS: Thanks for all the advice

[IzzySoft]

dropped support for older Android devices running Android version 9 or below

Oof. My repo especially supports longevity/sustainability, e.g. wants to help those running older devices to be able having them useful for as long as possible. So that's a bit unfortunate here. And what's even more troublesome:

it increases the application size from 20MB to 43MB

Which makes it ineligible for my repo then, which has a per-app size limit of 30 MB 😢

So what shall we do here now? IMHO raising minSdk was not needed to get rid of the storage permissions. SAF is supported since Android 5 – and as long as you don't need any special locations (Downloads, media storage i.e. the dedicated spaces for photos and videos) no storage permissions would be needed AFAIK. So maybe you revert that minSdk change and see if it works?

If that's not possible, the only other alternative would be to use ABI specific builds (i.e. one APK per ABI). It's usually the ABI/arch specific Flutter libs blowing up file size (in your case they make up ~14 MB per ABI – so sticking to 1 ABI would reduce the APK size by ~25 MB). If you want to go that path, it would be a good idea to adjust Flutter's standard behavior concerning versionCode: Flutter uses versionCode + ABI * 1000 by default (which would result in 1001, 2001, 3001 etc. for versionCode 1). It would be better then to change that to versionCode * 10 + ABI from the start (as you cannot decrease versionCode later).

PS: I've just tested. The armv8-only APK would be around 17 MB.