[shn'g]

So after having long enough to play with OS 2 and use the android player I just wanted to see what others think about it?

To be completely honest I'm not a huge fan of it right now. I was at the start but now after using it for awhile I find it to be buggy and overall doesn't work that great. Maybe this is just personal experience though or I am too impatient. I find that games work overall actual fairly good on it! But when it comes to apps I have had many freezes, crashes, and just the lag of some apps is too much for me to take. I am beginning to think that RIM should have just stuck to native apps. Don't get me wrong I do enjoy some apps and they come in really handy such as taptu I think was ported really well but again there is that lag with the app compared to native apps.

I think what would have maybe been a good idea is give us the choice as to wether we want to use the android player, turn it on or off. But again just my opinion. Are others enjoying it or finding the same thing as me?

[dbmalloy]

It already is an option.... If you do not want to use it do not download apps for it... As it launches per android app... If you had no Android apps you would not even know it was there..... So in essence it is optional....

[shn'g]

It already is an option.... If you do not want to use it do not download apps for it... As it launches per android app... If you had no Android apps you would not even know it was there..... So in essence it is optional....

yeah i see your point but how do i know when i am downloading an android app from app world? I know most I can tell but some I can't.

[Bakamushi]

Yes I too would like to know whether it is an Android app before downloading.

I found one educational app which is great but for productivity not so much. There is a huge load of Android junk already. Even some employees at RIM say they are surprised. I thought the Appworld was an opportunity to select the best but... no.

Overall it's just an emulator so finding a native version will always be better, at equivalent levels of features of course.

[dave1701]

I just want RIM to fix it so that running the android player once won't render my whole playbook unstable and require me to reboot. There are some android apps that it I would like to use but until they release an update, I will be steering clear of the android player.

[ralfyguy]

I just want RIM to fix it so that running the android player once won't render my whole playbook unstable and require me to reboot. There are some android apps that it I would like to use but until they release an update, I will be steering clear of the android player.

Same here. What I don't like is the fact that just because you have just One android app installed and not actually even running/using it, it still seems to keep the android player activated and burning about 200mb of RAM just for that. I don't mind for the app to take 200mb to run, the native browser does just that, but NOT if I actually want the app to be closed. If I had a switch to turn that off, I would even try an Android App.

[shn'g]

Same here. What I don't like is the fact that just because you have just One android app installed and not actually even running/using it, it still seems to keep the android player activated and burning about 200mb of RAM just for that. I don't mind for the app to take 200mb to run, the native browser does just that, but NOT if I actually want the app to be closed. If I had a switch to turn that off, I would even try an Android App.

yeah this is what I get annoyed at to.. thats exactly why I would like the option to!

[Zildjian71]

IMO I think tech DNA should be kept separate unless there are protections like in a true virtual environment. Windows on a Mac is proof of that protection.

Android apps belong on quality Android devices IOS on Apple devices,.etc.

The Android Player is not a protected virtual environment and if the Android Player reflects the protection abilities of BlackBerry Balance for PB use in a corporate domain then RIM has problems. I hope that it isn't so. It may well be that the Android Player is the tutor for RIM to get it right for BlackBerry Balance.

Bottom line, Android is risky on any device in its current versions. Yes some Android devices run well but they are few compared to the whole Android eco system.

[samab]

The Android Player is not a protected virtual environment and if the Android Player reflects the protection abilities of BlackBerry Balance for PB use in a corporate domain then RIM has problems. I hope that it isn't so. It may well be that the Android Player is the tutor for RIM to get it right for BlackBerry Balance.

ALL apps run within the Android player is considered "personal" in Blackberry Balance.

Secondly, I would say that a lot of the problems and crashes experienced by Playbook users with Android apps --- are not problems with the Android player. Most of the android apps are submitted (legally) by Handster on behalf of the app developers. Handster doesn't have the source code to these apps --- so these apps cannot degrade gracefully.

So if Handster submits an Android app that has a button to send your game score to another person via SMS. Well, both the Playbook and android player don't support SMS --- so when the end-user press that button in the Android app, of course the app would hang. Only the original app developer has the source code to change the app --- either to remove that button or when you press the button, a dialog tells you that this feature is not available on this version of the app.

[masqueofhastur]

Yeah, if the app world indicated that it's an Android App you could choose not to install it.

[Zildjian71]

Yes most of the Handster apps are problematic but there are other apps that have issues as well. For best performance apps need to be ported natively but that would depend on several tools not yet available.

[diegonei]

IMO I think tech DNA should be kept separate unless there are protections like in a true virtual environment. Windows on a Mac is proof of that protection.

Android apps belong on quality Android devices IOS on Apple devices,.etc.

The Android Player is not a protected virtual environment and if the Android Player reflects the protection abilities of BlackBerry Balance for PB use in a corporate domain then RIM has problems. I hope that it isn't so. It may well be that the Android Player is the tutor for RIM to get it right for BlackBerry Balance.

Bottom line, Android is risky on any device in its current versions. Yes some Android devices run well but they are few compared to the whole Android eco system.

Sorry but I don't get your point. How is the player not secure when it is sandboxed and does not allow for the apps in it to access info on the rest of the device?

Yes most of the Handster apps are problematic but there are other apps that have issues as well. For best performance apps need to be ported natively but that would depend on several tools not yet available.

Again, I don't see your point. Most of the tools are available. Cascades isn't available. Cascades by no means whatsoever prevents devs from porting apps.

See how many (ProInsights for one, that other app that was ported in ONE DAY is another, and there is that other that saw better profit in one day in appworld than in an year in the Android Market - sorry if my memory betrays me for the names., it's 3:29am here as I post this) of them are ported and working as planned.

[Zildjian71]

Sorry but I don't get your point. How is the player not secure when it is sandboxed and does not allow for the apps in it to access info on the rest of the device?

I did not say secure. I said protected as in not violating the host OS or partitions in RAM which sandboxing can't always protect because the guest app needs access to system resources. A true virtual environment creates pseudo or virtual system resources for the client OS to operate in thinking it has its own hardware. A player must allow system access to the host hardware to run therefore it is not a protected environment.

Sandboxing IS for data security only as you imply.

[Zildjian71]

Let's go back to the Windows on a Mac example. Windows can not run on Apple processors because they are not compatible, the virtual environment provides Intel like processor and motherboard translators in RAM so that Windows thinks it is installed and running on an Intel compatible motherboard with a NTFS partition on the Mac harddrive. It has its own virtual hardware without directly accessing the Mac OS thus protecting the Mac OS.

Also in a different light the Mac version of MS Office for the Mac is a true Mac native app not a port.

This is the problem for many ported Android apps is that they must have Android hardware, where a true native rewrite would solve the problem but cost more to do which is the temptation that is causing the problems...it is cheaper to port than rewrite.

With that good night as I need to get to bed as well.

[samab]

I did not say secure. I said protected as in not violating the host OS or partitions in RAM which sandboxing can't always protect because the guest app needs access to system resources. A true virtual environment creates pseudo or virtual system resources for the client OS to operate in thinking it has its own hardware. A player must allow system access to the host hardware to run therefore it is not a protected environment.

Sandboxing IS for data security only as you imply.

Let's go back to the Windows on a Mac example. Windows can not run on Apple processors because they are not compatible, the virtual environment provides Intel like processor and motherboard translators in RAM so that Windows thinks it is installed and running on an Intel compatible motherboard with a NTFS partition on the Mac harddrive. It has its own virtual hardware without directly accessing the Mac OS thus protecting the Mac OS.

Also in a different light the Mac version of MS Office for the Mac is a true Mac native app not a port.

This is the problem for many ported Android apps is that they must have Android hardware, where a true native rewrite would solve the problem but cost more to do which is the temptation that is causing the problems...it is cheaper to port than rewrite.

With that good night as I need to get to bed as well.

Except that Dalvik is a VM. It is a VM --- whether it is sitting on top of linux or QNX.

Are you telling me that an android app running on the Kindle Fire is different than running on the Playbook --- even though both have the same OMAP4430 CPU.

[varunsain]

People and their problems with everything good or bad.

[Superfly_FR]

I agree to both following points :
1/ It is optional by nature (if you don't use android apps, it won't even load)
2/ We should be noticed wether an app is android or not, or have an option within AppWorld to list/unlist android ported apps.

[rkennedy01]

Let's go back to the Windows on a Mac example. Windows can not run on Apple processors because they are not compatible, the virtual environment provides Intel like processor and motherboard translators in RAM so that Windows thinks it is installed and running on an Intel compatible motherboard with a NTFS partition on the Mac harddrive. It has its own virtual hardware without directly accessing the Mac OS thus protecting the Mac OS.

Also in a different light the Mac version of MS Office for the Mac is a true Mac native app not a port.

This is the problem for many ported Android apps is that they must have Android hardware, where a true native rewrite would solve the problem but cost more to do which is the temptation that is causing the problems...it is cheaper to port than rewrite.

With that good night as I need to get to bed as well.

Errr...that explanation is SO wrong on SO many levels. For example: Macs use Intel chips, just like Windows PCs. In fact, you can install Windows 7 onto a Macbook Air a create a bitchin' ultraportable PC...

RCK