Clickers, love 'em or hate 'em

[Renate]

No, I don't have a Boox Remote. I probably wouldn't buy one as my interest is only academic. I have various Bluetooth remotes and I have custom circuit boards on order for my "real" one.

@arooni You have a Nova Air? I think that's basically the same as my Poke3 as far as the essentials go, Qualcomm processor, Android 10. Magisk should work?

$ cat /proc/cpuinfo
...
Hardware        : Qualcomm Technologies, Inc SDM636

[arooni]

I was just paranoid of installing magisk in case I bricked this device.

Does it install without messing with the bootloader? Then I gain root? Have you found this messes with future updates?

I usually end up installing it when the warranty is over.

And yes I have a Nova Air.

[Renate]

If you want to play it safe, you can do as I do.
Get your Magisk image made but don't even install it in the boot partition.

C:\>adb reboot bootloader
C:\>fastboot boot magisk-whatever-1234567

A full reboot will bring you back to stock (in case you screwed something up).
The whole point of Magisk is to leave the system partition as stock so that incremental patches will work.
The only bad part of this is that if you are in the forest and have to reboot you will have to reboot to stock since you don't have fastboot away from your desk.

I've done some more experiments to determine how picky the system is with screwing around with framework-res.apk
It seems that deleting those two JSON breaks things.
The only thing that I've found yet that works was what I originally did, that is, changing the name in the zip local & global headers for the two files = 4 places.

There's another gotcha. If you screw up with the Magisk module it won't complete the boot and you won't have ADB. With stock (i.e. unrooted) you won't have access to the location where the Magisk module is to fix it.
I have another boot image that I made before Magisk that is "insecure", you can simply setuid to be root. This is not a good idea while running normally, especially with strange apps or WiFi on. Then I can access the bad Magisk module and fix it, then reboot to Magisk.

I don't know if it's cache or oat or what that makes the system so picky to changes. I'll have to figure it out so that I can do more patching. I need a good recovery too.

@arooni Hey, how about giving me that cat /proc/cpuinfo?

[arooni]

Originally Posted by Renate

If you want to play it safe, you can do as I do.


@arooni Hey, how about giving me that cat /proc/cpuinfo?

NovaAir:/ $ cat /proc/cpuinfo
Processor : AArch64 Processor rev 2 (aarch64)
processor : 0
BogoMIPS : 38.40
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x51
... blah blah blah detials about each one.
Hardware : Qualcomm Technologies, Inc SDM636

[Renate]

Thanks.
It seems that Onyx tries to standarize a lot on hardware and software, the biggest difference between models being touch screens/digitizers. I read about the old models with RockChip processors.

So, if you want to go through the trouble, you can backup your whole device (without even rooting) or grab a copy of recovery for Magisk using Qualcomm EDL mode. There's a bit of a thread on that here: https://www.mobileread.com/forums/sh...d.php?t=339471

[Renate]

Whee! My boards came in and I built my clicker.
Electrically everything was 100% but the case was really designed for 1/32" PCBs (instead of 1/16". I had to grind down some posts in the case 0.75mm, that's how tight the tolerances are. It looks the same as the raw case except for the advertising/pairing/keystroke LED. I'll add a photo later. The F keys don't seem to work. Oops, that's part of the keypad stuff that I nuked!

[Renate]

I'm really loving my clicker. Some people may think it's useless to have a remote for something that's within arm's reach. Still, it keeps your fingers off the screen.

One button (just PgDn) would not be sufficient. I'd tried that already with various hacked "selfie" clickers. Two buttons was the minimum (PgUp, PgDn) as I often go back to check what was on the previous page. With auto repeat working it's quite convenient for flipping back a bunch of pages. That's certainly easier than poking/swiping multiple times with your finger! The case I bought comes in 1, 2, 3, 4 button versions but they are all the same case so you might as well have the 4 button version. The "5-way" clicker above had those small buttons that were fairly stiff so you really had to hit them with a thumbnail. For the new clicker I selected the softest touch switches in that series. I push the buttons with the pad of my thumb.

As far as making this available for others, I'm not sure that that will work. The parts are about $25. The Cypress Bluetooth module is a bit of a pain to program (unless you have the recommended $100 programmer (which I don't anyway)). The soldering is not rocket science, but also not for first-time solderers. If I made another I'd switch to 1/32" PCB (from China) and get a pushbutton with a little less height.

Edit: I set the keys to (CCW from upper right) PgDn, PgUp, Menu & Sleep. I just love the sleep button! It sleeps the Poke3 but also turns off the clicker immediately.

[mergen3107]

Congrats!
You have finally made your Zen clicker!

[Renate]

And another thing. (There's always another thing.)

I've seen a lot of Bluetooth devices and a lot of them seem flakey. For no apparent reason they sometimes lose their connection and go into "advertising" (i.e. flashing) mode for a bit then they reconnect.

I've found this Cypress module to be reliable enough that when you lose your connection you can definitively say that the other end was shut down and you might as well shut down yourself instead of pointlessly trying to re-establish a connection.

That means that either hitting "Sleep" on the clicker or turning off the Poke3 manually will shut off both immediately.

[Renate]

Ok, here's a tip (that I just discovered for myself) for you app developers.

When a Bluetooth clicker appears Android says to itself, "OMG, something just appeared that can do a page down" and it restarts the foreground application so that it can take advantage of this startling info. In AndroidManifest.xml you can put:

android:configChanges="keyboard|keyboardHidden|orientation|screenSize|uiMode|navigation">

This tells Android to keep its hat on and that you can roll with the punches without your app having to restart. Most of the clauses you will recognize but the uiMode and navigation were new to me. If you want, you can address the changes in onConfigurationChanged in your Activity.

All of this only comes into question if you connect your Bluetooth device after your app is already started.

[Renate]

When you have a remote or a clicker you'd like to know when you're connected. Not something like an icon on the status bar (which if you're in a full screen reader you can't see anyway), not something app-specific that doesn't works everywhere, just something to give you a quick confirmation that you're connected. It's kind of surprising that there is no option for this in stock Android. So, I wrote one. If there is interest I'll release a more polished version.

[pazos]

Originally Posted by Renate

Ok, here's a tip (that I just discovered for myself) for you app developers.

When a Bluetooth clicker appears Android says to itself, "OMG, something just appeared that can do a page down" and it restarts the foreground application so that it can take advantage of this startling info. In AndroidManifest.xml you can put:

android:configChanges="keyboard|keyboardHidden|orientation|screenSize|uiMode|navigation">

This tells Android to keep its hat on and that you can roll with the punches without your app having to restart. Most of the clauses you will recognize but the uiMode and navigation were new to me. If you want, you can address the changes in onConfigurationChanged in your Activity.

All of this only comes into question if you connect your Bluetooth device after your app is already started.

It isn't a good advice to tell people to handle the changes themselves unless they're programming a game or the app cannot/doesn't follow android best practices. It is usally way better to let the framework to restart you app and recover the previous state from the bundle you get for free in onCreate.

99'9999% of apps handle orientation without problems and without the users noticing that the app was destroyed and recreated based on previous state.

Also keep in mind that screenSize et al can modify your device's dpi and require a whole different set of drawables. Handling drawables by hand isn't funny

[Renate]

Google is quite dogmatic in saying that you'll burn in hell for accepting configuration changes yourself.

A configuration change is a resource configuration change. Sure, if what has changed affects the selection of resources restarting is the easiest way to deal with it. If your app uses different layout xml for portrait and landscape you'll probably want to restart. Many apps don't use separate layout xml. Do you really need to restart just because a hardware DPAD became available?

{1.0 311mcc480mnc [en_US,de_DE,fr_FR] ldltr sw331dp w669dp h336dp 320dpi nrml long land finger -keyb/v/h -nav/h winConfig={ mBounds=Rect(0, 0 - 1339, 720) mAppBounds=Rect(0, 0 - 1339, 720) mWindowingMode=fullscreen mActivityType=standard} s.331 spnnull gidbae0000000000000}

If I connect a clicker that -nav/h switches to dpad/h. Do I really have to restart?

Many of these I didn't say. So if somebody swaps a SIM card while my app is running it will be forced to restart!

• density
• fontScale
• keyboard
• keyboardHidden
• layoutDirection
• locale
• mcc
• mnc
• navigation
• orientation
• screenLayout
• screenSize
• smallestScreenSize
• touchscreen
• uiMode

[pazos]

Agree with you in both 1) Google being dogmatic and 2) you can do whatever you want.

Even when both are true I can't see a good reason to handle changes yourself, unless:

- You want to override its behaviour (ie: whatsapp disables the account on sim changes and requires reactivation)
- You're forced because of reasons (ie: KOReader handles input/rendering in a single thread where the LuaJIT VM runs. Receiving an onDestroy() call on the input handler efectively destroys the single instance activity)

Managing configuration changes yourself without adding any logic to handle it differently is like overriding a method to add a comment: useless. Specially if you let the framework to manage your activity lifecycle on other configuration changes. If it works well on orientation changes (the app is destroyed, recreated and rendered correctly with previous data without the user noticing a delay beyond the system animation) it should work the same way when you attach a bluetooth hid device.

Does the activity need a restart?. Probably not. Does the restart hurt your user experience? It shouldn't if the app is well made.

I saw quite a few apps whose onCreate method is a god function that covers 80% of the activity logic. In those cases handling changes yourself might hide the problem a little bit. But the proper solution would be lazy loading, not preventing that method from being called.

[Renate]

I'm not handling changes myself.
I'm ignoring changes that do not affect anything.
I have never overridden onConfigurationChanged.