Openlib

Openlib copied to clipboard

Scanner report for today's update reads:

! repo/com.app.openlib_2008.apk declares sensitive permission(s): android.permission.READ_MEDIA_IMAGES android.permission.READ_MEDIA_AUDIO android.permission.MANAGE_EXTERNAL_STORAGE android.permission.READ_EXTERNAL_STORAGE

I guess READ_EXTERNAL_STORAGE is for eading downloaded material (as WRITE_EXTERNAL_STORAGE is to save eBooks; together with MANAGE_EXTERNAL_STORAGE on Android 11+). Can you confirm this?

What I however do not understand (at least going by the app description) is what media access (images and audio) is needed for. A clarification would be much appreciated!

As for DEPENDENCY_INFO_BLOCK: this can probably be avoided easily via some gradle settings:

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.

Scanner report for today's update reads:

! repo/com.app.openlib_2008.apk declares sensitive permission(s): android.permission.READ_MEDIA_IMAGES android.permission.READ_MEDIA_AUDIO android.permission.MANAGE_EXTERNAL_STORAGE android.permission.READ_EXTERNAL_STORAGE

I guess READ_EXTERNAL_STORAGE is for eading downloaded material (as WRITE_EXTERNAL_STORAGE is to save eBooks; together with MANAGE_EXTERNAL_STORAGE on Android 11+). Can you confirm this?

What I however do not understand (at least going by the app description) is what media access (images and audio) is needed for. A clarification would be much appreciated!

As for DEPENDENCY_INFO_BLOCK: this can probably be avoided easily via some gradle settings:

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.

The above permissions are used because on some devices, the EPUB reader works properly with them, and the upcoming update of the app would use a separate folder to store the book.

So the next release comes without those permissions? Then I'd say no further action needed for that – which would only leave the DEPENDENCY_INFO_BLOCK (to be handled at your convenience; trouble with that one is mostly that it's an "opaque block". Though there are POCs that such blocks can easily be abused to store payload and other "things", so it might be a good idea to address this: what's not there cannot cause issues. And apart from Google, nobody can even read it, not to speak of doing something useful with it).

No , The permissions are required for the EPUB package and will add support for direct folder for the app

Will you able to fix this DEPENDENCY_INFO_BLOCK

The permissions are required for the EPUB package and will add support for direct folder for the app

I can see that for READ_EXTERNAL_STORAGE and MANAGE_EXTERNAL_STORAGE (which I added to the "allow-list" for your app, so those will no longer trigger warnings here) – but READ_MEDIA_AUDIO and READ_MEDIA_IMAGES? There shouldn't be eBooks stored to the media directories, so I wonder why those permissions should be needed.

Will you able to fix this DEPENDENCY_INFO_BLOCK

See above, it's just adding a few lines to your build.gradle:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

Okay 👍 will sure add it

Looks like you forgot:

! repo/com.app.openlib_2009.apk declares sensitive permission(s):
  android.permission.READ_MEDIA_IMAGES android.permission.READ_MEDIA_AUDIO
! repo/com.app.openlib_2009.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

The media permissions are still there, and so is the blob…

Will sure remove it. Thank you

Still there with today's, yesterday's and the-day-before's update:

! repo/com.app.openlib_2001.apk declares sensitive permission(s): android.permission.READ_MEDIA_IMAGES android.permission.READ_MEDIA_AUDIO
! repo/com.app.openlib_2001.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

Funny. The tag is named 1.0.7, but IoD still shows 1.0.6 as latest. Which comes at versionCode 2009, while this one shows 2001, thus is considered an older release and removed right on arrival just to be pulled again to start over the cycle:

package: name='com.app.openlib' versionCode='2001' versionName='1.0.7'

Android will refuse accepting that as update for any previous versions as it would consider it a downgrade. I've disabled updates here now to avoid the circle of download-delete-download-delete. Please let me know when it's fixed.

Btw: if you wonder where the versionCode comes from: it's this line, and the +1 (which flutter by default adds 1000, 2000 etc. to for each ABI). Guess you "slipped" and that should have been a "+10"?

Last update still has them:

! repo/com.app.openlib_2011.apk declares sensitive permission(s):
  android.permission.READ_MEDIA_IMAGES android.permission.READ_MEDIA_AUDIO
! repo/com.app.openlib_2011.apk contains signature block blobs: 0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

Will you take care for that? Especially preventing that blob should be pretty easy.