System Call Interface and operating system API

The android backbone is written on top of linux so not really. It is possible to write an Operating System in C++ and there are many ones out there albeit not popular. C++ gives you the OOP concepts you want while still allowing you to do the low level stuff that you need in order to communicate with hardware. C still is the language that most operating systems are written in (with some assembly backbone required) and this is because C is lightweight and personally I find it better just because it removes a lot of the OOP stuff that I find isn't needed to write an operating system (that's just my opinion though).

Technically it is possible to write an operating system in Java in a sense you would need to hook into C/C++ code (I can't remember how to do it in Java but I believe you can) which would in turn call on the assembly required to talk to some of the hardware. The java code would also have to compile directly to machine language instead of the current bytecode scheme that runs on the Java Virtual Machine.

The high level concept of the OS could be done in java but the problem is that a lot of the functionality would have to exist in another form as doing some of the required things for handling data from devices and such cannot easily be accomplished in Java if at all.

I think you are confusing inter-process (user) space, intraprocess threads, and system space. So let's start with some definitions.

Threads belong to a process. A process can run within user space and system space. Which space a process belongs to is a function of how it is invoked.

System space tends to be the lowest level and is where protected or kernel processes run. Typically, they are owned by the system itself.

User space tends to be higher level and has less privileged processes.

Inter-process (user) space threads can be thought of as threads belonging to separate processes.

Intraprocess threads can be thought of as threads belonging to a single process. And that process may be running in user or system space.

So when you call:

pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM);

What you're really doing is moving the thread from being part of the rest of that calling process and moving it out into user space. Effectively it makes the thread a new process and is equivalent to fork, but I'm not positive on that aspect so don't quote me on it.

I think your confusion comes from the _SYSTEM portion of that definition. However, an operating system wouldn't necessarily want a process to be able to move from user space into system space as that could lead to an undesirable privilege escalation for that process. The kernel rightfully doesn't trust user space processes as they have been historically proven to be rubbish (from the kernel's perspective).

Said another way, that pthread_attr_setscope call doesn't allow you to move from PCS into SCS.

The man page is semi-helpful in understanding this.

PTHREAD_SCOPE_SYSTEM
The thread competes for resources with all other threads in all processes on the system that are in the same scheduling allocation domain (a group of one or more processors). PTHREAD_SCOPE_SYSTEM threads are scheduled relative to one another according to their scheduling policy and priority.

_{emphasis added}

Note the final clause in the part I emphasized: "that are in the same scheduling allocation domain". And also note that it makes no mention of being able to switch to a different scheduling allocation domain.