We could leverage the Android SDK packages installation by deploying an operator (using the operator framework) instead of running a service update.

Suggested architecture:

• Create a config map with the android sdk config (define a couple of mobile ci|cd specific labels)
• The operator should watch this config map for changes and should change the config file in the android sdk shared PV + run the androidctl command to update the android sdk package (the same way we do it in the update playbook)

Some advantages for this approach:

• The android sdk config is handled by a config map object (created by the mobile ci|cd apb)
• We get more verbose logs for free by running it from the operator
• It might enable us to install additional sdk packages when a build is running in the future (so builds won't fail when trying to use a platform version that is not installed) - this will require a spike on its own