I would argue IntentService is not a framework implementation of the command-executor design pattern, because it does not meet the requirement of the separation of application logic and application context.
The command-executor pattern is like providing a button on a remote control to replay some action(s) on-demand (dim the lights, close curtains, turn on Barry Manilow) no matter who presses it in whatever context. Command-executor is analogous to materialising a personal assistant who then does a bunch of predetermined tasks for you on-demand.
On the other hand, the use of the IntentService class is analogous to a pedestrian hailing a taxi cab or a pub patron flagging the bartender: The agent requests a service (expresses an intent), the agent enters a queue to receive the service, the agent finally receives the service. Unlike the command-executor, this sequence requires the participation of the agent, which itself requires that the agent be in the right kind of context to (want to) receive the service. But this is not what the command-executor pattern prescribes. Indeed, the API class overview for IntentService in the link you provided suggests that the IntentService class fits another established design pattern:
This "work queue processor" pattern is commonly used to offload tasks
from an application's main thread. The IntentService class exists to
simplify this pattern and take care of the mechanics. To use it,
extend IntentService and implement
IntentService will receive the Intents, launch a worker thread, and
stop the service as appropriate.
In a sense, the IntentService could be considered a command-executor if only the subject of the service could also be included in the abstraction. So for our analogies, if at any time we wished, we could invoke a command to "send my niece Suzy the birthday present I bought her" or "send me to Beijing to complete the business merger", then IntentService might be a command-executor. But when we state the comparison this way, it becomes clear IntentService could not be command-executor, because these events are dependent on context in the sense that they need objects or agents' participations prior to being able to run. This is not true for command-executors, which package all the necessary components for ready replay at any time.