[Speculation] Google play in 10.2.1.14XX

Nick...we get it man. You made your points loud and clear in many many threads. How long is it gonna take to let it go?
You got what you wanted. There is no longer a team and for that matter...leaks so far. Time to move on and stop bringing it up when people are having a good discussion about something that could potentially be a boost to BlackBerry. Noone cares anymore about your dislike for how the team did things or for a member or whatever.

Posted via CB10

Lmao I didnt say a word. I changed my signature, that's it. I never said a word about the leaks team. I never said anything about the way anything is being leaked. I never said anything at all except for hmm. So please spare me.

Lmao I didnt say a word. I changed my signature, that's it. I never said a word about the leaks team. I never said anything about the way anything is being leaked. I never said anything at all except for hmm. So please spare me.

The way people talk here sometimes leaves the impression that they must actually believe that a company has no right to internal deliberations of a highly sensitive competitive nature without sharing all of those deliberations with the entire world prior to when they feel it would be competitively advantageous or even feasible to do so.

I want to point out that I have NO expectation for BlackBerry to reveal any info that would lose it competitive advantage, or that was infeasible to release. Not sure how you gleaned that from what I said.

I was simply saying that the fact that they aren't releasing this info indicates it is something important (since if it wasn't, there would be no reason for them not to release it). That's all.

No one is expecting BlackBerry to release important info prematurely. HOWEVER, we can infer that certain information may be important (e.g.: info that may compromise competitive advantage for example, like possible GPS integration) by virtue of the fact that they DON'T release it.

Originally Posted by Omnitech

The fact that you might not get end-user performance equivalent to a modern, dedicated Android device with superior hardware specification in such an environment is not a surprise at all.

I don't think the goal can ever be "better performance than dedicated Android running on a device of equivalent hardware spec". All they have to achieve is "good enough performance to accomplish most of what users will expect

Unfortunately, my Dad's Galaxy Nexus (which has even slower hardware than my Z10), runs much better than my Z10 on apps such as GMaps 7.3, Flipboard, SoundCloud, and Instagram in terms of smoothness and responsiveness.

The Z10 hardware is considered a full generation ahead of the Galaxy Nexus hardware, yet it can't compete with it IMO.

Also, I disagree that it is technically impossible for the Android runtime to run at almost "native Android phone" speeds. QNX and Android are both Unix based, so many Android services have direct "1 to 1" equivalents in QNX (for example, Android and QNX have many of the same POSIX functions, even though Android is not 100% POSIX compliant). They do not recode these equivalent services again for Android, they use the existing QNX services natively.

I don't expect BETTER performance (even though there are a number of Android apps that do actually perform better on the Z10 than the Galaxy S3 which has the same SOC as the Z10).

However, I do expect more competitive Android performance than we currently have, and I'm confident BlackBerry has the technical talent to meet this expectation.

Q1. What's the main message here?A1. Alec told us that the BIG MESSAGE here is that BlackBerry is upping their game for Android support. It means they're comfortable with the performance they are getting out of the 4.2.2 runtime on BlackBerry 10 and the experience Android apps are delivering on the platform to users. It's offering "more choice for more customers because that's what customers have asked us to do."

The more, the better ?

Alec reiterated to us that they're following the same basic process here as they did with bringing the Gingerbread Android runtime to BlackBerry 10. The integration is tighter, the performance is better and there is greater compatibility this time around. Android apps that use Bluetooth APIs are supported (support for Bluetooth Low Energy for Android coming in future OS releases), and even though BlackBerry 10 doesn't have native Google Maps, BlackBerry has plumbed through the MapView v1 API via OpenStreetMaps. So Android .apks you install that call out to Google Maps via this API will still work, even though there's no native Google Maps on BlackBerry 10.

^^these (underlined) retro-engineering-like (technically, it's not) have to be considered, IMHO. What's the effect of this ? Can Google counter this "hack" ? Do they want to ? Would they prefer to get $$ rather than seeing an open (back) door into their T&C's ? Can these hacks allow to get rid of Google services when needed ? How would they survive updates ? At what cost ? ...

At this time there is no planned support for Google Play on BlackBerry.

^^these (underlined) retro-engineering-like (technically, it's not) have to be considered, IMHO. What's the effect of this ? Can Google counter this "hack" ? Do they want to ? Would they prefer to get $$ rather than seeing an open (back) door into their T&C's ? Can these hacks allow to get rid of Google services when needed ? How would they survive updates ? At what cost ? ...

I'm wondering if their support for MapView v2 is just a weak implementation of the API interface that ties into BlackBerry Maps, where the goal is to simply prevent Android apps that make MapView v2 calls from crashing. If this is true, then they wouldn't need Play Services for this to work (and we'd be left with missing features in apps that use MapView v2).

Legally, it would be hard to believe Google would sue BlackBerry for using the API interface, since this is EXACTLY what Google did with Java: they copied Java's API signatures but implemented them from scratch (without using any Oracle code). They are currently being sued by Oracle for this. Suing BlackBerry for this would be like an admission of guilt in the Oracle case.

I'm wondering if their support for MapView v2 is just a weak implementation of the API interface that ties into BlackBerry Maps, where the goal is to simply prevent Android apps that make MapView v2 calls from crashing. If this is true, then they wouldn't need Play Services for this to work (and we'd be left with missing features in apps that use MapView v2).

Legally, Google can't sue BlackBerry for using the API interface, since this is EXACTLY what Google did with Java: they copied Java's API signatures but implemented them from scratch (without using any Oracle code). They are currently being sued by Oracle for this.

Posted via CB10

What Google did with Java is a little bit different. Google essentially took Java APIs and changed them slightly through "reverse engineering." [sarcasm] Java code won't run on Android but it is easy for a Java developer to learn Android or to port a Java App to Android. This is not what BB is going for. BB wants existing Android code and API calls simply to function.

BB could have reverse engineered this all to work but others (who I believe are reliable) have claimed that this is not what is planned.

I'm wondering if their support for MapView v2 is just a weak implementation of the API interface that ties into BlackBerry Maps, where the goal is to simply prevent Android apps that make MapView v2 calls from crashing. If this is true, then they wouldn't need Play Services for this to work (and we'd be left with missing features in apps that use MapView v2).

Legally, it would be hard to believe Google would sue BlackBerry for using the API interface, since this is EXACTLY what Google did with Java: they copied Java's API signatures but implemented them from scratch (without using any Oracle code). They are currently being sued by Oracle for this. Suing BlackBerry for this would be like an admission of guilt in the Oracle case.

Posted via CB10

It's not a weak implementation of BB Maps :OpenStreet maps is a free worldwide map providing open data under ODBL (Open Data Commons Open Database License). See it as an "alias"; when an app is calling for Mapview, then it's OpenStreetMap functions and behaviors that are invoked.

For the legal stuff, I keep questioning myself but I believe there's no way to protect the name of a function/resource/whatever within an app/API, especially if the Opens Source app used was actually built ... before

And I wonder what would be the "price" to mimick this for any Google proprietary stuff, aka "Google services".
Just remind most Google proprietary stuff have been an Open Source project before; they added exclusive google features and killed the O.S "branch" ... well, not totally killed it. Ironical ?

It's not a weak implementation of BB Maps :OpenStreet maps is a free worldwide map providing open data under ODBL (Open Data Commons Open Database License). See it as an "alias"; when an app is calling for Mapview, then it's OpenStreetMap functions and behaviors that are invoked.

For the legal stuff, I keep questioning myself but I believe there's no way to protect the name of a function/resource/whatever within an app/API, especially if the Opens Source app used was actually built ... before

And I wonder what would be the "price" to mimick this for any Google proprietary stuff, aka "Google services".
Just remind most Google proprietary stuff have been an Open Source project before; they added exclusive google features and killed the O.S "branch" ... well, not totally killed it. Ironical ?

As to the legal stuff, there are a number of different licenses with open source, so depends on license distributed with the code. Do you know the license in question? Though they are still often hard to understand, and companies can argue technicalities.

As to the legal stuff, there are a number of different licenses with open source, so depends on license distributed with the code. Do you know the license in question? Though they are still often hard to understand, and companies can argue technicalities.

Now this is funny. Is he like a Russian hunter killer submarine? Tightening things up is a good thing, but wasting precious resources on something that arguably does them more good than harm is questionable.

Now this is funny. Is he like a Russian hunter killer submarine? Tightening things up is a good thing, but wasting precious resources on something that arguably does them more good than harm is questionable.

I find the voracity of this dubious at best.

Posted via CB10

Not to mention that if they really wanted to stop leaks they easily could without the need to hire "leak hunters".

Now this is funny. Is he like a Russian hunter killer submarine? Tightening things up is a good thing, but wasting precious resources on something that arguably does them more good than harm is questionable.

Now this is funny. Is he like a Russian hunter killer submarine? Tightening things up is a good thing, but wasting precious resources on something that arguably does them more good than harm is questionable.

I find the voracity of this dubious at best.

Posted via CB10

I'm sorry.. I'm not trying to start trouble or get into an argument. But you say leaks do them more good then harm. How do you mean. What good comes out of leaks?

I'm sorry.. I'm not trying to start trouble or get into an argument. But you say leaks do them more good then harm. How do you mean. What good comes out of leaks?

Posted via CB10

They drive a considerable amount of traffic to forums such as this which keeps interest in BlackBerry at a high level which they should not underestimate.

Secondly, it flushes issues out much better than general carrier testing ever has. I can tell you from personal experience that I have shared issues arising out of leaks directly with BlackBerry employees in the past that were addressed expeditiously.