Linked by Thom Holwerda on Sat 27th Apr 2013 15:47 UTC
Google "As everyone is trying to guess whether the next big Android update is going to be Key Lime Pie or not, and whether the release will be Android 5.X or 4.X, we have yet to hear anything concrete. After getting a tip from an eagle-eyed reader (thanks, deepayan!) and digging deeper, I can definitively tell you that Google is currently working on Android 4.3, and it is still Jelly Bean." Great detective work by Artem Russakovskii.
Order by: Score:
Makes sense
by reduz on Sat 27th Apr 2013 18:18 UTC
reduz
Member since:
2006-02-25

why change something that works so well?

Reply Score: 0

RE: Makes sense
by jayrulez on Sat 27th Apr 2013 19:19 UTC in reply to "Makes sense"
jayrulez Member since:
2011-10-17

To make it work even better.

Reply Score: 3

RE: Makes sense
by moondevil on Sat 27th Apr 2013 19:54 UTC in reply to "Makes sense"
moondevil Member since:
2005-07-08

Let me see:

- Support Java 7 language constructs (most likely not going to happen with the Oracle suit going on)

- Compile Java to native code or improve the JIT

- Allow the full use of native applications, instead of shared objects loaded into Dalvik with wrappers around JNI calls

- With clang as part of the NDK, start supporting Objective-C instead of disabling it

- Even without generics (my pet peeve), allow for Go usage in the NDK via gccgo

I think I can remember of a few more issues from the developer point of view.

Reply Score: 4

RE[2]: Makes sense
by JAlexoid on Sun 28th Apr 2013 00:09 UTC in reply to "RE: Makes sense"
JAlexoid Member since:
2009-05-19

1. There will be no upgrade to Java7 or even Java6, because Java6 changed the code license to prohibit exactly what Google are doing.
2. It's already mostly compiled
3. Full native applications have been available since 2.3
4. There will be no Obj-C, because the UI library(Skia et al) does not work with Obj-C. Enabling Obj-C is rather useless, since most iOS game devs are already on C++. And Obj-C UI code will definitely not be even close to compatible
5. Go would be nice

Reply Score: 3

RE[3]: Makes sense
by moondevil on Sun 28th Apr 2013 05:47 UTC in reply to "RE[2]: Makes sense"
moondevil Member since:
2005-07-08

1. I wasn't aware of it. Thanks for pointing this out.

2. No it is not. It makes use of a Trace JIT, only compiling hot code. Too much information to paste here.

3. This is not true:
- You are creating a .so that is called by a pre-defined Activity written in Java
- You have communication between Java and C/C++ code happening via JNI calls and UNIX pipes for events, instead of direct OS calls

https://android.googlesource.com/platform/frameworks/base.git/+/mast...

https://android.googlesource.com/platform/frameworks/base.git/+/mast...

https://android.googlesource.com/platform/frameworks/base.git/+/mast...

Since Android 2.3 the only new API is for OpenMAX AL, for everything else you have to wrap it yourself via JNI.

Thus you pay the price of interop every time you call an Android API or are notified from system events in a so called native activity.

4. Personally I don't care about Objective-C. But since they have clang, at least
they could allow iOS developers to easily port their application code, and not go
out of their way to forbid it.
So what if the UI code news to be different?

5. Yes, but the ticket I opened seems not to go anywhere. Android team requires shared objects and the Go guys hate dynamic linking with passion

Reply Score: 3

RE[4]: Makes sense
by JAlexoid on Mon 29th Apr 2013 07:39 UTC in reply to "RE[3]: Makes sense"
JAlexoid Member since:
2009-05-19

2. Hot code = most used = mostly compiled.

3. Considering why NativeActivities were created and the main language of Android you will not get rid of that. Same issue as with calling Objective-C from C++, there will have to be a converting step somewhere.

4. And what would be the point of porting application code that is highly dependent on iOS frameworks?

Reply Score: 3

RE[5]: Makes sense
by moondevil on Mon 29th Apr 2013 07:59 UTC in reply to "RE[4]: Makes sense"
moondevil Member since:
2005-07-08

2. Hot code = most used = mostly compiled.


That is not the same as you don't have to endure a JIT overhead. That is the reason .NET is compiled to native code in Windows Phone 8.

3. Considering why NativeActivities were created and the main language of Android you will not get rid of that. Same issue as with calling Objective-C from C++, there will have to be a converting step somewhere.


There is no conversion going on with Objective-C vs C++.

Both languages have native compilers available, and you can even make use of the Objective-C++ compiler mode.

There is no interop performance penalty between language implementations.

4. And what would be the point of porting application code that is highly dependent on iOS frameworks?


I don't know, code reuse? GNUStep also offers quite a lot of similar APIs.

Additionally it is always a matter of how much care is taken writing portable code.

Games for example have their own UIs built with OpenGL.

Reply Score: 3

RE[6]: Makes sense
by JAlexoid on Mon 29th Apr 2013 12:14 UTC in reply to "RE[5]: Makes sense"
JAlexoid Member since:
2009-05-19

That is not the same as you don't have to endure a JIT overhead.

And unlike traditional JVMs, the compiled code is preserved between VM shutdowns. There is a lot more GC overhead, than there is JIT and interpreted code overhead.

There is no conversion going on with Objective-C vs C++.

Objects are not the same. Method calls are not the same.

I don't know, code reuse?

Which is not an issue of any sizeable amount.

Additionally it is always a matter of how much care is taken writing portable code.

And Objective-C is objectively barely portable. C/C++ on the other hand...

Games for example have their own UIs built with OpenGL.

And are mostly written in C++ for simplicity.

Reply Score: 3

RE[7]: Makes sense
by moondevil on Mon 29th Apr 2013 13:36 UTC in reply to "RE[6]: Makes sense"
moondevil Member since:
2005-07-08

C/C++ on the other hand...


Spaghetti #ifdef ...

Reply Score: 3

RE[2]: Makes sense
by reduz on Sun 28th Apr 2013 02:44 UTC in reply to "RE: Makes sense"
reduz Member since:
2006-02-25

Having to interface with Java from C++ is a royal pain in the ass. JNI sucks.
Nothing would make me happier if Android API moved to C++ (or at least the full API was exported to NativeActivity)

But it's still pointless because clients want integration with APIs such as facebook, gree, tabjoy, adwhirl, etc. and all those are java-only.

Reply Score: 4

RE[3]: Makes sense
by moondevil on Sun 28th Apr 2013 05:51 UTC in reply to "RE[2]: Makes sense"
moondevil Member since:
2005-07-08

Agreed, that is what most developers aren't aware when they are told Android supports C++.

I prefer Java's type safety over C++, but C++ has the benefit of being portable to other mobile platforms for native applications and first class language in all vendor's SDKs.

But Google could take better care of it.

Reply Score: 3

RE: Makes sense
by vivainio on Sat 27th Apr 2013 21:25 UTC in reply to "Makes sense"
vivainio Member since:
2008-12-26

Android is far from perfect yet. Multitasking is out of hand a lot of the time, and performance overall is not as stable as it should be.

It's not far away though.

Reply Score: 4

RE[2]: Makes sense
by Kochise on Sun 28th Apr 2013 07:09 UTC in reply to "RE: Makes sense"
Kochise Member since:
2006-03-03

From a former Symbianer, I could tell it's not all that bad...

Kochise

Reply Score: 1

RE[3]: Makes sense
by moondevil on Mon 29th Apr 2013 08:00 UTC in reply to "RE[2]: Makes sense"
moondevil Member since:
2005-07-08

Symbian "Blue Screens"?

I had quite a few in some devices.

Reply Score: 3