CC and Boyue Likebook Mars

[m.a.biglin]

I've used CC for years with no problem. I switched to the Boyue Likebook Mars last December and installed CC on it and has worked flawlessly.

As of yesterday, I updated CC for the 1st time since April and now CC will no longer send books to Boyue Likebook Mars built-in e-reader. I can send it to another e-reader (moonreader+) just fine. It just sits there and does nothing when I hit the read button. If I hit the 3-dots and choose "open books with" and the "Boyue OS" it still does nothing.
All my books are stored on a SD card.

It is running the latest Boyue Software which includes android 6.0.1.
CC is version 5.4.4.9

I have seen a other posts with the same basic problem, but not for this particular e-reader.

[stumped]

the " read" button mechanism in CC has changed. it now tries to hand off a copy of the book to a reader app ( as per google rules). that may not be possible with your device, for the reader app which is part of the OS. You will have to get the developers to look at it - their contact details are in app and on web store. it may not be compatible any more, or it may be a simple bug fix is all that is needed

[ottischwenk]

Originally Posted by stumped

the " read" button mechanism in CC has changed. it now tries to hand off a copy of the book to a reader app ( as per google rules). that may not be possible with your device, for the reader app which is part of the OS. You will have to get the developers to look at it - their contact details are in app and on web store. it may not be compatible any more, or it may be a simple bug fix is all that is needed

Why the hell was it changed?
It worked before - and in all Android apps.
Now it doesnt work eg. on Likebook with the built in Reader App!
Please make it work again!

[stumped]

Originally Posted by ottischwenk

Why the hell was it changed?

i told you why - re-read the 1st sentence ( and a few dozen other posts that also discussed it at the time). also various stickies

complain to the developers, if you like, or to Google. It was google's idea, to change how apps are allowed to share files, in order to "improve security".
In other threads, weren't you one of the fans of newer android versions, for improved security?. well , welcome to the world of unexpected consequences

there's nothing any other user here can do about it. why not restore from a backup of the previous , 2018, version ( you do keep backups ? )

[theducks]

I am a bit more cynical.
It makes things (media) more difficult to load OTHER than from the captive store

[pazos]

Originally Posted by stumped

the " read" button mechanism in CC has changed. it now tries to hand off a copy of the book to a reader app ( as per google rules). that may not be possible with your device, for the reader app which is part of the OS.

Absolutely true. I wonder if packaging eveything in a single APK has something to do with the ExposedFileUri exception, see below.

Originally Posted by ottischwenk

Why the hell was it changed?

Because the new CC dev bumped the android API level to be able to push an update to the Google Play Store.

Each API level is tied to certain rules. When you bump the API level you're accepting the new rules, enforced by the android VM.

In this case the new rule is: crash the VM for a given package if an activity or a service try to send the full path of a file outside the boundaries of the application. It generates an ExposedFileUri exception.

Originally Posted by stumped

complain to the developers, if you like, or to Google. It was google's idea, to change how apps are allowed to share files, in order to "improve security".
In other threads, weren't you one of the fans of newer android versions, for improved security?. well , welcome to the world of unexpected consequences

Improved security I dunno, but makes *some* sense. The app that sends the path has no way to check if the receiving app has permissions to read on that particular directory.

Originally Posted by stumped

there's nothing any other user here can do about it.

True. Users have nothing to do, but developers can fix that issue. For instance, reading apps can figure out a path from a file provider uri without making a hard copy when the file provider is serving a local file (no dropbox or gdrive). That's what KOReader does.

But it is easier for CC dev to remove that specific VM policy and provide an option to the user. I would implement it this way:

1. Assign the "read" button to the legacy behaviour (send the path of the book)
2. Add a new button "send to" with the new behaviour (send the book itself)
3. Provide an option in settings to enable legacy behaviour
4. If legacy behaviour is not enabled the "read" button will be disabled and the user will notice that he/she is sending the book to the reading app of choice.

Both workarounds (for sending and receiving apps) are showcased in https://github.com/pazos/filesResolver. Removing the offended VM policy is just adding a few lines to CC app subclass: https://github.com/pazos/filesResolv...App.kt#L11-L13

[stumped]

In the meantime, the workarounds are as simple as stop using the read button. Use CC to download then use any files app to locate and open the book with the default reader app. I do that now , for reading with moon, to avoid the clutter and confusion of having copies passed.

I wonder, but don't personally care, if read is also broken now for .aws on fire tablets, as those also have the reader baked into the Fire OS. I speculate there are more fire tablet users than bound.
The old CC version was pretty crap for Amazon formats on fire anyway, as it could not resume a book at last page read, in the Kindle app.

[ottischwenk]

Originally Posted by stumped

In the meantime, the workarounds are as simple as stop using the read button. Use CC to download then use any files app to locate and open the book with the default reader app. I do that now , for reading with moon, to avoid the clutter and confusion of having copies passed.

I wonder, but don't personally care, if read is also broken now for .aws on fire tablets, as those also have the reader baked into the Fire OS. I speculate there are more fire tablet users than bound.
The old CC version was pretty crap for Amazon formats on fire anyway, as it could not resume a book at last page read, in the Kindle app.

Are you joking or am I wrong?
I use CC because it gives me the same selection criteria as calibre.
I don't need it to download books, it can be done much easier (e.g. with sync applications) and using a file application to select one of more than 13,000 books is simply stupid.

This change makes CC pretty worthless. Unfortunately I cannot give 0 stars in the Play Store.

[stumped]

i understand where you are coming from. but this has been inevitable for 2+ years. The previous developer read the (google) writing on the wall and sold out, to avoid being in charge when it hit the fan. The 2018 threads are still there if you want a history

but its not anything the developers can change, its a ( IMHO) stupid "security" enhancement decision by google that is to blame. ( and a matching one over at apple).

all apps that depend on fire sharing to other apps are affected. You may think having to copy each small epub before viewing it is a hassle, just imagine what this change does for any video organiser app!

the only smart way forward that I see if for CC to buy into / partner with a reader app and integrate that, so that "read" does not call anything external and thus does not need to hand over a copy.

except for series info, moon can access and show much of the calibre data in book details, so switching the OPDS server directly into moon and mastering its shelf sesytem is another option

[stumped]

ps - took a bit of searching for- it was buried in a thread about adding shortcuts to homescreen - but here is the relevant history.

"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 responsible 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.
Last edited by chaley; 12-18-2019 at 09:27 PM."

[stumped]

i wonder if another fix is to add another button next to "read" that works like the "show in folder" option in windows, or the path:click to open in calibre

what's needed is something that shows the actual file so that tapping it will open it in the default reader app - thus reading it?

a possible problem is that AFAIK, there are no subfolders in CC, so your 1,300 books are all in one big folder on the device- thus show in folder is not helpful unless it can show the relevant bit of the folder list ?

a final suggestion is you locate and install the old 2018 version , then turn off updates. you have to Live with the known bugs of that but you get the READ mecahnism back. there used to be a link to one in a thread but you have to search, or trust a site that hosts old apk versions

[ottischwenk]

Originally Posted by stumped

a final suggestion is you locate and install the old 2018 version , then turn off updates. you have to Live with the known bugs of that but you get the READ mecahnism back. there used to be a link to one in a thread but you have to search, or trust a site that hosts old apk versions

It worked in the December 2019 version.

[stumped]

no such thing as a 2019 andrioid version. we went from july 2018 [ last release from previous developer to store] directly to the march / april 2020 releases [ from new developers] , nothing in between
anything you were running in december 2019 was actually a 2018 release

[PMrev]

Hello,

Thanks Stumped for communicating the information in regards to the updates to API's that required us to make this change. It's on many threads but you continuously inform users.

We are looking into adjusting this behavior and the LOE to do so.

We are aware of the Likebook issue and confirmed its related to this new behavior of handing a book file off.

I will follow up when we have more information in regards to effort required to change the behavior of sending a book file to the reader apps.

Thanks,
Alex

[stumped]

Forgive my ignorance but what is LOE ?

Also, is there a plan for the app version still offered in the Amazon app store?

Historically that has stayed in step with the Google store version ,but with some lag - maybe because Amazon approval process is slow and tedious?