A few of my older apps rely on a common principle of having a permanent background service. This broke with the API changes in Android O & P (API 26).

Trying to fix T3 & RTAC in-situ has been a bit of a PITA, so it’s time to do an isolated “canonical example” app to figure that out. But first I need to understand why I have a background service and how to adjust it for these API. Also to clearly list which API levels are the issues.

Existing cases:

• RTAC:
• Needs to run on Hi10 tablets, Android 5.1 (API 22, Lollipop MR1).
• Permanent background service.
• Designed to keep the app alive at all times, even if not in foreground. Keep all the network connections active. Wakelock to make sure the tablet never sleeps.
• Notification shown when main activity is in background.
• DccThrottle:
• Same as RTAC. Permanent, active even when in background.
• Bearing v1:
• Similar to RTAC. Permanent, active even when in background.
• T2:
• T2 is API 9+, T3 is API 26+.
• Job-oriented background service.
• Started by “check” menu, alarm, or receiver, only for the duration of the operation.

The needs for T3 are very different and ideally we would not use a service for that if we can avoid it. The only reason a service was used here is because that was the recommended design at the time. I understand OS requirements can change, but it’s somewhat ironic an app breaks when it was following the recommended design, with undertones of “you’re doing it wrong”.

The T3 case was handled in 2019-07-08.

It uses:

• JobService to schedule a task.
• Still relies on an UpdateReceiver starting an actual Service.
• Boot_Received triggers the UpdateReceiver.

Now the question is whether a service is even needed at all. Does the new API offer something else?

https://developer.android.com/about/versions/oreo/android-8.0-changes.html#back-all 

In theory that doc seems fine: start a service using startForegroundService, then call startForeground with a notification  In practice that seems to fail, and the service still gets killed 5 minutes later when testing on an Android O device or emulator.

There’s a lot of that on SO:
https://stackoverflow.com/questions/49637967/minimal-android-foreground-service-killed-on-high-end-phone 

Thus my suggestion is to create two simple samples/demo apps:

• T2 case: a “short job”, triggered by a button, an alarm (specific time), or a boot receiver.
• Permanent case (e.g. RTAC, DccThrottle, etc) of a permanent “foreground” service.

For the latter, integrate some external lib such as Doki that shows details from dontkillmyapp.com for a specific device.

https://bitbucket.org/ralfoide/misc-exp-public/src/master/android/  is a good place to store these.

What is the dev that I want to be doing right?

I want some projects that I can demonstrate visually -- most of my stuff is often very cryptic, abstract, with little to see. By that I mean have a nice write up, maybe a video, and have a little collection of them. Experimental projects would be best for that.

• ESP32-CAM in train context.
• Could be as a simple web server demo with an android viewer. For example placed in scenery, or from a top view.
• Power from USB brick.
• Point is to show the simplicity and versatility of this.
• ESP32-CAM with OpenCV.
• That requires a bit more research.
• Use integrated web server to see output.
• Point is to demonstrate we can do embedded detection on the ESP32.
• ESP32-CAM as “occupancy detector” without OpenCV.
• This is the simple “things move in the image” kind of demo.
• Use integrated web server to see output.
• ESP32 with OLED send a JMRI JSON.
• The OLED is nice because it adds a visual component. It makes it less abstract.
• Point out that the OLED is a nice status/debugging tool.
• This is the kind of thing to do in MicroPython as it becomes trivial.

One tutorial for later would be “hacking the NCE AIU”, for example for the EB1. This requires more thought to explain why it’s useful for. It has less appeal (lesser known hardware).

4 x ESP32 boards compared, all with an OV2640 camera module:
https://www.youtube.com/watch?v=5IhhyJjjCxo 

Possible applications? I’ve been looking at the cheapest way to add video to train layouts with at least 2 goals, if not more:

• Video-based train automation.
• In-car video streaming.
• Single/multi view on remote monitor. E.g. monitor hidden staging yard(s) or tunnels, or display activity on a remote monitor -- any place where there’s motion.

For each of these, my concern is footprint, price, and power. Each time I operate under the expectation I can offset any processing to a local laptop or tablet or similar.

For example, for streaming the expectation is that the camera can either send a constant stream and the computer does motion detection, or the camera can do basic detection and only transmit when there are changes. A mix is possible (e.g. non-sophisticated change detection on the camera, then a better filtering at the computer level).

In this case, the value of the ESP32 is fairly reduced. It only needs to act as a crude frame server. The benefits are a small footprint, and real 1080p or better.

The contenders are mini pinhole wifi cameras like the one I tried earlier. This would be an almost ideal choice if it were really a 1080p and not a marketing gimmick using a fairly old 720p @ 30 Hz.

In the "don't need one right now, just doing my research" department...

There's a new RPi 4 out there, announced in June, and this is a pretty good and balanced review:
https://www.techrepublic.com/article/raspberry-pi-4-model-b-review-this-board-really-can-replace-your-pc/

Direct comparison to the previous RPi 3:
https://www.androidcentral.com/raspberry-pi-4-vs-raspberry-pi-3

As always with the Pi, there's the hype and reality:

• Element14 (Newark) the official distributor is waiting for stock for the 4 GB version. They sell it at the official MSRP of $55 (+ s/h) bare-bones.
• Amazon: Can't find a bare-bone one, but there are kits for the 4 GB version (with power supply, etc) for $99 (also waiting for stock). (example 1 and example 2 ... these are good kits)

When comparing to "something else", the "kit" price is often a better indicator in my book since we're often comparing it with another mini-PC that has a power supply, storage, and a box. In this respect, it's interesting: years ago I was expecting a full RPi 2 kit to be around $100, and here a full RPi 4 kit is still around $100.

Video review from Andreas [link?]:

• Speed is only 30% marginally faster in tests.
• Can get really hot during intensive computation.
• Ethernet speed is now good.
• Nowhere near a “desktop” computer beside claims.
• Micro HDMI instead of full size HDMI.

Perf benchmark:
https://core-electronics.com.au/tutorials/raspberry-pi-4-vs-3-model-b-performance-benchmark.html

The dual HDMI output can be a good solution for building e.g. a public display.

In the Instant Apps for Game on the Play dev guide, I noticed they officially support a plugin for Unity as well as one for Cocos2d.

It would be interesting to try this to see how an android game can be made using that: https://cocos2d-x.org/ 

https://digitalocean.cocos2d-x.org/CocosCreator/v2.1.2/CocosCreator_v2.1.2_20190716_win.7z 

513 MB download… will skip for PA.

The quick start here:

https://docs.cocos2d-x.org/creator/manual/en/getting-started/quick-start.html 

Shows:

• It seems to come with an editor, kinda like Unity.  Asset library, etc.
• Programmed using JS, CoffeeScript, or TypeScript.
• The example uses the “old” property-dict style for creating a JS class.
• “Custom components” are JS classes with properties.
• Creator “nodes” are manipulated.
• A custom “jump action” is created by combining interpolators.
• Typical key events handling.
• “Prefabs” are used to duplicate assets.
• Object collision is programmatingly done by computing asset-to-player distance.
• Overall “score” audio and effects.

Overall it seems like a (suitable?) replacement for Unity in 2d, as long as JS is acceptable. Using TypeScript or CoffeeScript may make the JS a tad more palatable. Integration with Android remains to be seen, as well as runtime size.

A while ago I wanted to take a consistent approach at splitting my projects into a “UI vs core” pattern. My old C# skeleton generated 2 libs upfront for that. In other android apps, I have either an android lib or at least clear packages “core vs ui”.

Looking at something like Flutter, the benefits would be useful if the app and UI is using one framework and then the “core” of the app uses another framework, namely a POJO or at least an Android lib. In the case of a game, the latter could be a Unity library.

When doing a pure Android app of a limited scope, there’s little value in that separation. It becomes more useful when I try alternate frameworks, for example Flutter or Kotlin. The idea is that if I write the UI part in Flutter now and the framework falls in desuetude, I could rewrite just the UI later.

One thing I noticed is that if I do not force myself to do the split upfront using actual libraries, it will not happen easily after. Forcing to have an android app + an android lib imposes some constraints in the import/dependency structure. It forces us to make callbacks instead of direct bi-directional calls. It forces us to make the boundaries clear. Dagger would help a bit to ease using one with the other.

As far as patterns go, there’s MVP and MVC. I suggest a mix, which I’m calling MCVP:

• Model: Model data/classes, in the core feature library.
• Controllers: Action classes acting solely on the model, in the core feature library.
• Views: Pure UI elements display model, in the app/ui library.
• Presenters: Action classes managing the interaction, in the app/ui library.

The app logic would be both in controllers and presenters. The controllers are purely model-oriented and by having them in the core lib, they have no impact on the UI. The presenters on the other hand coordinate between the views, model, and controllers. They are the “business logic” that is located at the app/ui level.

As a graph, we would have:

[model] ⇐⇒ [controllers] ⇐⇒ [presenters] ⇐⇒ [views]

It’s time to get a look at Flutter… What would this be good for?

https://flutter.dev/docs/get-started/install/windows

Now the question is what will be the throw-away project and the goal for it?

One thing Flutter targets is Android vs iOS and then “rescalable” app for Chrome OS.

It does not do “web apps” per se. It is not a server-side html thing.

I was going to start a “Service [idea]” doc as a Summer Project, but honestly at that point it’s more like a reboot as it feels really deja-vu:

• Menerba is the obvious canonical example.
• Home Monitor App.

Not every far:

• Mobile dev and Hint v3.
• Ikaria and Ikaria v2.
• And of course “\pɔʁt.na.wak\” as a meta-meta project.

Part of the motivation for Portnawak was exactly what the name says, it’s a place to put temporary projects without the pretense of ever finishing them. They can be left there and not be too visible, so it’s not an inconvenience to anyone.

This looks worth looking into for the kids:

https://microbit.org/guide/quick/ 

Should be around $17 per kit.

https://www.adafruit.com/product/3362 (properly packaged I guess)

https://amzn.to/2Dh7Wb7 (not the full kit, see comments)

Showed that to the kids. Is it interesting? Maybe. Should I get one? Nah. OK fine I tried.

Of note:

• RPi 1 = 700 MHz Arm11
• RPi 2 = 900 MHz ARM Cortex-A7, 1 GB RAM (all 2 and 3 models)
• RPi 2 = 900 MHz ARM Cortex-A53
• RPi 3 = 1.2 GHz ARM Cortex-A53, arm64.
• RPi 3 B+ = 1.4 GHz ARMv8, arm64, 1 GB RAM.
• USB/Eth combined with 30 MB/s max.

https://www.zdnet.com/pictures/top-12-raspberry-pi-alternatives-2018-edition/

Similar clones:

• NanoPi NEO4, $45
• Rockpi4
• Libre.Computer “Le Potato”, $45 on Amazon with 2 GB RAM
• UDOO makes the NEO (an RPi like), an x86+arduino, and the Dual is some kind of Android/Arduino DUE mix. One has SATA.
• VoCore has a super-mini linux box (1 inch square), limited RAM, etc.

Depends on needs:

• For very low computing, the VoCore seems interesting. The Nano/Rock Pi are just clones with no specific advantages (cpu speed maybe?)
• Le Potato looks interesting, until one reads the comments about the limits of the Linux distro with specific builds made for it.

The problem with those is the custom linux kernels. It means no “default debian” install (even with the RPi3), but at least Raspbian is well maintained (and the official way to go). For some of the other boards, the deal is more muddy, with typically a single image to deal with, no updates. For example the BeagleBoards have precompiled kernels and linux images to be installed as a whole. This is good from an IoT “fire and forget” standpoint but much less attractive to customize the distro & keep up-to-date with security patches.

Maybe I should take another look at BeagleBone/Board (board matrix): the Black is a bit under an RPi 3 (1 GHz Arm A8, 512 MB RAM, $65 Amazon, $55+s/h e14/mouser), the SanCloud version has 1 GB RAM & Gigabit eth ($60-80). [Note: names were BeagleBoard before 2010, and BeagleBone after 2010].

I happen to have a BeagleBone Black. I should use it. Which rev? What specs?

• Markings: “PCB Rev B3” (in black other side of power plug). “STM-5 94V-0 1013” next to eth, proc “XAM3359AZCZ100”, eMMC U13 “3DA18 JW896”, DDR3 U12 “2ZE12 D9PXV”.
• BeagleBoard images & instructions: https://beagleboard.org/latest-images
• List of revision changes: https://elinux.org/Beagleboard:BeagleBoneBlack#Board_Revisions_and_Changes
• Rev B has 2 GB of eMMC (Armstrong Linux pre-installed); Rev C has 4 GB of eMMC with Debian pre-installed.
• The one I have appears thus to be a Rev B with 2 GB of eMMC.
• Confirmed by eMMC Micron JW896 [FBGA part search] ⇒ Micro part MTFC2GMVEA-0M WT, and “MT FC 2G” is the Micron model code for a 2 GB NAND Flash [link].