Ok I see what your situation is. And I'm curious, because this is sort of my thing. I don't think allowing greedy services with a big red warning would be a good solution for you either because your users would tire of seeing the warning, even if only at boot.
I would put a service-starter service in the device images. I see that might be a problem, too, because it seems like you are only "lightly embedded," with multiple hardware platforms. But this could be a really lo-impact thing for your hardware partners and relatively clean. Alternatively, provide a modified launcher, if you are not already replacing the launcher with your own embedded app, that tickles the service on startup. There are probably other advantages to having your own Home app if I understand your situation correctly.
Google has to be heavy handed because too much mobile development is crap, and a low-bidder contract development shop wouldn't hesitate to take the anti-social way to an implementation if they could. The road to hell is paved with cheapass outsourcing.
We experimented with a lightweight bootstrap service, but there was too much resistance from the manufacturers.
It'd pretty much require changing our contract to have much more expensive terms because from their pov it crossed the line from them providing pre-installed software (our apps) , to them providing custom devices ("our image").
I also tried some tricks with replacing the launcher since we have full root access, but the launcher process was getting killed almost as often as our custom services.
Since I moved to a single-process model I've had fewer killed services, but we still have the AlarmManager kicking them off just in case.
A lot of the moves Google's been making, from shutting down file uris for content providers feel like they're meant to shut down the "easiest way out for developers", things that are easy for devs, but bad for the average mobile user, but they're also hurting Android for other usecases. I guess the plan is to push Brillo for that, but being able to leverage Android's ecosystem on embedded has some advantages
You don't need any special access to replace the launcher. They just need to set your Launcher as default as part of the pre-load. Since I don't know your product it's a little hard to say but the combination of a Home app that check on configuration sanity and a watchdog, which it sounds like what you are using AlarmManager for should do you.
No, we do something like "bespoke" digital installations for different brands, sometimes it's simple digital signage, sometimes it's stuff that's a little more interactive, but we try and centralize the apps involved on a platform we built on one specific Android device which has now spread out onto different models for certain clients that had special requirements like large touchscreens
I would put a service-starter service in the device images. I see that might be a problem, too, because it seems like you are only "lightly embedded," with multiple hardware platforms. But this could be a really lo-impact thing for your hardware partners and relatively clean. Alternatively, provide a modified launcher, if you are not already replacing the launcher with your own embedded app, that tickles the service on startup. There are probably other advantages to having your own Home app if I understand your situation correctly.
Google has to be heavy handed because too much mobile development is crap, and a low-bidder contract development shop wouldn't hesitate to take the anti-social way to an implementation if they could. The road to hell is paved with cheapass outsourcing.