SoylentNews is people
SoylentNews
from the if-you-have-to-ask-the-price... dept.
Galaxy S20 Ultra to come with a whopping 16GB of RAM
After the recent leak of live pictures of Samsung's next flagship smartphone, the Galaxy S20, more details have started to trickle in about the upcoming device.
[...] we're getting three sizes: the Galaxy S20, Galaxy S20+, and the highest-end phone, the Galaxy S20 Ultra. In the US, they're all going to be 5G with Qualcomm Snapdragon 865 SoCs, and internationally you should be able to find 4G and 5G versions with Samsung Exynos chips.
[...] Max Weinbach, the XDA author who scored the live pictures of the Galaxy S20, has some spec info.
The S20 Ultra 5G is going to keep the SD Card slot. Support for up to 1TB.
It will also be available in 128GB/256GB/512GB and have a 12GB and 16GB RAM option.
108MP main, 48MP 10x optical, 12MP ultra wide.
5000 mAh battery with 45W option fast charge. 0 to 100% in 74 min.
— Max Weinbach (@MaxWinebach) January 13, 2020
16GB of RAM would be a new high point for smartphones. That is an absolutely ridiculous amount of memory and would outclass many laptops out there, which typically start at 8GB of RAM. As for what you're supposed to do with all that memory, it might be useful for Samsung's DeX desktop mode, which lets you kick the phone over to a full windowed PC interface by hooking it up to a monitor, mouse, and keyboard. A baseline of 12GB—the highest-end config for the Galaxy S10—would be a big increase, too. As connected Samsung leaker Ice Universe points out, this will most likely be LPDDR5, which Samsung has already put into production.
The Galaxy S10 came in storage tiers of 128GB, 512GB, and 1TB, so the listed S20 tiers of 128GB, 256GB, and 512GB would be a downgrade. The good news is that there's still a MicroSD slot—on the "Ultra" model, at least.
Also rumored are a 5000mAh battery and 120 Hz display.
Also at: https://www.theregister.co.uk/2020/01/14/samsung_galaxy_s20/
(Score: 4, Informative) by DannyB on Wednesday January 15 2020, @04:36PM (3 children)
That is true.
That is NOT true.
The Java source HAS ALWAYS been compiled by a standard Java compiler into JVM bytecode. In the development system. Similarly other compilers (like Kotlin) take take other source codes and generate JVM bytecode, at development time.
The Android development tools (Android SDK) then build an APK file with Dalvik bytecode. Part of this process involves compiling JVM bytecode into Dalvik bytecode. And yes it is an actual compiler even though it's "source" is JVM bytecode. (unrelated: JVM's C1 and C2 compilers also take JVM byte code as their "source" code.) All of the JVM bytecode (even if not from "Java source") is compiled to Dalvik.
When the APK is built by the Android SDK, your project might include JAR files (jvm bytecode) that came from compilers other than Java source code. Those JAR files are also compiled into Dalvik. Java is not the only source code language that compiles into jvm bytecode. Once the APK is built there is no JVM bytecode. (but see possibility below)
To be pedantic, "the language" runs. All of it.
The Android runtime has a subset of the APIs Java programmers are accustomed to. It's not everything Java programmers might want. But is a large and useful subset. A lot of things don't make sense on a phone, like CORBA or RMI, for example.
In Android prior to "N" (Nouget) Android was based on (a subset of) Apache Harmony, which was about Java 1.5 level.
Starting with Android "N" (Nouget), Android was based on (a subset of) Open JDK. (hey Oracle, if you don't like Google using Apache Harmony, then Google will switch to genuine Open JDK!)
I have not used Android development tools since Android N, so I don't know how large the subset it. But I understand it now includes more things, like, I believe, more of the standard MIDI APIs from Java, and probably other things. That way you can use more standard APIs and other third party JARs that use standard APIs to do ordinary things -- without needing to do them "the android way".
That is true.
By the time an APK is built it is all Dalvik bytecode.
It is apparently possible for an app to have the JVM to Dalvik bytecode compiler within the app itself -- the compiler having been compiled to Dalvik bytecode running on Android. In this case, the app can take JVM bytecode -- at runtime -- and produce Dalvik code. In fact, the app can generate JVM bytecode at runtime, compile that to Dalvik, and then run it. (See: Clojure, a lisp like language. I haven't seen any recent builds of Clojure on Android)
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by barbara hudson on Wednesday January 15 2020, @05:30PM (1 child)
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 2) by DannyB on Wednesday January 15 2020, @05:41PM
Swing is an example of APIs excluded from Android. For good reason. It doesn't make sense. Swing is a classic desktop GUI toolkit.
Despite Google excluding swing, some perverse and highly motivated person could probably build a working implementation. Swing rests on AWT which isn't that large. If they could get Component to work, they're a lot of the way. But . . . why would anyone do this?
And why would anyone want it?
As I said, some parts of Java just don't make sense on a phone.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by driverless on Thursday January 16 2020, @01:42AM
It's OK, Oracle, or at least Oracle's lawyers, are working to fix that.