If it is so easy for the Andriod apps to be converted, why don't RIM offer such a service to the creators to give them a hassle-free opportunity to sell them to BB owners?
Yes all 3 of them - sorry, could not resist!
Devs: 'Pirates are flogging OUR stuff on BlackBerry's App World'
In its enthusiasm to stock its App World shelves, RIM has reportedly inadvertently invited in the pirates, according to Android developers who've said they have seen their work replicated at the burgeoning store. Android devs said they had seen their apps turning up in RIM's App World despite their lack of interest in the …
-
-
Wednesday 9th January 2013 21:49 GMT bazza
@AC
If it is so easy for the Android apps to be converted, why don't RIM offer such a service to the creators to give them a hassle-free opportunity to sell them to BB owners?
They do! Even the most moronic and idle of commentards should be able to discover that with a simple Google search. Download the SDK, and then it's about a half hour job to do the port and its free to list on the RIM app store. Not a bad deal considering that almost any sales would mean a profit. RIM's point is that if you're in the business of writing Android apps you may as well port to BB too because the cost is so low.
If Android devs can't be arsed to port their apps to BB but yet are entirely happy to distribute their software on a platform as insecure as Android, its not surprising that someone else has taken advantage of the opportunity. That's hardly RIM's fault! For example, Amazon haven't done a Kindle reader for the Playbook, yet someone out there has unofficially port the Android version. [That's not even on RIM's app store, you have to download and side load it.]
RIM have implemented a Dalvik VM on top of their QNX based OS. The only reason why you can't run Android apps as is with no modification is because RIM make a developer repackage the app using signing keys that are traceable directly to that individual developer.
The bad news for the pirates is that for an app to get on the RIM app store they will have had to have given RIM a valid email address (so as to get the signing keys), and presumably their IP address too when they uploaded. That means that their anonymity is reduced, and RIM are probably in a good position to support the wronged original authors.
-
Wednesday 9th January 2013 23:42 GMT Confused Vorlon
easy conversion service
They kinda do. You can go to their website and upload your apk with their web based tool and it will package up your app for Blackberry. After some java jiggling, it looks like it should be pretty simple when it works.
The fact that most devs haven't bothered gives you an idea of how credible Blackberry is at the moment.
Of course, there are a bunch of APIs that don't work - so my app just fails the bundling process (it uses multicast wifi for bonjour).
-
Thursday 10th January 2013 08:07 GMT bazza
Re: easy conversion service
"The fact that most devs haven't bothered gives you an idea of how credible Blackberry is at the moment."
As I understand it RIM have made it effectively free (with a degree of guaranteed income) to put apps on their store. If the port process does work out to be simple, why wouldn't you? It almost doesn't matter whether Blackberry is credible or not, nearly free money is always worthwhile.
"Of course, there are a bunch of APIs that don't work - so my app just fails the bundling process (it uses multicast wifi for bonjour)."
That's a pity, I was hoping that RIM would have strived to do as complete a job as possible at replicating the Android Dalvik environment. I hope they're being responsive and helpful (you know, the kind of things that a struggling outfit needs to display if they're going to engender good will). Good luck.
-
Thursday 10th January 2013 15:29 GMT Mark .
Re: easy conversion service
"The fact that most devs haven't bothered gives you an idea of how credible Blackberry is at the moment."
I'm not sure that argument works. I mean, just look at how loads of companies support only iphone, or iphone first, despite the reality being that iphone was never number one, and Android massively outsells it. I'm not sure what the reason is - but sadly, choice of platform to port to has never been about credibility or market share. Possibly it's about perception, which I guess you could mean by "credibility", but I think it's wrong to blame the platform, for myths held about the market by ignorant people.
Thanks for the info though - if it's possible to do this without needing a device to test on, I may give it a try. Even though BB share has declined rapidly in recent times, (a) there's still a large installed userbase (it sold way more than iphone for years - oddly no one poked fun at iphone's lousy share by then, so I don't see why it's okay for some to do so now for BB), and (b) a key point is that there's less competition.
I mean, although Symbian was number 1 until 2011 and has a reasonably large installed userbase still, I would guess that Android has definitely overtaken it now, significantly - but I get a staggering one hundred times the downloads compared to on Google Play (reproduced across multiple apps). (For a similar reason, I've heard the Amazon and Nook store are worth releasing on - despite smaller market, there's also less competition.)
In fact, I'd be more than happy for these "pirates" to do it for me, since my stuff is GPL...
-
-
-
Wednesday 9th January 2013 15:56 GMT Anonymous Coward
building sailing ships in glass bottles
Because of the same reason that building sailing ships in glass bottles has gone out of fashion. Unless the BB device has Tardis like properties and RIM infinite development resources, oh wait.... the reason RIM would need an emulator is because it does not have infinite development resources.
-
-
Wednesday 9th January 2013 17:37 GMT A J Stiles
Emulators
Because if you offer an emulator, you are -- to all intents and purposes -- admitting that whatever target architecture you are emulating has already won, and you are reduced to providing some token support for it because you couldn't do anything better. And also, unless you have some totally unmissable killer app on the host architecture, there's a chance that the customer's next purchase may be the native version of the emulated target.
Microsoft aren't going to offer an emulator to run Android apps (downloaded from the Google Play store) on Windows Phone. Google, on the other hand, would love the thought of such a thing, because a user who has seen emulated Android apps is a user who might buy an Android phone.
-
Wednesday 9th January 2013 18:31 GMT Anonymous Coward
>> admitting that whatever target architecture you are emulating has already won
Very sound point - Symbian fell afoul of this with *nix compatibility - originally there was a very cut-down stdlib implementation with the explicit goal of just barely getting the Java VM to run and the app story was "for full grunt learn to love Symbian C++ or go the MIDlet/applet way". And the story on grunt was impressive at the time: SOS was engineered so that sensibly-written code was both frugal and safe.
But it was apparent that native SOS C++ was a real deterrent (poor tools, mediocre documentation, source not available, no automation for porting) so large efforts were devoted to supporting much of the POSIX APIs, resulting in a large stack of code with unimpressive performance and inadequate POSIX compatibility (eg the set of independent SOS file and comms services were never perfectly hidden under file descriptors). So the trade-off was more apps but less differentiation from competing platforms; taken to an extreme for apps developers a SOS device would have just been an irritating variant on a *nix phone. And about the same time the traditional SOS advantage of frugality was bypassed by Apple & Android, as it became evident that the market was very happy to trade-off device cost and battery life against features and responsiveness: the microwatts saved by a native SOS app were irrelevant set against the big-screen backlight.
At least in the past the Microsoft answer was "Hotel California": make it extremely easy to port into your platform (be it document formats, keyboard mappings (Excel 2010 still has some Lotus 1-2-3 support), lots of good doco), and not such good support for leaving. Of course this doesn't address the needs of cross-platform developers looking to maintain a single code base but that used to be less common - and really you want your platform to capture and hold developers. Speaking as a developer this is of course EVIL, but their shareholders across a couple of decades have a different take.
-
Wednesday 9th January 2013 22:23 GMT bazza
@ AJ Stiles, & Mongo
admitting that whatever target architecture you are emulating has already won
It's not a sound point at all. RIM are not running the whole Android OS in a VM on top of QNX - there's no need to do that at all. Android apps run on a Dalvik VM on both Android and BB Playbook. In what way is the Android Dalvik VM running on ARM any better or worse in principle to the RIM Dalvik VM also running on ARM?
RIM have been quite clever, and Google have been a bit thick. By using Dalvik Google have created a means for anyone and everyone to exploit Google's hard work for their own ends, and because it's open source there's nothing Google can do about it. RIM are merely doing so in a way that, arguably, puts Android apps in a more controlled and reliable ecosystem (e.g. stronger app signing, a permissions system that actually works, etc) than the anarchistic world of the many Android apps stores and manufacturers.
If you think RIM have been a tiny bit cheeky in doing this you should see what the Chinese mobile outfits are doing with Android. They're making handsome money by de-Googlising Android completely, and selling mobiles that point users at their own search engines, email servers, etc. Google do all the work, these guys make all the money in China from sales and advert revenue.
Mongo's point about the need to do POSIX properly is good. Symbian did make a mess of that (with good reason initially - they were trying to save as much power / RAM as possible). As far as I know QNX (which underpins RIM's BB10 and Playbook) has a full POSIX implementation, and Qt also. There's a few apps on RIM's store which seem to have been ported this way from Linux (e.g. Stellarium).
-
-
-
Wednesday 9th January 2013 15:53 GMT stu_ekins
It's not surprising.
RIM are making it really quite simple to port, and they're even providing cash incentives to get apps converted and in to their store.
e.g.
"...Research In Motion® experts will be on hand to answer your questions and help you get your apps ported or built quickly.... You’ll receive $100 USD for every approved app you submit (up to a maximum of 20 apps per participant). "
"if you earn a minimum of $1,000 USD on your app over 12 months, and comply with the Terms and Conditions, RIM will pay the difference between your earnings and $10,000 USD for your app."
-
-
Thursday 10th January 2013 10:04 GMT Charles Calthrop
Re: 'easily achieved with reversible Java code'
“A very extraordinary thing has struck me.”
“Something funny, as usual,” said Cummings.
“Yes,” I replied; “I think even you will say so this time. It’s concerning you both; for doesn’t it seem odd that Gowing’s always coming and Cummings’ always going?” I fairly doubled up in my chair, till it cracked beneath me. I think this was one of the best jokes I have ever made.
I love Diary of a Nobody, any excuse to wheel out the old classics
-
-
Wednesday 9th January 2013 16:27 GMT jai
Re: Why aren't they doing it themselves?
As evidenced by this article, not all Android apps run smoothly on BB. So why bother with having to support the handful of BB users? To adequately support it, you'd need to buy the hardware and divert time and resources away from your support of the Android platform. I suspect most devs just aren't willing to take the chance until there's proof that the majority of RIM10 users aren't other developers (and pirates it would seem).
-
-
Wednesday 9th January 2013 16:45 GMT Ralph B
RIM conflicted much?
RIM have to balance:
1. Being able to claim X thousand apps in their shiny new app store;
2. Not being seen as playing host to a bunch of pirates.
So, they've decided to "deal with complaints promptly" - i.e. ther're leaving it to the poor pirated Android devs to find the crims - rather than pro-actively route out the pirates themselves.
Quelle surprise!
-
Wednesday 9th January 2013 16:46 GMT DrXym
Reversible code
Anyone uploading an app to Google marketplace is encouraged to obfuscate their code and make use of the licence verification library (LVL) which is a client side bunch of classes provided as source code that the dev is meant to modify and call at various auspicious and inauspicious times.
Apps should also make their own secondary checks, e.g. maybe they call the LVL once in an obvious way during startup but call it again in some corner of the app where it's likely to be uncovered by casual inspection. Apps could also phone home for a message of the day and pass OS version and other stats in the call which could alert someone if something is amiss.
While this does not make apps crack proof it does turn the effort into timesink and that alone might be enough to deter counterfeiters or limit the amount of apps they get around to pirating.
-
Wednesday 9th January 2013 22:35 GMT bazza
Re: Reversible code
While this does not make apps crack proof it does turn the effort into timesink and that alone might be enough to deter counterfeiters or limit the amount of apps they get around to pirating.
It depends. Back in the days when expensive CAD software for PCs (e.g. AutoCAD) was dongle protected it seemed to take the pirates hardly any time at all to hack through and remove all the references to the dongle check library.
I suspect that the best form of defence against this particular pirating mechanism would be for the dev to do the port themselves. They might even make some money on it!
-
Thursday 10th January 2013 00:07 GMT DrXym
Re: Reversible code
I agree but at the same time, there is a time and effort to maintaining different versions of the same app.
I have a couple of apps on blackberry and a few other stores and to test and verify it's working, produce art at the appropriate (and different from other stores) resolutions takes in the order of 6 hours. It's made all the worse because when I upload a new version of the app I have to sit around for days waiting for approval so it's not like on Google market where I can turn around releases in response to bugs.
I do actually make a small amount of money out of the apps being up, probably disproportionate to the size of the platform but the main incentive was the free tablet that was on offer at the time. So I could see why some people, especially those without the hardware to test might not be bothered.
My next app is a screen saver of sorts so I doubt I can port it even if I wanted to.
-
-
-
Wednesday 9th January 2013 17:45 GMT Anonymous Coward
Android compatibility
Already there on the playbook, seems to work on pretty much all games, apps that utilise the camera and mic are the most troublesome.
Fact is it's easy to download the android apps and convert to .bar (if someone hasn't already done it for you) and sideload them. Some have their quirks, mostly to do with the android back button and sub menus but are ultimately functional.
The crazy thing is that developers are not doing this themselves, especially with the incentives BB are offering. As it stands either the pirates are cashing in or the apps are available elsewhere for free anyway. Regardless of the relatively small market place it's still a missed opportunity for the sake of little effort.
If the developers had no intentions of recompiling their apps for BB then they they aren't losing anything if someone else does. Although it doesn't make it right that someone else is cashing in either.
-
Wednesday 9th January 2013 19:11 GMT Blain Hamon
"then they they aren't losing anything if someone else does."
The problem comes that they ARE losing something. Even if they never enter the BB arena, if said pirate makes a crappy port, or that the app isn't designed for BB and thus has some issues that aren't otherwise on Android, it hurts the appmaker's reputation and would cause support calls (like what happened in the article) that wastes the developer's time, energy, and possibly money to even find out that it's a case where the app isn't being used in the way it's designed.
That's the danger, and that's why even a free port done with the developer's permission (or by their own hand) isn't really free.
-
-
Wednesday 9th January 2013 21:06 GMT Anonymous Coward
Java is the real problem.
The simplest answer is to stop using Java like it's a blood line, or at least the only option. I will never understand how the Android NDK isn't a top priority for Google.
Google: "In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++."
The above statement literally reads to me... why would you choose something you like, when you can have something you don't like? I'm not sure how Google's statement will read in 2 years, but I'm sure it won't read like that. You can almost count the days until Google puts out a press release in regards to the NDK that will read "This is how it should be done".
-
Thursday 10th January 2013 00:11 GMT DrXym
Re: Java is the real problem.
I do believe apps writting in C have been hacked for a long time before Java ever turned up. It's no magic bullet since someone could feed a lib through a disassembler and it'd probably make more sense than obfuscated dalvik byte code. Of course there is nothing to stop some of the app being written in the NDK via JNI and leaving the bulk in Java but then there is the extra burden of supporting MIPs, x86, ARM 7 variants or just one of them, cross compilation issues and so on. It's too bad the NDK doesn't support LLVM as one target since it might just become more popular if it did.
-
Thursday 10th January 2013 01:30 GMT Anonymous Coward
Re: Java is the real problem.
>The simplest answer is to stop using Java like it's a blood line, or at least the only option.
>I will never understand how the Android NDK isn't a top priority for Google.
What does the NDK not do now that you want it to do? I have no problems using the NDK for what it's intended for; Creating shared libraries containing performance critical or ported code to interface with via JNI.
>Google: "In general, you should only use the NDK if it is essential to your app—
>never because you simply prefer to program in C/C++."
The UI framework is all written in Java... NativeActivity exists for applications (activities) that don't want any of the Java APIs like the UI framework.
>You can almost count the days until Google puts out a press release in regards to the
>NDK that will read "This is how it should be done".
For games there is no reason not to go 100% native (although you can write pretty decent games in Java via libgdx) and there is an SDL port that mostly works if you want it to be "portable". I very much doubt google are going to start promoting C/C++ as the way to develop apps considering all of the high level APIs are implemented in Java and the libraries you use to get access to stuff like the screen, sound etc are limited and vary between versions of Android.
I think the point you were trying to make is; Java == Easy piracy. Java can be reverse engineered but so can C. You should take a look at something like IDA (http://www.hex-rays.com/products/ida/index.shtml). The issue with a lot of cracked Android apps was that the dev only called the license check once at start-up and used google's code without making any changes.. and then didn't use proguard so it's very easy to remove the single license check. A similar issue but for "applications" written in assembly or C is "save patching" in console backup units. Backup units don't have all of the different backup types that are possible.. they rely on the fact that game developers link against a library supplied in the SDK to handle the backup storage.. so all the patcher needs to do is search for a signature of the library and replace it.
-
-
Thursday 10th January 2013 10:51 GMT jamroo
Labels
Oh, I do wish Artists and Authors wouldn't spend so much 'of their time searching for illegitimate copies of their own work'.
It's a miracle any music/apps/literature gets made at all really.
Perhaps we could band together, under some kind of collection of artists, possibly funded by a corporation, then pay heavy handed thugs and bullies to patrol the internet highways, and throw fines and threatening letters out willynilly to anyone who gets in our way.
Ofcourse, the corporation would take most of the profits, for their hard work and participation in protecting and creating these works of art.
-_-
This topic is closed for new posts.
Biting the hand that feeds IT
