09-28-14 11:44 PM
761 ... 1415161718 ...
tools
  1. Pete The Penguin's Avatar
    Remember that CJH said that BB10 would "never" run Android Native code.

    While, I remind you, it was fully-capable of doing so and in fact I was running native-embedded apps on BB10. You simply used to have to load a debug token (or have it submitted through BlackBerry World, as was the case for Skype.)

    How many times do you get to be (1) dead-flat wrong and (2) continue to run a fear-mongering load of garbage without being called out on it and stomped on by the mods?

    Just curious.
    BB10 doesn't run Android Native code, nor do Android phones. They both use a VM.

    Which bit of Virtual Machine don't you understand?
    MyFirstOwnUsername likes this.
    12-16-13 12:42 PM
  2. wu-wei's Avatar
    Oh dear. Is this becoming an antitrust discussion? Truly? Sigh...
    12-16-13 01:11 PM
  3. wu-wei's Avatar
    BB10 doesn't run Android Native code, nor do Android phones. They both use a VM.

    Which bit of Virtual Machine don't you understand?
    Hmmm. A Java Virtual Machine, you say? When have I heard that criticized as outdated and inefficient? *cough* BBOS *cough*

    And now which platform is running a virtualized virtualization? How remarkably intelligent. Yawn.
    LP_Rigg and Superfly_FR like this.
    12-16-13 01:13 PM
  4. tickerguy's Avatar
    Now now CJH, Dalvik is a VM (if you want to be pedantic.)

    You know damn well what you were claiming, and it was false. Not only was it false in the future tense it was false in the present tense, you got caught (by myself along with others) and you have steadfastly refused to admit to it.

    Never mind that native code is native code, and Android ARM native code (specifically, armeabi) does run on BB10. Prior to 10.2.1 you had to wrap any APK using it in a BAR file and use a debug token if sideloading it (but only to load it -- it would execute just fine once loaded even if you deleted the token from the phone or it expired) I suspect the reason for that was that BlackBerry deliberately barricaded it from casual use due to concerns about performance, quality of implementation or both -- but whatever the reason it most-certainly did work and in fact Skype on BBWorld (which is an Android port) is chock full of it.

    Also never mind that the means by which BB10 performs trap interception and thus Android execution isn't much different than how traps work in general at an OS level. Indeed, it's exactly how various i86 Unix variants could run Xenix binaries a couple of decades ago and how FreeBSD runs Linux ones now. The inherent function of a load-on-demand runtime linker operates in exactly this way; provided the calling conventions are reasonably coherent between particular implementations this isn't very difficult at all.

    Nor will ART change any of this, incidentally.

    The only "wizardry" (or "hackery" if you prefer) involved in BlackBerry's implementation of materiality is in their interface to system databases such as contacts where storage conventions and such are wildly different than found in Android. Indeed, if you look around in the Android runtime you'll find the shims involved in that translation -- they're not hidden at all.

    All of this sort of thing was invented and in commercial use long before processor support for Hypervisors showed up in "consumer" style CPUs (that is, other than in mainframe CPUs), and it's neither new or an "ugly hack"; the base methods used by BlackBerry are in fact how virtually all modern demand-loaded library based object formats have worked since pageable segmented RAM made dynamically-faulting in code segments (including shared libraries) reasonable.

    There may be a lot of people around here who don't understand how all this works at a machine level, but there are a few of us, myself included, who have been writing operating systems and related code all the way back to the original Zilog 8-bit chips (Z80s) and before -- in assembler.
    12-16-13 01:26 PM
  5. SirJes's Avatar
    [Speculation] Google play in 10.2.1.14XX-minor-burn-first-aid-procedure-part-2-picture.jpg

    CLICK HERE To Join My Music & Poetry Channel. Please&Thanks.
    12-16-13 01:35 PM
  6. ital1's Avatar
    Now now CJH, Dalvik is a VM (if you want to be pedantic.)

    You know damn well what you were claiming, and it was false. Not only was it false in the future tense it was false in the present tense, you got caught (by myself along with others) and you have steadfastly refused to admit to it.

    Never mind that native code is native code, and Android ARM native code (specifically, armeabi) does run on BB10. Prior to 10.2.1 you had to wrap any APK using it in a BAR file and use a debug token if sideloading it (but only to load it -- it would execute just fine once loaded even if you deleted the token from the phone or it expired) I suspect the reason for that was that BlackBerry deliberately barricaded it from casual use due to concerns about performance, quality of implementation or both -- but whatever the reason it most-certainly did work and in fact Skype on BBWorld (which is an Android port) is chock full of it.

    Also never mind that the means by which BB10 performs trap interception and thus Android execution isn't much different than how traps work in general at an OS level. Indeed, it's exactly how various i86 Unix variants could run Xenix binaries a couple of decades ago and how FreeBSD runs Linux ones now. The inherent function of a load-on-demand runtime linker operates in exactly this way; provided the calling conventions are reasonably coherent between particular implementations this isn't very difficult at all.

    Nor will ART change any of this, incidentally.

    The only "wizardry" (or "hackery" if you prefer) involved in BlackBerry's implementation of materiality is in their interface to system databases such as contacts where storage conventions and such are wildly different than found in Android. Indeed, if you look around in the Android runtime you'll find the shims involved in that translation -- they're not hidden at all.

    All of this sort of thing was invented and in commercial use long before processor support for Hypervisors showed up in "consumer" style CPUs (that is, other than in mainframe CPUs), and it's neither new or an "ugly hack"; the base methods used by BlackBerry are in fact how virtually all modern demand-loaded library based object formats have worked since pageable segmented RAM made dynamically-faulting in code segments (including shared libraries) reasonable.

    There may be a lot of people around here who don't understand how all this works at a machine level, but there are a few of us, myself included, who have been writing operating systems and related code all the way back to the original Zilog 8-bit chips (Z80s) and before -- in assembler.
    With absolutely no sarcasm intended, thank you very much for advancing the education of this post's readers.
    12-16-13 01:42 PM
  7. cgk's Avatar
    There's an angle I hadn't considered. Good thinking.
    Having said that - the more I look into this, the more I think the really important thing to get GAPPS is confirmation to this document - if you don't, you don't get GAPPS.
    12-16-13 01:52 PM
  8. lawguyman's Avatar
    nope. My motorola xoom, will not have kitkat.

    it's not only specs, it's internal memory as well.
    I meant that future devices with low end specs will run Kitkat, not that existing low end devices will be upgraded. Existing low end devices will be retired or break. Such is life.

    Posted via CB10
    12-16-13 01:55 PM
  9. lawguyman's Avatar
    That's because of 15 USC (Sherman and Clayton Acts) which makes felonious a conspiracy to restrain trade, with real no-BS prison sentences possible.

    An actual agreement to restrain trade among competitors who as a combined set wield market power is per-se unlawful.

    It is for this reason that I have challenged those who claim that Google "can't" (as a matter of some contractual agreement, as opposed to their sole and unilateral choice) allow BlackBerry to incorporate Play Services into BB10 to produce the written document so-stating in a form that can be authenticated as real.

    I don't believe such an agreement exists because the odds of such being found to be a criminal violation of law in the United States is quite high.
    I'm not exactly sure what you are contending to be the conspiracy in restraint of trade? The OHA?

    I can't imagine what tree you are barking up with this. The OHA develops a product that ANYONE can freely use. How does that restrain trade?

    Do you mean Google's restrictions on who can distribute Google Services? If so, Good luck with that. Companies are given a large amount of latitude in how they choose to distribute their products. OHA members cannot do certain things with Android that others are free to do. At the same time OHA members get access to Google services. I can't think of a more competitive marketplace than mobile phones and the Android subset of that is even more competitive. Where is the agreement that restrains trade?

    I'm not really understanding your argument.

    Posted via CB10
    edthebudman likes this.
    12-16-13 02:06 PM
  10. smart548's Avatar
    I've read almost all posts and still not understanding: if both Android and BlackBerry run apps thanks to a VM why BlackBerry could not make a deal with google for its specific apps (or for apps that are usign google services)? There is not an hack at all. From version 10.0 BlackBerry 10 devices were sold with the capabilities to run certains android apps: if that was not legal they would not have released them with this capability. Plus,if apps are free or payed if not free why I am not supposed to run them on BlackBerry phone if it can afford them? I'm not expecting support nor auto update.
    Second question: if from KitKat things will change but a VM will always be involved..well, BB just will have to build a new VM for new apps or updating the old VM. Am I right? thx all!

    Posted via CB10
    12-16-13 02:25 PM
  11. tickerguy's Avatar
    I'm not exactly sure what you are contending to be the conspiracy in restraint of trade? The OHA?
    No; I'm arguing that there is no "side letter" or other agreement that says that Google cannot allow BlackBerry (or anyone other than some group signing some other agreement) to use Play Services. Those who argue that Google can't (not won't, but can't) allow BlackBerry to use Play are basically arguing that there is some heretofore-secret quid-pro-quo that Google has given OHA members that says they won't let anyone else​ use Play Services.

    Such an agreement by a consortium with market power would be quite-dangerous under the Sherman Act.

    That is the effective allegation that many on this thread have made about why BlackBerry "can't" have Play. Well, if that's true then let's see the agreement that binds Google. I allege it doesn't exist.
    12-16-13 02:31 PM
  12. lawguyman's Avatar
    No; I'm arguing that there is no "side letter" or other agreement that says that Google cannot
    allow BlackBerry (or anyone other than some group signing some other agreement) to use Play Services. Those who argue that Google can't (not won't, but can't) allow BlackBerry to use Play are basically arguing that there is some heretofore-secret quid-pro-quo that Google has given OHA members that says they won't let anyone else​ use Play Services.

    Such an agreement by a consortium with market power would be quite-dangerous under the Sherman Act.
    Ah. Okay.

    Could Google restrict it's distribution of its services only through OHA members? Sure it could. Limited and restricted distribution models are really common. Apple sells only through authorized resellers who agree to minimum prices and that is fine. Companies are given lots of leeway in vertical arrangements like this. Plus, Anyone can join OHA, you just have to agree to its terms.

    Has Google done this? Who knows. It's possible. I doubt it though. This requirement protects Google, not the OHA members.

    Posted via CB10
    12-16-13 02:38 PM
  13. Gnomesane's Avatar
    There may be a lot of people around here who don't understand how all this works at a machine level, but there are a few of us, myself included, who have been writing operating systems and related code all the way back to the original Zilog 8-bit chips (Z80s) and before -- in assembler.
    Oh my dear and fluffy lord, that takes me back. I'm not a programmer, but as a kid my buddy got a TRS-80 which used that chip, no? Just had a massive flashback to public school. I personally had a Commodore Pet 32K with external cassette drive (my Dad was a teacher and got it through the school). I remember spending hours typing in machine language (that what we called it anyway) printed at the back of magazines. Sorry, just had to throw that in there.

    Interesting discussion, even if a lot is going over my head. Whether we get Google Play or not, it's reassuring to know that when Google switches to Art in KitKat that BlackBerry should have no problems adapting.
    12-16-13 02:42 PM
  14. Gnomesane's Avatar
    No; I'm arguing that there is no "side letter" or other agreement that says that Google cannot allow BlackBerry (or anyone other than some group signing some other agreement) to use Play Services. Those who argue that Google can't (not won't, but can't) allow BlackBerry to use Play are basically arguing that there is some heretofore-secret quid-pro-quo that Google has given OHA members that says they won't let anyone else​ use Play Services.

    Such an agreement by a consortium with market power would be quite-dangerous under the Sherman Act.
    And up here in Canada it seems Google's being looked at by our regulators... This seems to be new the last day or so.

    Competition regulator wonders: Is Google breaking Canada's antitrust laws? | CTV News

    Unrelated to their Play Store and Android, seems centered on the Search engine and advertising rates, but... Wouldn't hurt if Google inked a deal with BlackBerry to access the Play Store perhaps.
    12-16-13 02:46 PM
  15. tickerguy's Avatar
    Google won't "switch" to ART in KitKat on an exclusive basis and may never.

    ART is simply a at-load-time compiler as opposed to an interpreter with a cache (which is what the current Dalvik is more-or-less.)

    The lines are a lot more blurry than that because Java is a p-code sort of thing anyway.

    I find the entire ART thing rather amusing actually, as years ago I argued that Android would eventually find itself backed in a corner due to performance limitations present in interpreted runtime execution environments (such as Dalvik.) I was called all sorts of names by Android apologists who claimed there was no performance penalty and that the Dalvik cache prevented there from being a problem at all. This was before ARMEABI showed up, incidentally.

    Then the limitations (both capability and performance) of Java-***-Dalvik got bad enough that Google was basically forced to allow inline native code. But that led to a new problem, because now what Google was trying to avoid with Dalvik in the first place (processor and architecture dependence) suddenly became a hard-stop compatibility problem that will only get worse as new processor families and instructions show up (e.g. ARM's new 64-bit capable CPUs, Intel chipsets, etc.) So now we have "ART" appearing, which is pretty-much what I argued at the time they should have done in the first place... years later.
    mnc76 likes this.
    12-16-13 02:50 PM
  16. Pete The Penguin's Avatar
    Google won't "switch" to ART in KitKat on an exclusive basis and may never.

    ART is simply a at-load-time compiler as opposed to an interpreter with a cache (which is what the current Dalvik is more-or-less.)

    The lines are a lot more blurry than that because Java is a p-code sort of thing anyway.

    I find the entire ART thing rather amusing actually, as years ago I argued that Android would eventually find itself backed in a corner due to performance limitations present in interpreted runtime execution environments (such as Dalvik.) I was called all sorts of names by Android apologists who claimed there was no performance penalty and that the Dalvik cache prevented there from being a problem at all. This was before ARMEABI showed up, incidentally.

    Then the limitations (both capability and performance) of Java-***-Dalvik got bad enough that Google was basically forced to allow inline native code. But that led to a new problem, because now what Google was trying to avoid with Dalvik in the first place (processor and architecture dependence) suddenly became a hard-stop compatibility problem that will only get worse as new processor families and instructions show up (e.g. ARM's new 64-bit capable CPUs, Intel chipsets, etc.) So now we have "ART" appearing, which is pretty-much what I argued at the time they should have done in the first place... years later.
    Google won't swtich to ART? Really?

    "Google Says It Could Replace Dalvik Runtime In Next Version Of Android" - http://readwrite.com/2013/11/07/goog...oqdHvNBZOtdamP

    On November 7th, 2013 Google said this:
    "I don't want to make promises but I imagine next release it could be ready. Maybe. We will switch over when it is ready. It is actually quite fast now and now we are just really optimizing it and assuming those optimizations go well I assume that we will be ready to switch over at the next opportunity" from Android head engineer Dave Burke in an interview with ReadWrite.

    (I've highlighted the pertinent sentence).
    12-16-13 03:03 PM
  17. Gnomesane's Avatar
    Google won't swtich to ART? Really?
    He said: "Google won't "switch" to ART in KitKat on an exclusive basis and may never." I think you misread.
    12-16-13 03:08 PM
  18. Thunderbuck's Avatar
    Is there anything that would preclude Blackberry from offering Android Apps in Blackberry World much like Amazon does?
    Yes.

    APKs don't run in the same kind of security context as a proper .bar file. This is a workaround, not a replacement for the existing BB10 app model.

    Posted from CB10 running on my awesome Z30
    Superfly_FR likes this.
    12-16-13 03:22 PM
  19. stabstabdie's Avatar
    [Speculation] Google play in 10.2.1.14XX-mockup.png

    Couldn't resist
    Ruslan Botsyurko likes this.
    12-16-13 03:29 PM
  20. tickerguy's Avatar
    Yes.

    APKs don't run in the same kind of security context as a proper .bar file. This is a workaround, not a replacement for the existing BB10 app model.

    Posted from CB10 running on my awesome Z30
    Wweeeeeeeeellll. Not exactly.

    Go into one of the Android ports that you got officially as a BAR file from BlackBerry world and try to shut off one of the permissions (as you can for all native-code apps.)

    Notice anything about the screen?
    12-16-13 03:30 PM
  21. goku_vegeta's Avatar
    Wweeeeeeeeellll. Not exactly.

    Go into one of the Android ports that you got officially as a BAR file from BlackBerry world and try to shut off one of the permissions (as you can for all native-code apps.)

    Notice anything about the screen?
    You can't modify permissions for Android apps?
    12-16-13 04:41 PM
  22. stabstabdie's Avatar
    You can't modify permissions for Android apps?
    It's all or nothing
    12-16-13 04:56 PM
  23. Thunderbuck's Avatar
    Wweeeeeeeeellll. Not exactly.

    Go into one of the Android ports that you got officially as a BAR file from BlackBerry world and try to shut off one of the permissions (as you can for all native-code apps.)

    Notice anything about the screen?
    I get it. I was drawing the distinction that APKs aren't signed, as BARs are required to be. I find it most improbable that BlackBerry would allow unsigned code in BB World.

    Posted from CB10 running on my awesome Z30
    12-16-13 06:10 PM
  24. Omnitech's Avatar
    Limited and restricted distribution models are really common. Apple sells only through authorized resellers who agree to minimum prices and that is fine.

    Actually, it's against the law in the USA.

    "Fair Trade laws" were banned in the 1970s.

    Later, the workaround that various companies had come up with where they threatened dealers with various sorts of sanctions (ie loss of advertising co-op dollars at minimum, revocation of their dealer license was also possible, etc) if they did not meet their "minimum advertised prices" was also thrown out in various jurisdictions, notably New York.

    It appears there is still a lot of state-to-state variation in this, but in general a sweeping lock on the price that a reseller is allowed to sell a product for - particularly if it is sold nationwide - is very hard to maintain without getting into legal trouble.
    12-16-13 06:20 PM
  25. tickerguy's Avatar
    I get it. I was drawing the distinction that APKs aren't signed, as BARs are required to be. I find it most improbable that BlackBerry would allow unsigned code in BB World.

    Posted from CB10 running on my awesome Z30
    Oh yes they are. All APKs have to be signed (with "jarsigner")

    It's just that they can be self-signed (e.g. you can generate your own signing key.)

    BAR files will not load unless the certificate chain has a valid BlackBerry root. That's the difference, but is it really a difference? How much actual vetting goes on at the code level? Without source, the answer is "almost none", so the real difference is that if something malicious is distributed they know where to point.

    That, by the way, is true for Google's Play Store too -- while you can self-sign an APK on Android none of the store environments will accept a self-signed, no-root-chain APK that I'm aware of.

    I know Google won't.
    12-16-13 06:32 PM
761 ... 1415161718 ...

Similar Threads

  1. Blackberry CAC Smart Card Reader v2 ((Stuck in Boot Cycle))
    By bdahl77 in forum General BlackBerry Discussion
    Replies: 1
    Last Post: 12-13-13, 11:38 AM
  2. How Do I Set Bi-Weekly Reoccurrence in Calendar App?
    By sly11 in forum BlackBerry Z10
    Replies: 6
    Last Post: 12-13-13, 09:23 AM
  3. Traffic in BlackBerry Map
    By Alfredofid in forum BlackBerry Z10
    Replies: 3
    Last Post: 12-12-13, 11:18 PM
  4. Is Beweather 10 Hourly Forecast Working?
    By EauRouge in forum BlackBerry 10 Apps
    Replies: 2
    Last Post: 12-12-13, 10:33 PM
  5. 10.2.1 and Google Chromecast
    By Superbuddy2007 in forum General BlackBerry Discussion
    Replies: 2
    Last Post: 12-12-13, 09:04 PM
LINK TO POST COPIED TO CLIPBOARD