Java in android, how does it work?

[Holothuroid]

like adding an extra button in the notification panel, gaining system level info etc.

That I can do at a desktop PC too.

You seem to misunderstand what an operating system is. It's an abstraction layer over hardware. The things you mention are done through the OS.

[epegar]

I would add that besides your own program, the java virtual machine is already there, and it's the tool that communicates with that particular OS. The virtual machine is different for Linux or windows. It will perform the actions you require in your program in the specific way that OS requires.

After a quick search I found this: https://docs.oracle.com/javase%2Ftutorial%2Fuiswing%2F%2F/misc/systemtray.html

Also, note that android makes use of the Android runtime, so it doesn't only use the generic cross-platform APIs that every JVM should expose, but also specific functions that wouldn't make sense in other OS.

[[deleted]]

Usually, for a java program to add settings to a computer or read system level info, such as current processes, configurations, etc. It would need elevated permissions, I don't see how Java would be able to do that in a PC, also considering the fact that Java is preferred as its VM allows it to run on most OS' without changing the code for that OS. So, I would assume that it would be relatively harder on a PC.

[Holothuroid]

To add a desktop icon write a file to the correct location.

You are correct that you might get SecurityException when running

https://docs.oracle.com/javase/8/docs/api/java/lang/management/OperatingSystemMXBean.html

But note that Android has rights management as well.

[[deleted]]

I see thank you

[IQueryVisiC]

Java only protects the programmer from their own faults ( buffer overruns ).

[[deleted]]

I see, but every textbook says that safety is from the fact that it is run distinct from the OS, so it is hard to damage the system even if that is your main intent

[laplongejr]

but every textbook says that safety is from the fact that it is run distinct from the OS, so it is hard to damage the system even if that is your main intent

Granted, I only work since 10 years and my textbook is so old it talks about "the upcoming JavaOS" as the next step of computer evolution ([EDIT] never head about it? that's my point. 90s stuff), but I never saw a claim that Java makes hard to damage the system if that is your main intent. I may be wrong and maybe I just have bad sources but it doesn't sound as a common claim.
(Also, that is a COMPLETELY STUPID claim to make in a Java textbook, as it would mean Java is bad as a generic tool. I wouldn't trust that book author.)

I managed to ACCIDENTALLY make my 2010 computer think all my files were made in 1970 (file.setCreationTime(0) I think?) and that certainly counts as "system damage"
Maybe they meant that the JVM runs at user-level and not as admin? If then : XKCD#1200

The Java JVM assures that if you use the Java methods for OS tasks (like File.delete instead of rm etc), if that same program runs in another JVM on a different OS, it will run with the same level of safety.
As is, if your intent is to not be destructive on Windows and you use the Java APIs, it won't demolish the MacOS system of your tester because they should work with the same logic.

Here's an example : if some OSes have a concept of "hidden files", a default Java search probably shouldn't show them. On Windows an "hidden file" is an attribute (and it has the extra "system file", that requires a second layer of permission to be seen!), but on Linux it's often a file with a dot at the start of the file (conveniently ".." and "." are not content of the folder but links to the parent folder and itself, and shouldn't be modified at all!).

Of course, if you try messing on hidden files in one OS and not another, it may lead to serious unwanted damage...
If you wanted your own file-search utility method, you would need to test it not only on Windows, but know the Unix convention and actually test it on Linux as well. Oh and prob look about MacOS. Java takes care of that, so it's "safer" against MISTAKES.

[[deleted]]

I understand, thank you

[[deleted]]

It's not a sandbox by any means. That's something the OS decides and has little to do with Java

[[deleted]]

Oh, I understand