1

Since Android Things only runs one app at a time, I'm not sure how the rules differ from normal Android OS when it comes to killing/backgrounding/resuming a process.

My Android Things use case is not trivial. I'm controlling actuators with PWM channels. The problem is if I set a "move command" and then there is a fatal exception or other such interruption, my app is crashed but the actuator arms keep moving (because the PWM shield retains its power and values)! As these arms are controlling a moving boat, this is quite dangerous.

Is there someway, somehow to intercept the killing of the process so I can get my PWM "zero out" commands in? Or is there someway to game Android Things to immediately boot some other process that does this after my main app dies?

honkbert
  • 135
  • 1
  • 7

2 Answers2

2

Since Android Things only runs one app at a time, I'm not sure how the rules differ from normal Android OS when it comes to killing/backgrounding/resuming a process.

This isn't quite true. Android Things has the same semantics around multiple foreground and background apps as an Android mobile device. However, since there is no default app launcher, you have to define an application to capture the default HOME intent and become the foreground app. From this application, you are free to start other applications in the background as you see fit.

Is there someway, somehow to intercept the killing of the process so I can get my PWM "zero out" commands in? Or is there someway to game Android Things to immediately boot some other process that does this after my main app dies?

Android restarts the HOME activity automatically if that app were to crash (unless you've launched other activities on top of it, which isn't necessarily recommended unless you have a UI). You could use this to initialize your hardware to a default state.

Another option is for your motor driver logic to be run in bound services in a background app. This would allow the main app to run as a supervisor (it gets notified when a bound service dies) and reset the PWM (or restart the service, which initializes the PWM correctly).

devunwired
  • 62,780
  • 12
  • 127
  • 139
0

I'd add to the previous answer that is a good idea to reset the state of the hardware components inside onStart, and to add proper exception handling (i.e. on the case something gets disconnected accidentally)

shalafi
  • 3,926
  • 2
  • 23
  • 27