11-25-13 02:02 PM
561 ... 212223
tools
  1. ofutur's Avatar
    Isn't Art just a beta on kit kat right now?

    sent from my galaxy note 3
    Indeed, don't expect it to become the default runtime any time soon.
    11-25-13 09:58 AM
  2. Pete The Penguin's Avatar
    So many things wrong with your statement...

    1. A lot of Android apps were running just fine even before BlackBerry developed that hack. Not every Android app needs native extensions.
    2. The clever hack is only about running native Linux extensions not about running "Android Java" bytecode. It works well for apps which behave normally, not for apps using stupid tricks in order to try and improve the security of their code through obscurity
    3. QNX is not binary compatible with Linux, nothing to do with BB10 being compatible with Android which runs in a VM...
    4. What makes you think ART won't be Open Source Software?
    5. ART will make it so that Android apps running on BB10 will do so at native speed since they will be natively compiled at install time.
    I never said QNX is binary compatible with Linux, I have been saying for months that it isn't.

    There's no guarantee that Google will make ART open source, they're already tightening down Android.

    Don't attack me just because I posted an article. Go read the article (if you haven't) and the comments too (many corrections in those comments).

    Geeks United C00122408
    11-25-13 10:13 AM
  3. tickerguy's Avatar
    ART is just changing where the preprocessing happens.

    Dalvik already has a cache mechanism built-in and all of the existing Android devices use it. It's an LRU cache (by default anyway) and is quite effective.

    ART is sort of like putting "cc" and "ld" on the phone and having it compile and link an app when it's installed. This is going to be faster than Dalvik, quite possibly by a lot. It also (amusingly) becomes even more device-independent, which is the real reason Google is going that way.

    The "story" is that this is about performance. The truth is that it's about processor-independence, much as is building an Ansi C compiler into something means that (provided you write code against the standard) it should compile and run without changes.

    Note the "should" however, and this is where the problems are going to come from. Anyone who has ported C or C++ code knows that sometimes you type "make" and it is all ok, and then sometimes it's not. The "not" part gets to be fun when you're on a phone and the code is signed and not able to be easily modified by the user (or modified at all!)

    Incidentally this actually makes BlackBerry's (and other manufacturers) job easier than the existing operating model for Android, in that there is no longer a matter of running embedded machine code in an app. Supporting the compile environment of ART ought to be materially simpler since the actual object representation on the device becomes immaterial to compatibility.

    In addition, and this is quite important, one can legally develop a compiler for it without Google's permission. Indeed, provided that you don't steal any of Google's code there is nothing Google can do about you developing said compiler.
    11-25-13 10:16 AM
  4. playbookster's Avatar
    ART is just changing where the preprocessing happens.

    Dalvik already has a cache mechanism built-in and all of the existing Android devices use it. It's an LRU cache (by default anyway) and is quite effective.

    ART is sort of like putting "cc" and "ld" on the phone and having it compile and link an app when it's installed. This is going to be faster than Dalvik, quite possibly by a lot. It also (amusingly) becomes even more device-independent, which is the real reason Google is going that way.

    The "story" is that this is about performance. The truth is that it's about processor-independence, much as is building an Ansi C compiler into something means that (provided you write code against the standard) it should compile and run without changes.

    Note the "should" however, and this is where the problems are going to come from. Anyone who has ported C or C++ code knows that sometimes you type "make" and it is all ok, and then sometimes it's not. The "not" part gets to be fun when you're on a phone and the code is signed and not able to be easily modified by the user (or modified at all!)

    Incidentally this actually makes BlackBerry's (and other manufacturers) job easier than the existing operating model for Android, in that there is no longer a matter of running embedded machine code in an app. Supporting the compile environment of ART ought to be materially simpler since the actual object representation on the device becomes immaterial to compatibility.
    Thanks for your insight! Better performing android apps benefits everyone

    Sent from my Z30
    11-25-13 10:23 AM
  5. tickerguy's Avatar
    Yeah, I love how Google and others claim this is about "performance."

    Uh, no, that's a (beneficial) side effect. If Google gave a damn about that they would have never implemented Android as a Java engine in the first place.

    The reason it's being done is that Intel is finally challenging ARM in the mobile processor space and this is a major problem for Google and Android because there are so many apps that have embedded machine code in them.

    That breaks all such apps until and unless the developer recompiles them so as to include the object code for both, and it makes the calling conventions considerably more-complex since the register layouts for ARM and Intel processors are very different.

    The entire "Java" thing was only viable if you prohibit inline code. But Google got basically forced into allowing it years ago by the developers for performance and capability reasons (in other words pure Dalvik sucks big donkey hoses for complex apps.) Once that happened the premise of Dalvik (machine-independence) was violated and the only way to "get it back" was to head in this direction.

    This isn't Google being clever or even intelligent -- it's them scrambling to avoid being run over by a steamroller that is headed in their direction.
    11-25-13 10:37 AM
  6. Poirots Progeny's Avatar
    Yeah, I love how Google and others claim this is about "performance."

    Uh, no, that's a (beneficial) side effect. If Google gave a damn about that they would have never implemented Android as a Java engine in the first place.

    The reason it's being done is that Intel is finally challenging ARM in the mobile processor space and this is a major problem for Google and Android because there are so many apps that have embedded machine code in them.

    That breaks all such apps until and unless the developer recompiles them so as to include the object code for both, and it makes the calling conventions considerably more-complex since the register layouts for ARM and Intel processors are very different.

    The entire "Java" thing was only viable if you prohibit inline code. But Google got basically forced into allowing it years ago by the developers for performance and capability reasons (in other words pure Dalvik sucks big donkey hoses for complex apps.) Once that happened the premise of Dalvik (machine-independence) was violated and the only way to "get it back" was to head in this direction.

    This isn't Google being clever or even intelligent -- it's them scrambling to avoid being run over by a steamroller that is headed in their direction.
    Very well articulated.

    I, for one, am really interested in where this all ends up.

    Posted via CB10
    m1a1mg and Anilu7 like this.
    11-25-13 10:42 AM
  7. Pete The Penguin's Avatar
    Yeah, I love how Google and others claim this is about "performance."

    Uh, no, that's a (beneficial) side effect. If Google gave a damn about that they would have never implemented Android as a Java engine in the first place.

    The reason it's being done is that Intel is finally challenging ARM in the mobile processor space and this is a major problem for Google and Android because there are so many apps that have embedded machine code in them.

    That breaks all such apps until and unless the developer recompiles them so as to include the object code for both, and it makes the calling conventions considerably more-complex since the register layouts for ARM and Intel processors are very different.

    The entire "Java" thing was only viable if you prohibit inline code. But Google got basically forced into allowing it years ago by the developers for performance and capability reasons (in other words pure Dalvik sucks big donkey hoses for complex apps.) Once that happened the premise of Dalvik (machine-independence) was violated and the only way to "get it back" was to head in this direction.

    This isn't Google being clever or even intelligent -- it's them scrambling to avoid being run over by a steamroller that is headed in their direction.
    Well written and concise. Thank you.

    I'm looking forward to seeing where this goes.

    Seamless Android integration threatens repeat of 1990s PC wars: http://www.theregister.co.uk/2013/11...stealth_steed/

    Geeks United C00122408
    11-25-13 10:45 AM
  8. m1a1mg's Avatar
    Wow, I learned on lot on this page.

    We've heard rumblings for a while about Intel in mobile, and mobile is definitely the future, but Intel hasn't had much luck.
    11-25-13 10:50 AM
  9. Poirots Progeny's Avatar
    Wow, I learned on lot on this page.

    We've heard rumblings for a while about Intel in mobile, and mobile is definitely the future, but Intel hasn't had much luck.
    I think they're seriously committed to mobile, seeing as convergence devices are now picking up steam. Though yes, limited in success up to now, baytrail and all that could be a big "thing" in the future.

    I suppose it is right that Google address any android shortcomings at the dawn of this furute...!?

    Posted via CB10
    11-25-13 10:55 AM
  10. wu-wei's Avatar
    I, for one, am very thankful for this discussion.

    Posted via CB10
    Poirots Progeny and Wigley458 like this.
    11-25-13 12:29 PM
  11. ofutur's Avatar
    I never said QNX is binary compatible with Linux, I have been saying for months that it isn't.

    There's no guarantee that Google will make ART open source, they're already tightening down Android.

    Don't attack me just because I posted an article. Go read the article (if you haven't) and the comments too (many corrections in those comments).
    You said "BB10 is not binary compatible with Android" which doesn't make sense. That's the reason I highlighted the fact that the problem lied with the native Linux extensions, not with Android code.

    Regarding ART, tickerguy went into more details to explain as to why the change is more of a blessing than a hindrance.

    And I wasn't attacking you :P. There were just too many mistakes in your statement, especially after I had read the article you mentioned.

    ...
    Incidentally this actually makes BlackBerry's (and other manufacturers) job easier than the existing operating model for Android, in that there is no longer a matter of running embedded machine code in an app. Supporting the compile environment of ART ought to be materially simpler since the actual object representation on the device becomes immaterial to compatibility.
    Exactly
    11-25-13 02:02 PM
561 ... 212223

Similar Threads

  1. For all those people who post "First"
    By drmike in forum Rehab & Off-Topic Lounge
    Replies: 321
    Last Post: 01-21-14, 10:00 PM
  2. zero tries left MEP unlocking 9780
    By Marlvin Dustzi in forum BlackBerry Unlocking
    Replies: 2
    Last Post: 11-13-13, 09:27 AM
  3. Can I have a High capacity battery instead of the original one?
    By Kamlekar Venkateshwar in forum BlackBerry Torch 9860/9850
    Replies: 12
    Last Post: 11-12-13, 11:51 AM
  4. Clash of Clan Sideload issue
    By mrbub in forum BB10 Android App Sideloading
    Replies: 2
    Last Post: 11-11-13, 01:25 PM
  5. BlackBerry to have Photo unlocking screen in 10.2.1
    By OniBerry in forum News & Rumors
    Replies: 2
    Last Post: 11-11-13, 12:47 PM
LINK TO POST COPIED TO CLIPBOARD