Adding shortcuts to home screen doesn't work

[Toni91]

I'm using CC on my Android phone (8.1) with moonreader. Shortcuts do not appear on the homescreen for some reason. Maybe because of the Nova launcher?

[chaley]

Originally Posted by Toni91

I'm using CC on my Android phone (8.1) with moonreader. Shortcuts do not appear on the homescreen for some reason. Maybe because of the Nova launcher?

No, it is because Android 8 changed everything about how homescreen icons work. Fixing it must wait until CC is (radically) changed to support the new way that files are passed between apps. Basically, starting in Android 7 CC cannot pass a book file, but instead must pass a copy.

[pazos]

Originally Posted by chaley

No, it is because Android 8 changed everything about how homescreen icons work. Fixing it must wait until CC is (radically) changed to support the new way that files are passed between apps. Basically, starting in Android 7 CC cannot pass a book file, but instead must pass a copy.

Hi Chaley. It seems that CC file provider still works on some versions higher than 7.1. I use it to feed files to KOReader and works nice on a Huawei Mediapad T5 on 8.1. I think this might work on some other vendor/fws but I'm not sure.

If you, or somebody, wants to check you can test it with koreader, which just handles action.VIEW for file schemes, ignoring content ones.

[chaley]

Originally Posted by pazos

Hi Chaley. It seems that CC file provider still works on some versions higher than 7.1. I use it to feed files to KOReader and works nice on a Huawei Mediapad T5 on 8.1. I think this might work on some other vendor/fws but I'm not sure.

If you, or somebody, wants to check you can test it with koreader, which just handles action.VIEW for file schemes, ignoring content ones.

First, I am no longer a CC developer.

Second, you are missing the main problem. In November 2018 Google started enforcing the requirement that Android apps must "target" a recent android release, specifically Android 8.0 (API 26). If an app targets a release then it must follow the rules for that release. In CC's case this would mean that starting with Android 7, files cannot be passed between apps. Any attempt causes the app to die. This broke CC in very fundamental ways.

It is this Google requirement that stopped me from releasing CC Android updates after summer of 2018. It is in fact this requirement that convinced me that I could no longer continue to be responsibile for developing CC (Android). My choice was to let it die or let someone else try. I chose the latter.

You say that it works in some cases. Yes, it does, because the current releases of CC "target" Android 6. This causes Android 7 & up to run in "compatibility mode" so that passing files works. It also means that CC cannot be updated on the play store. There is a good chance that the current version of CC will eventually be removed by Google because it doesn't target a recent version of Android.

If I were still developing CC I would under no circumstance code around vendor-specific strangeness in this area to try to make passing files work on some devices when targeting Android 8+. There lies madness. Instead I would (attempt) to keep the current behavior for Android 6 while making Android 7+ pass copies of the books (content providers). I suspect that is what the current developer is trying to do, but I don't know that.

EDIT: I see from this post that you already know about what I posted above. Apologies for the lecture.

[pazos]

I was aware that you're no longer the dev behind CC and that google f*cks android each few releases but I wasn't aware that file providers are tied to a targetSdk version. That makes sense.

BTW thanks for your work on CC and Calibre, specially in the wireless device driver.

[peaceridge]

Yes, Chaley, thanks for all your hard work. Very understandable your decision to no longer update android cc. I've actually gone back to my old Lg Android 6 for reading. I love my ipad mini, but it is just too cumbersome to work around downloading and updating my ebooks. I just want to read!

[stumped]

Originally Posted by chaley

First, I am no longer a CC developer.

... In CC's case this would mean that starting with Android 7, files cannot be passed between apps. Any attempt causes the app to die. ...

this is what I can't get my head around , if true.
lets say I just about squeeze a 4Gb HD video into the downloads folder of my android 9 tablet,
and I want to use a file explorer app to find it and hand it off to a video player,
its insane if that 4GB file then has to be copied / moved not pointed at. Even if there is sufficient storage to host a copy, it would take minutes, not seconds to made and hand off such a copy.

or, hopefully, the rule is not as black and white as you portray it, and it exempts the issue of using " open with" on large media files ?

Though the file size of an issue for e books, let's suppose a new improved targeted for A8 version CC has my e book of collected Shakespeare ,my George Martin omnibus, or some 100Mb graphic novel. Is it really going to be required to make and hand off a copy of each to a reader app, and not just provide a pointer. That copy process will not be instant on a low powered phone or basic tablet and will burn up precious storage space.

Surely this destroys much of the utility of any librarian app that is not itself a reader/renderer ?

I did try to google more info but I don't know enough about android coding to understand the intricacies of what I found

PS I did experiment a little with calibre box though. I found an inscrutable icon ( a right arrow in a box thing) that means open with/pass to my default reader app ( moon reader). When I tap that, a copy appears in books/moonreader/attachments. I have not tried to outsmart the system though by making that attachments folder the default download folder for calibre box. I have CB set to download to books/moonreader so that I can then find and open downloads using the my books tab in moon, and I can delete them with moon once read. CB will jsut them tell me the local library is out of date next time I use it, and will re-scan. Nothing breaks.

[chaley]

Originally Posted by stumped

this is what I can't get my head around , if true.
lets say I just about squeeze a 4Gb HD video into the downloads folder of my android 9 tablet,
and I want to use a file explorer app to find it and hand it off to a video player,
its insane if that 4GB file then has to be copied / moved not pointed at. Even if there is sufficient storage to host a copy, it would take minutes, not seconds to made and hand off such a copy.

Here is what Google says. The relevant section is:

Sharing Files Between Apps
For apps targeting Android 7.0, the Android framework enforces the StrictMode API policy that prohibits exposing file:// URIs outside your app. If an intent containing a file URI leaves your app, the app fails with a FileUriExposedException exception.

To share files between applications, you should send a content:// URI and grant a temporary access permission on the URI. The easiest way to grant this permission is by using the FileProvider class. For more information on permissions and sharing files, see Sharing Files.

A "content provider" in Android does exactly what it says, provides the content as a stream (or a database, but that isn't of interest for a book reader). If the recipient wants to be able to move around in the stream, for example re-read a chapter, then the recipient must make a local copy. Because permissions are temporary, if the recipient wants to be able to open the file again later then it must make a copy. If the recipient is happy to stream it once then no copy is needed.

When the problem arose I looked at the code in Android. There are no exceptions. And yes, this sucks as much as you think.

It is also the way iOS works. It sucks there too.

[crane3]

IOS 13/ipados was touted to have "file sharing"; a huge lie.

I cannot even 'share' the ios manual which can be downloaded only from an ios or macos computer.

This may be just a similar reason why many people still prefer to stay with winxp or win7......

[stumped]

Chaley, Thanks for that. I began thinking I had misunderstood the problem but your extra info helps a lot. Reading a book is different to streaming a movie.

So the folks who like having thousands of books in a librarian app will have to accept needing double the storage, for their reader apps to store copies, or do a lot of hands on micro management of the reader apps storage to free up space after reads are completed.

[milady133]

Yes, that kind of behavior was one of the reasons I never considered entering in the apple ecosystem, and when I read it was entering in modern versions of Android... I'm out of options for mobile so I'll just have to live with it. It's supposed to be good for security, but unusable without a lot of pain for productivity: if you are working on a file and you produce different versions, you'll end up with an unknown version of the file in each of the applications closed boxes.

[stumped]

maybe using calibre ODPS will become more popular, and will bypass needing a "librarian" on the device. I got that working with Moon reader after getting advice here and it's quite slick

and maybe I will get around to understanding how to use "my Shelf" in moon reader as a organizer. It's a pity that feature comes without any instructions as it's probably easy to have different shelves for different categories - and I think it's all done with database pointers , so a book can be on mutiple "shelves" and no extra copies get created as it is all within one app

if any one has or knows of a " for dummies" guide to using " My shelf" in moon please say

[pazos]

Originally Posted by chaley

You say that it works in some cases. Yes, it does, because the current releases of CC "target" Android 6. This causes Android 7 & up to run in "compatibility mode" so that passing files works...

If I were still developing CC I would under no circumstance code around vendor-specific strangeness in this area to try to make passing files work on some devices when targeting Android 8+. There lies madness. Instead I would (attempt) to keep the current behavior for Android 6 while making Android 7+ pass copies of the books (content providers)...

I'm sorry for bothering you again, chaley. Yesterday I installed the play store version of Moon Reader, built with targetSdk 28 and is still able to pass a file scheme to other apps without showing the FileUriExposedException on my device.

I'm aware that emulators can open file schemes without problems, following this example:

adb shell
cd /sdcard
echo "hello world" > test.txt
am start -a android.intent.action.VIEW  -t 'text/html' -d 'file:///sdcard/test.txt'

It could be because shell tools are not under a certain domain sandbox and can expose file uris without hussle. But again I can reproduce on my huawei with both am and with modern apps built against latest levels. So I'm guessing that the following scheme will work even on targetSdk >= 24.

try {
    File file = new File("/sdcard", "test.txt"; // lets assume file exists here...
    Intent intent = new Intent(Intent.ACTION_VIEW);
    intent.setDataAndType(Uri.fromFile(file), "text/plain");
    startActivity(intent)
} catch(FileUriExposedException e) {
    // ooohhh, no fun. try the content provider approach instead.
}

[chaley]

Well, file URIs didn't work in CC when I tried changing the target release, using the Android emulator(s) in Android Studio and on my OnePlus phone. It could be that Huawei took out the restriction.

Another complication is that when using the SAF (Storage Access Framework), it is *very hard* to get a real file path. I used a hack that requires reaching into the kernel to get the mount names. I found on some devices the hack doesn't work. I don't know whether my hack will work if targeting V9 or V10. Unfortunately one must use the SAF when accessing SD card. The Android 10 "Scoped Access" documents imply (strongly) that the SAF will be needed for all storage, not just SD cards. If the hack for getting a file path doesn't work then the app must use Android's SAF content provider. The resulting URI can be handed unchanged to other apps.

At this point the problem belongs to Sam & Co. I don't know what they plan to do. I do know that I am (happily) not in the loop.

[crane3]

Originally Posted by stumped

maybe using calibre ODPS will become more popular, and will bypass needing a "librarian" on the device. I got that working with Moon reader after getting advice here and it's quite slick

and maybe I will get around to understanding how to use "my Shelf" in moon reader as a organizer. It's a pity that feature comes without any instructions as it's probably easy to have different shelves for different categories - and I think it's all done with database pointers , so a book can be on mutiple "shelves" and no extra copies get created as it is all within one app

if any one has or knows of a " for dummies" guide to using " My shelf" in moon please say

Not for me. My doctor's office, dentist or barber shop have wifi for me. I don't have tablets that have lte; do not intend to do so. Prefer access to books on my tablets.

Also have not bought additional cloud storage; no reason & too expensive just to store books when not needed or readily accessible when I desire, especially in this era of "blackouts" for "fire safety".