In short, my battery life problems are summed up as: Using a stock Nexus S firmware, wifi and bt off, signed into Google services, sitting on my desk with the screen off, I lose 85% of my battery in 8 hours. No voice calls are made. The screen's off for this period of time.
If I turn off all radios, my standby time rises from 9 hours to 6 days (where those 6 days includes me using it as a mp3 player in my car both directions of my commute, so it's actually better than 6 days) So the hardware's fine with this regard. Something's severely messed up in software.
I've signed out of Google Latitude already. The task killer helped maybe give me one more hour standby with cell radio on. All I'm left with off the top of my head is Gmail, Google Voice, the system's built in software updater. Perhaps there's something else, but if so, it was setup automatically by Google to a Google service. I've read the android multitasking article in the past; it sounds reasonable. Unfortunately, this basically leaves a Google service as the blame for the poor battery life showing.
You'd need to consider what can be done once dev mode is switched on.
Yes, most apps, like skinning the UI and installing a MiFi-ish router program is not likely to break the hardware in a way that running the normal reflash routines couldn't fix.
But then there's the radio unlock tools. Like any device, a phone doesn't have a single firmware. It has, at least, a 2nd one for the radio. And perhaps plenty more. If you upload bad firmware, not all microcontrollers are as easy to work with once you're out of the hardware development board/factory. The iPhone 1.1.1 "bricking" was because the early unlocks inadvertently tweaked the code used to flash firmware. Think about it this way, if I was an average user and used nvflash on my PC with the wrong ROM to update my video card, why should nvidia or any card manufacturer be responsible to fix it? If I ran a BIOS update utility for my mobo, and then accidentally kicked the power cord. Why should my mobo manufacturer be responsible for fixing it?
The only reason is demand. Or... lack there of. I'm guessing less than 0.1% of all smartphone users would be interested in rebooting their phone into another OS. Nearly all of them would probably end up using one OS or another permanently in the long run.
Most people I know including myself who got MacBooks were thinking, "whoa, I can get kick ass hardware, run iMovie and still boot WinXP? Sweet!" Eventually, I blew away Boot Camp, and now periodically run XP in VMware for my printer cleaner utility.
If Nokia were to make a MeeGo/WP7/Android triple boot phone, the sysadmins would use MeeGo, the gamers would use WP7 for xbox live integration, the FOSS people would use Android, and the rest of the people would probably do a 25%/75% split across WP7 and Android. With a huge capacity penalty.
Multi-boot isn't a good solution. But... having a phone platform which lets you flash to the config you prefer might help reduce hardware production/inventory costs. Let the user decide what kind of interface they want, as long as they buy your hardware. You'd still have major development costs on the software side, but it's slightly better than maintaining two independent phone lines.
Samsung's partly there. Their Galaxy S phones and their WP7 phones aren't too different on the inside.
I got a Nexus S days after it came out. And I have some battery problems with it. When I mention these problems I either get one of these responses: 1) Works for me, you must be doing something wrong. 2) Must be the firmware. Go install another firmware, it's an open phone. (I'm using stock, btw) 3) Try a task killer. (been there, done that, ATKFree helped marginally) 4) Try xyz battery log thing, and find out which app's using some idle lock thing, and install this random package that's repackaged from android source or something to get extra utilities or other. (Really? I am a developer. And usually I do like to tinker. But doesn't this sound a bit far to go to get the stock android distro working acceptably?)
In the end, the easy solution for me is to disable data access until I need it otherwise my battery life is 9 hours idle. Not talking or browsing, but sitting on a desk idle. With wifi off. And all I know is that it's a Google service keeping the radios awake with data access.
I just got an iPhone 4 on Verizon the past week to try out. Yeah, it drops a bar if I hold it funny. I expected that to happen even before a single blogger posted about it. Doesn't matter to me because the call still goes through.
In the end, this whole mobile war thing just gets people riled up because so many people identify with the brand/camps they're in. I have a friend who's betting on the Xoom; not because he knows anything about how well it might work, but only because he owns a Droid. Personally, I feel that's the wrong reason. Heck, I'd be interested in checking out the new webOS tablet even though my workplace's vested interest is in the iOS platform. (though, yes, I'm a bit of a mobile device collector:P)
So it took a while but I logged some data using the Battery Monitor Widget. Basically, the phone sits in 4mA to 8mA idle for an hour or so, and then jumps to 15 to 30mA for about 3 hours. Then returns to 4-8mA for about 3 hours. Periodically, this cycling occurs over 1 hour instead of 3, but more often 3.
Here's the list of apps installed: Advanced Task Killer Free Angry Birds Awesome Drop Battery Monitor Widget Google Chrome to Phone ConnectBot Google Goggles Market
There isn't much choice I have in terms of what to "uninstall and find better behaved alternatives".
And, the battery usage info under phone settings is pretty useless. It claims most of my battery went to Google Services and Music. I was going to try to download Spare Parts from the market, but it felt questionable to get it from the market. I'd probably rather download from source and compile it myself later.
The way I see it isn't that Motorola, Samsung, and HTC arn't bad at Android software, it's just that the stock Android software is bad. I haven't owned a Nexus One, but I did play with a friend's when it first came out, and "slow as balls" describes that perfectly as well. It's not very reassuring to me that even using Google-supported devices, there's quirks that just arn't acceptable.
From what I can see, there's something polling the net as the phone's idle, keeping the radio on. So turning off all the radios causes that app to not drain as much. The problem is, I'm using an almost stock Nexus S. I've got GMail and Google Voice configured. And I periodically use Google Maps. When I did this test, the only software installed (aside from the default ROM) was Angry Birds and Google's Chrome to Phone (not yet configured, so it's probably not doing anything). So probability says it's even a Google app that's running amok with my cell radio.
Your numbers sound pretty darn good, but I'm not sure how to get any closer to those kinds of numbers without turning it into an ipod touch equivalent. I'll be giving Advanced Task Killer a go since a friend recommended it to me because it helped her.
Strange, I've found that the Samsung Galaxy S units (Friend has a Captivate) seem smoother in terms of UI responsiveness than the HTC Evos I've played with. Also the Captivate and Nexus S were definitely smoother than the Motorola Atrix I played with at CES.
My problem actually hasn't been the AMOLED display, it's the OS' incessant need to use the radio when it's in my pocket. (But yeah, the display does eat batteries too)
If I leave the phone on a desk idle without touching it (display off, bluetooth off, wifi off, cell on) for 8-9 hours, I got 20% of my battery remaining. If I leave the phone mostly idle (did play mp3s for my car for 3 hours) but all the radios off, I got 90%+ remaining.
Friends with Moto Droid 1s and other Nexus S units I've talked to are unsurprised, so I could only conclude that this is considered normal. (while I didn't get mine free from google, most of the people I know with Nexus S units got them as their employee holiday gifts)
Well.... KDDI uses CDMA2k and all their handsets are based off brew. Given that they're #5 in the world according to http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats Then I'm guessing BREW's still trumping Android by a long shot since it's basically part of the dev kit for each CDMA2k-based handset/modem.
You're using the Android battery logger thing on your G2? If my Nexus S counts for a point of reference, the percentage values it gives are total crap.
It claims my screen is the thing that takes 68% of my battery power when my phone's screen has been on for about 10 minutes out of 8 hours and my battery's down to 20% from 100%.
You know, I have a feeling it's that Honeycomb itself won't require dual-core. But that Google will require dual-core in order to be allowed to ship with Android Market and the "with Google" branding.
While I totally admit that setting up an iPhone is more involved because of iTunes, I have to say that as an owner of an original iPhone 2G, a Nexus S, and a Motorola Q (WinMo6.5), superficially, they're all the same.
When it comes to the little details, like polish or number of annoying things, my experience is that Android phones lose by a wide margin. (well, at least my Android phone sucks) Want some examples?
Camera App/Gallery: Atrocious. 1) Well, actually, when I first launched it, it looked pretty cool with the animated flow thing showing me the few Picasa albums I have up. That's about all that's good. 2) Either the camera is totally awful, or there is a limit to how much detail it'll let you zoom to see. 3) When you delete the last picture, a blurred leftover version of the last picture is left onscreen, and half the UI thinks there's still a picture. The rest of the UI is interactive, but accomplishes nothing. It's like everything's just trashed. Menus don't even appear sometimes when you hit the menu button. Back doesn't seem to work right either. 4) Multi-touch interaction : pinch to zoom. It's awful, it anchors using some arbitrary point that I can't figure out. The result is that the zoom will shift what you can see away from what you wanted to zoom. At least they did it right in Maps.
Capacitive touch-sensitive buttons: Capacitive buttons suck in general. They sucked on the LG Chocolate years ago. And they suck now. They activate on the slightest brush. They're also not tied to the rest of the UI from a usability standpoint. If you swipe using a finger down the screen and just past the boundary of the screen in your followthrough, you hit a button AND it activates. This is frustrating.
Buttons on BOTH sides of the device: It bugged me a little on the Motorola Q when I first got it. But since the buttons are pretty stiff, it wasn't that bad. The Nexus S pushes that problem to a whole new level because the sleep switch is on the side now because there's no other physical buttons on the front. Put side buttons on one side, not both. Because if you put it on both, without looking at your phone every single time, you're bound to press both sides at the same time because you need something to push against. This is hella annoying especially since it's the wake button across from the volume-up button. So yes, without contorting my hand, my volume goes up or down every time I turn on the phone.
Music playback app: For some reason if I wake from sleep when not playing, the playback shuttle sometimes jumps to a new location. It's kinda annoying. Actually, I have a funny feeling it could possibly be due to the way I have to hold the phone to unlock with one hand (using the thumb) and avoid the side buttons. The retracting of my thumb might be close enough to register as a press on the playback shuttle. I'll investigate more another time.
Location Services: Anonymous always-on statistics gathering? Really? wtf? (for comparison: the iPhone uses Skyhook, which also gathers base station statistics in order to do wifi-location when location has been requested and the presses an allow button. But Android will gather even when you're not using location services. It just sits there and spys.)
Yeah, and on my Nexus S, I found out that the battery usage logger built into the OS isn't even correct.
With the cell and wifi radios on and the screen off, letting the phone sit by itself. It dies in a day. The radios barely show up on the logger. With all radios off, the phone is 50% dead after 3 days... and I'm even using it to periodically play a bunch of MP3s.
That suggests that the bottleneck isn't the GPU or CPU most of the time, it is the speed of flash memory and by extension the amount of available RAM (since more RAM = more caching and less flushing.)
Unfortunately, that doesn't really make any sense since the Galaxy S series has similar(probably even same) flash to the iPad and Samsung Windows Phone 7 units, but at least the iPad doesn't suffer from the same lag.
A variant of that idea I rather liked. I had a professor who liked to give 'tests of 2'... i.e. every answer on the test was '2'.... but better show your work.
Haha, at Cal, every homework for my Signals and Systems course involved at least half the answers being 0. How you got the zero mattered more than the answer.
What you fail to understand - and searching on Apple iPhone exploits shows - is that the pre-screening Apple gives has *no bearing on the security of the phone*.
So how does a scan for what APIs your app calls not have any bearing on security?
Nor are the immune to the description you give of the G1's - ask anyone with any hardware before the 3G where all their shiny new updates are.
If you read the point I was making, it wasn't that the G1 doesn't have updates. It's that Google can only push updates directly to end users of the G1, N1, and MyTouch dev phones. Google cannot push updates directly to users of other handsets like the Droid, the Epic, the Evo, and all other handsets/tablets/etc.
But yeah, the fact that Google is no longer supporting the G1 is true too.
Indeed, the original iPhone is in the same boat as the G1. But unlike the original iPhone, the following phones haven't been out for 3 years yet and still don't have 2.2 either: the G1, the Droid Eris, the Motorola Backflip, the Motorola Devour, Samsung Behold II, Samsung Moment, Motorola Cliq, and the Sony Experia X10. (Has the 2.2 rollout for the Samsung Epic 4G and Captivate hit the US yet?)
Sure, you can flash an unofficial rom just like you can patch a jailbroken iPhone 2G. But the common user isn't going to understand how to do either.
I do not find apples "sandboxing" (which they aren't doing at all - they are simply saying you can only buy software at your local Best Buy which is *not* sandboxing - they are a walled garden, not a sandbox) to be useful from a security point of view because it gives me *nothing* that enhances that. Google really doesn't either - while the OS certainly does real sandboxing (which apple doesn't at all) installing applications generally requires you to give blanket permission that pretty much break this as a security feature too.
As for sandboxing, I have no idea what you mean by "walled garden, not a sandbox." But what I do know is that the iPhone indeed has a sandbox.
If you write an app to do something not allowed, say, open a serial port, then compile and load an app using the SDK. It'll exit as soon as open is called because the kernel killed it. Yeah. I tried it pretty early on.
This isn't some simple, "ooh, you can't install it, so it's protected" naivety. It's that processes loaded from the app store are killed or denied access by the kernel if they try to go out of their sandbox.
1) This IS a conventional method as designed by the SD Association. (It's the S in SD) 2) They label this slot as a manufacturer intended slot. It's not intended to be swapped, just like those 8GBs of internal memory on your Droid Incredible? 3) It's part of a JBOD with the internal memory, so it's contents arn't complete. Taking this card out is like taking a drive from your RAID0 in your computer. 4) Locking it to a device helps prevent accidental erasure by other devices like your PC since it's useless to the PC because it's still a fraction of a JBOD. 5) Locking it to a device (if it prevents read by other devices) also means that you can't take somebody else's card from their phone and dump private data off of it. 6) As other people mentioned, this means that you can upgrade the phone's primary storage unlike all the other phones who have theirs soldered on. This is both a win for MS (simplifies the production line, because it's one phone), a win for the user (can use whatever's the cheapest per meg), and a win for the environment (phones are upgradable) 7) Not all phones have this, it's a feature that the manufacturer can choose to implement.
What better solution? (Encryption costs more in power. Would you rather they be soldered? )
As such I find no security difference and a great deal of usability difference.
You exhibit the same problem as those who blindly support the idea that "security by obscurity is no security at all," in that you appear to dismiss the fact that security isn't made of one thing or another, but the sum of all the efforts to make something secure.
The iTunes App Store does not itself make the iPhone secure. It only attempts to improve the quality and conformity of applications provided to the user. The lockdown/sandboxing of the iOS device itself makes it harder to install apps that have not been vetted by Apple somehow, but it doesn't guarantee security. It only makes it significantly more difficult to obtain user data. The iTunes/iOS update system, can post a patch to all devices relatively quickly and with relative certainty that the hole exploited has been plugged. It doesn't guarantee security.
All of these don't guarantee security. They're all defeatable. The first two are obviously defeated by jailbreaks and that PDF/freetype vulerability. The 3rd one is defeated if the user decides not to install firmware updates.
But together, they make it harder for a user to get exploited. If you try to attack from the official App Store, even if the reviewer was a moron, the sandbox makes most user private data impossible to access. Even if you managed some way to hack through kernel-level sandboxing, whatever you do will get plugged on discovery, and the fix deployed via a system update. (and not only that, the base OS will get reset to an unhacked state, which is probably why the PDF fix was deployed in a full system firmware update of some couple hundred megs, instead of a 100kB patch.)
On the other hand, you have Android. You can install whatever you want. You can access most things on the phone, usually just by letting the user know in vague terms in the install. (or in this article's case, without really knowing at all, provided you have an HTC phone with Flash Lite.) Google only pulls out the banhammer on the marketplace when something's reported to be no good. Google can apply a fix and deploy it to the G1s, some myTouch dev units, and the N1s. But everybody else will wait until their manufacturer pushes the fix. (and Google's own stats say that only 1/3rd of Android users are on 2.2)
Apparently khchung finds the sandboxing in iOS to be a blessing. Apparently you and bigstrat2003 find the flexibility in Android to be more valuable. Either choice is fine with me. (heck, when I first got into the iphone jailbreaking scene, I not only audited the source code for the early jailbreak utilities, but then did all the procedures manually, to make absolutely sure nothing got sneaked in.)
But make no mistake, the security aspects of both platforms are most definitely different.
Absolutely wrong. Softbank's network will allow for an unlocked device with an unrecognized IMEI with just a SIM card change. How do I know? One of my friends has been living in Japan and had been using a WinMo phone from ATT and a iPhone from Taiwan on Softbank for the last 3 years. When visiting, I was also given the option of using a prepaid Softbank SIM on a jailbroken/unlocked iPhone 3G from ATT.
It works.
What you should be complaining about it Softbank not selling prepaid SIMs to foreigners.
Actually, it's not even Apple. It's some random shop trying to cater to the DIY Apple crowd quick making a quick buck, while working through the idea that if they can afford an Apple, they can afford to get screwed over $50 for a screwdriver.
While I think that seems kind of overkill, Filemaker has a product called Bento that seems somehow more fitting for something like this (assuming you use a Mac).
Slashdot Mirror
In short, my battery life problems are summed up as:
Using a stock Nexus S firmware, wifi and bt off, signed into Google services, sitting on my desk with the screen off, I lose 85% of my battery in 8 hours. No voice calls are made. The screen's off for this period of time.
If I turn off all radios, my standby time rises from 9 hours to 6 days (where those 6 days includes me using it as a mp3 player in my car both directions of my commute, so it's actually better than 6 days) So the hardware's fine with this regard. Something's severely messed up in software.
I've signed out of Google Latitude already.
The task killer helped maybe give me one more hour standby with cell radio on.
All I'm left with off the top of my head is Gmail, Google Voice, the system's built in software updater. Perhaps there's something else, but if so, it was setup automatically by Google to a Google service.
I've read the android multitasking article in the past; it sounds reasonable. Unfortunately, this basically leaves a Google service as the blame for the poor battery life showing.
You'd need to consider what can be done once dev mode is switched on.
Yes, most apps, like skinning the UI and installing a MiFi-ish router program is not likely to break the hardware in a way that running the normal reflash routines couldn't fix.
But then there's the radio unlock tools. Like any device, a phone doesn't have a single firmware. It has, at least, a 2nd one for the radio. And perhaps plenty more.
If you upload bad firmware, not all microcontrollers are as easy to work with once you're out of the hardware development board/factory. The iPhone 1.1.1 "bricking" was because the early unlocks inadvertently tweaked the code used to flash firmware.
Think about it this way, if I was an average user and used nvflash on my PC with the wrong ROM to update my video card, why should nvidia or any card manufacturer be responsible to fix it?
If I ran a BIOS update utility for my mobo, and then accidentally kicked the power cord. Why should my mobo manufacturer be responsible for fixing it?
The only reason is demand. Or... lack there of. I'm guessing less than 0.1% of all smartphone users would be interested in rebooting their phone into another OS.
Nearly all of them would probably end up using one OS or another permanently in the long run.
Most people I know including myself who got MacBooks were thinking, "whoa, I can get kick ass hardware, run iMovie and still boot WinXP? Sweet!" Eventually, I blew away Boot Camp, and now periodically run XP in VMware for my printer cleaner utility.
If Nokia were to make a MeeGo/WP7/Android triple boot phone, the sysadmins would use MeeGo, the gamers would use WP7 for xbox live integration, the FOSS people would use Android, and the rest of the people would probably do a 25%/75% split across WP7 and Android. With a huge capacity penalty.
Multi-boot isn't a good solution. But... having a phone platform which lets you flash to the config you prefer might help reduce hardware production/inventory costs.
Let the user decide what kind of interface they want, as long as they buy your hardware. You'd still have major development costs on the software side, but it's slightly better than maintaining two independent phone lines.
Samsung's partly there. Their Galaxy S phones and their WP7 phones aren't too different on the inside.
The problem is on all sides.
I got a Nexus S days after it came out. And I have some battery problems with it. When I mention these problems I either get one of these responses:
1) Works for me, you must be doing something wrong.
2) Must be the firmware. Go install another firmware, it's an open phone. (I'm using stock, btw)
3) Try a task killer. (been there, done that, ATKFree helped marginally)
4) Try xyz battery log thing, and find out which app's using some idle lock thing, and install this random package that's repackaged from android source or something to get extra utilities or other. (Really? I am a developer. And usually I do like to tinker. But doesn't this sound a bit far to go to get the stock android distro working acceptably?)
In the end, the easy solution for me is to disable data access until I need it otherwise my battery life is 9 hours idle. Not talking or browsing, but sitting on a desk idle. With wifi off. And all I know is that it's a Google service keeping the radios awake with data access.
I just got an iPhone 4 on Verizon the past week to try out. Yeah, it drops a bar if I hold it funny. I expected that to happen even before a single blogger posted about it. Doesn't matter to me because the call still goes through.
In the end, this whole mobile war thing just gets people riled up because so many people identify with the brand/camps they're in. I have a friend who's betting on the Xoom; not because he knows anything about how well it might work, but only because he owns a Droid. Personally, I feel that's the wrong reason. Heck, I'd be interested in checking out the new webOS tablet even though my workplace's vested interest is in the iOS platform. (though, yes, I'm a bit of a mobile device collector :P)
So it took a while but I logged some data using the Battery Monitor Widget.
Basically, the phone sits in 4mA to 8mA idle for an hour or so, and then jumps to 15 to 30mA for about 3 hours.
Then returns to 4-8mA for about 3 hours.
Periodically, this cycling occurs over 1 hour instead of 3, but more often 3.
By the way, I already signed out of Google Latitude as suggested by:
http://www.google.com/support/forum/p/Google%20Mobile/thread?tid=6bcdbe3c9425039c&hl=en
Here's the list of apps installed:
Advanced Task Killer Free
Angry Birds
Awesome Drop
Battery Monitor Widget
Google Chrome to Phone
ConnectBot
Google Goggles
Market
There isn't much choice I have in terms of what to "uninstall and find better behaved alternatives".
And, the battery usage info under phone settings is pretty useless. It claims most of my battery went to Google Services and Music. I was going to try to download Spare Parts from the market, but it felt questionable to get it from the market. I'd probably rather download from source and compile it myself later.
The way I see it isn't that Motorola, Samsung, and HTC arn't bad at Android software, it's just that the stock Android software is bad. I haven't owned a Nexus One, but I did play with a friend's when it first came out, and "slow as balls" describes that perfectly as well. It's not very reassuring to me that even using Google-supported devices, there's quirks that just arn't acceptable.
From what I can see, there's something polling the net as the phone's idle, keeping the radio on. So turning off all the radios causes that app to not drain as much. The problem is, I'm using an almost stock Nexus S. I've got GMail and Google Voice configured. And I periodically use Google Maps. When I did this test, the only software installed (aside from the default ROM) was Angry Birds and Google's Chrome to Phone (not yet configured, so it's probably not doing anything). So probability says it's even a Google app that's running amok with my cell radio.
Your numbers sound pretty darn good, but I'm not sure how to get any closer to those kinds of numbers without turning it into an ipod touch equivalent. I'll be giving Advanced Task Killer a go since a friend recommended it to me because it helped her.
Strange, I've found that the Samsung Galaxy S units (Friend has a Captivate) seem smoother in terms of UI responsiveness than the HTC Evos I've played with. Also the Captivate and Nexus S were definitely smoother than the Motorola Atrix I played with at CES.
My problem actually hasn't been the AMOLED display, it's the OS' incessant need to use the radio when it's in my pocket. (But yeah, the display does eat batteries too)
If I leave the phone on a desk idle without touching it (display off, bluetooth off, wifi off, cell on) for 8-9 hours, I got 20% of my battery remaining.
If I leave the phone mostly idle (did play mp3s for my car for 3 hours) but all the radios off, I got 90%+ remaining.
Friends with Moto Droid 1s and other Nexus S units I've talked to are unsurprised, so I could only conclude that this is considered normal. (while I didn't get mine free from google, most of the people I know with Nexus S units got them as their employee holiday gifts)
Awesomeness, indeed. I seem to be caught in the awesomeness of failure that is Android.
Sent from my Macbook Pro cuz I have one less reason to post from my Nexus S... aside from that its battery is dead again.
Well.... KDDI uses CDMA2k and all their handsets are based off brew.
Given that they're #5 in the world according to http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats
Then I'm guessing BREW's still trumping Android by a long shot since it's basically part of the dev kit for each CDMA2k-based handset/modem.
So it has a Serial ATA port... can this act as a SATA device instead of a SATA host?
You're using the Android battery logger thing on your G2?
If my Nexus S counts for a point of reference, the percentage values it gives are total crap.
It claims my screen is the thing that takes 68% of my battery power when my phone's screen has been on for about 10 minutes out of 8 hours and my battery's down to 20% from 100%.
You know, I have a feeling it's that Honeycomb itself won't require dual-core.
But that Google will require dual-core in order to be allowed to ship with Android Market and the "with Google" branding.
While I totally admit that setting up an iPhone is more involved because of iTunes, I have to say that as an owner of an original iPhone 2G, a Nexus S, and a Motorola Q (WinMo6.5), superficially, they're all the same.
When it comes to the little details, like polish or number of annoying things, my experience is that Android phones lose by a wide margin. (well, at least my Android phone sucks)
Want some examples?
Camera App/Gallery: Atrocious.
1) Well, actually, when I first launched it, it looked pretty cool with the animated flow thing showing me the few Picasa albums I have up. That's about all that's good.
2) Either the camera is totally awful, or there is a limit to how much detail it'll let you zoom to see.
3) When you delete the last picture, a blurred leftover version of the last picture is left onscreen, and half the UI thinks there's still a picture. The rest of the UI is interactive, but accomplishes nothing. It's like everything's just trashed. Menus don't even appear sometimes when you hit the menu button. Back doesn't seem to work right either.
4) Multi-touch interaction : pinch to zoom. It's awful, it anchors using some arbitrary point that I can't figure out. The result is that the zoom will shift what you can see away from what you wanted to zoom. At least they did it right in Maps.
Capacitive touch-sensitive buttons:
Capacitive buttons suck in general. They sucked on the LG Chocolate years ago. And they suck now. They activate on the slightest brush.
They're also not tied to the rest of the UI from a usability standpoint. If you swipe using a finger down the screen and just past the boundary of the screen in your followthrough, you hit a button AND it activates. This is frustrating.
Buttons on BOTH sides of the device:
It bugged me a little on the Motorola Q when I first got it. But since the buttons are pretty stiff, it wasn't that bad. The Nexus S pushes that problem to a whole new level because the sleep switch is on the side now because there's no other physical buttons on the front.
Put side buttons on one side, not both. Because if you put it on both, without looking at your phone every single time, you're bound to press both sides at the same time because you need something to push against. This is hella annoying especially since it's the wake button across from the volume-up button. So yes, without contorting my hand, my volume goes up or down every time I turn on the phone.
Music playback app:
For some reason if I wake from sleep when not playing, the playback shuttle sometimes jumps to a new location. It's kinda annoying.
Actually, I have a funny feeling it could possibly be due to the way I have to hold the phone to unlock with one hand (using the thumb) and avoid the side buttons. The retracting of my thumb might be close enough to register as a press on the playback shuttle. I'll investigate more another time.
Location Services: Anonymous always-on statistics gathering? Really? wtf?
(for comparison: the iPhone uses Skyhook, which also gathers base station statistics in order to do wifi-location when location has been requested and the presses an allow button. But Android will gather even when you're not using location services. It just sits there and spys.)
Yeah, and on my Nexus S, I found out that the battery usage logger built into the OS isn't even correct.
With the cell and wifi radios on and the screen off, letting the phone sit by itself. It dies in a day. The radios barely show up on the logger.
With all radios off, the phone is 50% dead after 3 days... and I'm even using it to periodically play a bunch of MP3s.
The VZW iPhone is looking mighty good right now.
That suggests that the bottleneck isn't the GPU or CPU most of the time, it is the speed of flash memory and by extension the amount of available RAM (since more RAM = more caching and less flushing.)
Unfortunately, that doesn't really make any sense since the Galaxy S series has similar(probably even same) flash to the iPad and Samsung Windows Phone 7 units, but at least the iPad doesn't suffer from the same lag.
(I have an iPad and a Nexus S.)
A variant of that idea I rather liked. I had a professor who liked to give 'tests of 2'... i.e. every answer on the test was '2'.... but better show your work.
Haha, at Cal, every homework for my Signals and Systems course involved at least half the answers being 0. How you got the zero mattered more than the answer.
What you fail to understand - and searching on Apple iPhone exploits shows - is that the pre-screening Apple gives has *no bearing on the security of the phone*.
So how does a scan for what APIs your app calls not have any bearing on security?
Nor are the immune to the description you give of the G1's - ask anyone with any hardware before the 3G where all their shiny new updates are.
If you read the point I was making, it wasn't that the G1 doesn't have updates. It's that Google can only push updates directly to end users of the G1, N1, and MyTouch dev phones. Google cannot push updates directly to users of other handsets like the Droid, the Epic, the Evo, and all other handsets/tablets/etc.
But yeah, the fact that Google is no longer supporting the G1 is true too.
Indeed, the original iPhone is in the same boat as the G1. But unlike the original iPhone, the following phones haven't been out for 3 years yet and still don't have 2.2 either:
the G1,
the Droid Eris,
the Motorola Backflip,
the Motorola Devour,
Samsung Behold II,
Samsung Moment,
Motorola Cliq,
and the Sony Experia X10.
(Has the 2.2 rollout for the Samsung Epic 4G and Captivate hit the US yet?)
Sure, you can flash an unofficial rom just like you can patch a jailbroken iPhone 2G. But the common user isn't going to understand how to do either.
I do not find apples "sandboxing" (which they aren't doing at all - they are simply saying you can only buy software at your local Best Buy which is *not* sandboxing - they are a walled garden, not a sandbox) to be useful from a security point of view because it gives me *nothing* that enhances that. Google really doesn't either - while the OS certainly does real sandboxing (which apple doesn't at all) installing applications generally requires you to give blanket permission that pretty much break this as a security feature too.
As for sandboxing, I have no idea what you mean by "walled garden, not a sandbox." But what I do know is that the iPhone indeed has a sandbox.
If you write an app to do something not allowed, say, open a serial port, then compile and load an app using the SDK. It'll exit as soon as open is called because the kernel killed it. Yeah. I tried it pretty early on.
This isn't some simple, "ooh, you can't install it, so it's protected" naivety. It's that processes loaded from the app store are killed or denied access by the kernel if they try to go out of their sandbox.
See here for profile info: http://iphonedevwiki.net/index.php/Seatbelt
Jailbroken phones and apps obviously bypass this in order to do their customizations. But for any app from the app store, they're sandboxed.
However, when nobody has written the tools to lock the card for so long, who wrote the tools to then unlock them?
The QA team responsible for the card.
1) This IS a conventional method as designed by the SD Association. (It's the S in SD)
2) They label this slot as a manufacturer intended slot. It's not intended to be swapped, just like those 8GBs of internal memory on your Droid Incredible?
3) It's part of a JBOD with the internal memory, so it's contents arn't complete. Taking this card out is like taking a drive from your RAID0 in your computer.
4) Locking it to a device helps prevent accidental erasure by other devices like your PC since it's useless to the PC because it's still a fraction of a JBOD.
5) Locking it to a device (if it prevents read by other devices) also means that you can't take somebody else's card from their phone and dump private data off of it.
6) As other people mentioned, this means that you can upgrade the phone's primary storage unlike all the other phones who have theirs soldered on. This is both a win for MS (simplifies the production line, because it's one phone), a win for the user (can use whatever's the cheapest per meg), and a win for the environment (phones are upgradable)
7) Not all phones have this, it's a feature that the manufacturer can choose to implement.
What better solution? (Encryption costs more in power. Would you rather they be soldered? )
As such I find no security difference and a great deal of usability difference.
You exhibit the same problem as those who blindly support the idea that "security by obscurity is no security at all," in that you appear to dismiss the fact that security isn't made of one thing or another, but the sum of all the efforts to make something secure.
The iTunes App Store does not itself make the iPhone secure. It only attempts to improve the quality and conformity of applications provided to the user.
The lockdown/sandboxing of the iOS device itself makes it harder to install apps that have not been vetted by Apple somehow, but it doesn't guarantee security. It only makes it significantly more difficult to obtain user data.
The iTunes/iOS update system, can post a patch to all devices relatively quickly and with relative certainty that the hole exploited has been plugged. It doesn't guarantee security.
All of these don't guarantee security. They're all defeatable. The first two are obviously defeated by jailbreaks and that PDF/freetype vulerability.
The 3rd one is defeated if the user decides not to install firmware updates.
But together, they make it harder for a user to get exploited. If you try to attack from the official App Store, even if the reviewer was a moron, the sandbox makes most user private data impossible to access. Even if you managed some way to hack through kernel-level sandboxing, whatever you do will get plugged on discovery, and the fix deployed via a system update. (and not only that, the base OS will get reset to an unhacked state, which is probably why the PDF fix was deployed in a full system firmware update of some couple hundred megs, instead of a 100kB patch.)
On the other hand, you have Android.
You can install whatever you want. You can access most things on the phone, usually just by letting the user know in vague terms in the install. (or in this article's case, without really knowing at all, provided you have an HTC phone with Flash Lite.)
Google only pulls out the banhammer on the marketplace when something's reported to be no good.
Google can apply a fix and deploy it to the G1s, some myTouch dev units, and the N1s. But everybody else will wait until their manufacturer pushes the fix. (and Google's own stats say that only 1/3rd of Android users are on 2.2)
Apparently khchung finds the sandboxing in iOS to be a blessing. Apparently you and bigstrat2003 find the flexibility in Android to be more valuable.
Either choice is fine with me. (heck, when I first got into the iphone jailbreaking scene, I not only audited the source code for the early jailbreak utilities, but then did all the procedures manually, to make absolutely sure nothing got sneaked in.)
But make no mistake, the security aspects of both platforms are most definitely different.
Technology and frequency differences? You've got to be shitting me. They don't work because the cell operators are greedy assholes.
What? Really?
Huh, so that's why my 10Base-T hub can't do Gigabit, yeah?
Idiot.
Uh, no.
Absolutely wrong. Softbank's network will allow for an unlocked device with an unrecognized IMEI with just a SIM card change.
How do I know? One of my friends has been living in Japan and had been using a WinMo phone from ATT and a iPhone from Taiwan on Softbank for the last 3 years.
When visiting, I was also given the option of using a prepaid Softbank SIM on a jailbroken/unlocked iPhone 3G from ATT.
It works.
What you should be complaining about it Softbank not selling prepaid SIMs to foreigners.
Or... install a Sandforce SSD into every common consumer's laptop, marked up for labor, and call it an upgrade.
It would feel like you just swapped out a 486 for a Quad-Opteron.
I'd think rust platters recycle easier too than entire laptops.
Actually, it's not even Apple. It's some random shop trying to cater to the DIY Apple crowd quick making a quick buck, while working through the idea that if they can afford an Apple, they can afford to get screwed over $50 for a screwdriver.
While I think that seems kind of overkill, Filemaker has a product called Bento that seems somehow more fitting for something like this (assuming you use a Mac).