[Kindle Touch] adding support for other ebook types

[LittleLui]

Hi everyone,

I'm trying to add support for a new ebook type to my kindle touch. I've implemented a suitable subclass of BookController, along with some of the stuff that goes along with it (Book, RendererCapabilities, ...).

Packed it all into a jar, signed it and placed it suitably on the kindle.

I added my BookController to /opt/amazon/ebook/config/reader_plugins.xml (referencing the jar's absolute path) and it gets loaded correctly, as is evident by my logging messages appearing in /var/log/messages.

My RendererCapabilities states that the BookController can handle files of type "test"; the getSupportedFileExtensions method is called at the expected time. I placed a few appropriately-named text files (eg. "foo.test") in the documents folder in USB mass storage mode (as i would do with any other ebook).

I also registered the reader booklet as an appropriate handler in /var/local/appreg.db:

INSERT INTO extenstions (ext, mimetype) VALUES ('test', 'MT:application/x-lui-kindle-test');
INSERT INTO mimetypes (ext, mimetype) VALUES ('test', 'MT:application/x-lui-kindle-test');
INSERT INTO associations (handlerId, interface, contentId, defaultAssoc) VALUES ('com.lab126.booklet.reader', 'application', 'MT:application/x-lui-kindle-test', 'true');
INSERT INTO associations (handlerId, interface, contentId, defaultAssoc) VALUES ('com.lab126.booklet.reader', 'detail', 'MT:application/x-lui-kindle-test', 'true');

That registration seems to have worked, as i can find it from my code:

 ApplicationRegistry ar = (ApplicationRegistry)ReaderSDKImpl.getBundleService(com.amazon.kindle.restricted.device.ApplicationRegistry.class);
String hid = ar.getHandlerIdFor("application", "MT:application/x-lui-kindle-test");
//hid now is "com.lab126.booklet.reader"

So, the system knows that the reader can handle the test files, and the reader knows my BookController can handle the test files.

However, there must be something missing, because the test files don't show up on the home screen.
In contrast, when I declare in my RendererCapabilities that I'm able to handle azw files, my BookController gets invoked when opening azws (which are of course correctly enumerated on the home screen), so it seems to really be a problem with the home screen just not showing my test files.

When i query the content programmatically, the test files also don't show up:

  private void testCatalog() {
      CatalogService cs = null;
      try
      {
          cs = (CatalogService)ReaderSDKImpl.getBundleService(com.amazon.kindle.content.catalog.CatalogService.class);
      }
      catch(ReaderException a)
      {
          log("cs can't be gotten",a);
      }
      //com.amazon.kindle.content.catalog.Predicate a = PredicateFactory.equals("location", getPath());
      CatalogEntry ces[] = cs.find(null, null, 1024, 0);
      
      log("ces: ".concat(String.valueOf(ces.length)));
      
      for (CatalogEntry ce : ces) {
      	LString[] titles = ce.getTitles();
      	String display = titles.length >= 1 ? titles[0].getDisplay() : "unknown";
      	log("ce: ".concat(display));
      }
  }

(for this to work i had to adapt /opt/amazon/ebook/security/application.policy, otherwise it would fail becaus it was missing some access rights)

Does anybody have an idea what i'm missing (apart from sleep)?

thanks in advance,
lui

[yifanlu]

Amazon's logs are very detailed. Try doing "showlog -f" in SSH while running your test code and see if it says anything.

[LittleLui]

Thanks, "showlog -f" was really interesting.

I watched the download of an azw coming in over the air via my @free.kindle.com e-mail. Apparently, several processes are involved, and they are communicating via lipcd.

lipcd-probe shows some interesting things, for one the possibility to change logging levels on the fly for most (all?) of the processes.

I think it might be possible to trigger the cataloguing/indexing with some lipcd trickery.
Google doesn't seem to know anything about lipcd though, so this might be difficult.

Well, logfiles have been captured and are waiting for me to read them, so maybe enlightenment is just around the corner

[yifanlu]

So I've looked more into creating reader plugins. I think you're error came from the fact that not all the methods you have to implement in your readersdk plugin are abstract. Some are defaulted to return -1, false, or null. I haven't played too much with it, but some examples are:

AbstractBook: public int getType() returns -1
BookView: public void drawPage(Graphics2D a) throws not implemented
RendererCapabilities: public boolean acceptsFile(String a) always returns false

I'm guessing one or more of these might be the root of your problem.

[LittleLui]

Well, AbstractBook.getType(), and RendererCapabilities.acceptsFile(String) i've covered, BookView.drawPage not (I don't get far enough to draw anything yet). But of course there's plenty more where those came from - I still have to analyze the logfile, probably there's something interesting in there.

For now I've stopped the reader plugin thingie and am dabbling with kindlets, which is currently much more rewarding. Of course the kindlet i'm working on now (crosswords) would also work great as a reader plugin, so i'm bound to come back to that sooner or later.

Originally Posted by yifanlu

So I've looked more into creating reader plugins. I think you're error came from the fact that not all the methods you have to implement in your readersdk plugin are abstract. Some are defaulted to return -1, false, or null.

[Lorphos]

I'm also very interested in adding support for new formats. However, I have a Kindle 4. Are there similar hooks on that device? Yifan, you mentioned the java on the K4 is obfuscated?

[ixtab]

Originally Posted by Lorphos

I'm also very interested in adding support for new formats. However, I have a Kindle 4. Are there similar hooks on that device? Yifan, you mentioned the java on the K4 is obfuscated?

I don't own a K4, so I can't really answer the first part of your question. However, concerning the second part (obfuscation): on both the K4 and KT, *class and method names* are not obfuscated. This is generally helpful, because it allows to understand the logical structure quite well.

However, both field and local variable names are obfuscated. So in general, all parameters and local variables are called "a", which can lead to confusion when trying to analyze concrete code. Still, this is much easier to understand than the completely obfuscated K3 framework.

[yifanlu]

Originally Posted by ixtab

I don't own a K4, so I can't really answer the first part of your question. However, concerning the second part (obfuscation): on both the K4 and KT, *class and method names* are not obfuscated. This is generally helpful, because it allows to understand the logical structure quite well.

However, both field and local variable names are obfuscated. So in general, all parameters and local variables are called "a", which can lead to confusion when trying to analyze concrete code. Still, this is much easier to understand than the completely obfuscated K3 framework.

Woah! You got a K4 that does NOT have obfuscated java? (parameter and local variables cannot be obfuscated. It's just that their names are never saved or are needed in the byte code). PM me please.

[ixtab]

@yifanlu: Ooh wait, I just double-checked it. I was assuming that it wasn't obfuscated because of the results from the localization stuff (resource bundle package names and class names looked "normal"). But now I took a closer look again, and the implementation is still obfuscated. Sorry for the confusion.

[aditya3098]

Bump (I am JUST OBSESSED with e pub)