iPhone Mythbusting! Let's separate the facts from the fiction.
This is a discussion on iPhone Mythbusting! Let's separate the facts from the fiction. within the iPhone General Discussion forums, part of the iPhone Forum category; Welcome to iPhone Mythbusting!
This thread's purpose is to find out how things really work with the iPhone. I will do my very best to ...
iPhone Mythbusting! Let's separate the facts from the fiction.
Welcome to iPhone Mythbusting!
This thread's purpose is to find out how things really work with the iPhone. I will do my very best to remove the fiction from the facts. And to do it in such a way that even you will be able to reproduce what we have discovered.
First lets lay out some ground rules. I will:
Only test NON jailbroken features.
Only be testing with an iPhone 4S and iOS 5.1.1. Well until iOS 6 and the next iPhone comes out
Only use FACTS that are reproducible.
Always state when I am voicing an opinion or theory.
Do my very best to cover every angle of a situation. But just remember, I am only human.
Those are the rules I will follow. Now for the rules I need you as the audience to follow.
If you post a myth you want looked at, make sure you give every detail possible.
If you have evidence that disputes something, make sure you show all your work. I did
Be respectful at all times.
I phyically do not have the time to answer every general question or app question out there. This thread is about covering myths and misconceptions. So remember to keep any requests you have in that vein.
And finally a disclaimer. I reserve the right to delete a post that breaks any of the rules laid out here. But when I do, I will explain why I did it. Transparency is key to proper research and facts. And that is what we are all here for.
Technically the first myth I want to cover isn't a myth. It is more of a misconception that has become mythical like. And in the process of researching this I have discovered a few things that even dropped my jaw to the floor.
Here are the tools used for the project.
My iPhone 4S running iOS 5.1.1. Cellular provider Verizon and delivered to me on Oct 14, 2011.
The standard Apple 5 Watt charger that came with the iPhone 4S.
The standard Apple charging cable that came with the iPhone 4S.
The P3 International P4400 Kill A Watt Electricity Usage Monitor.
My iPad 3 (not shown) that was used to document everything.
Droid X as a stop watch. You of course can use a watch for this.
Kinects. I had to get all three displays level and facing the right way
Lets go over a few quick items to set a baseline. The Kill A Watt is not a certified or calibrated piece of hardware. So it will not show the "exact" wattage being drawn. But it will be "close enough" to show how the charging stages progresses. Also Apple's documents state that the iPhone charger is 5 watts. The reality is it can actually supply more than 5 watts of power. You will see that throughout the video.
But first here are some stills to help set a baseline. And it directly shows that the Apple iPhone charger can provide more than 5 Watts. Please excuse the yellow color and no Kinect stands. But this was done earlier in the week to help get this thread started.
The first picture will set the base line. And give us some offsets to work with.
As I stipulated early on the Kill-A-Watt is not fully calibrated. But it is close enough to the 5 watts Apple specifies to be useable in this demonstration. Now for the second picture.
Notice it at the unlock screen it jumps .6 watts. This extra load is from first waking up the device and the screen brightness kicking in. The third picture shows...
What happens when the iPhone settles in to the auto brightness level I have set. And last we can show what happens when we have an app running
Even though the brightness hasn't changed, the CPU and GPU are now showing there are being used constantly.
So with that in mind, we can assume during the video that the wattage is always .2 watts off natural due to not being properly calibrated and an additional .4 to .6 watts is being shown due to the phone simply on and possibly doing work so we can see the battery percentage change over the time lapse.
Now for the video!
There goes 4 minutes and 24 seconds of you life that you will never get back! Bwahahahaha!
So lets start of with what I personally thought was going on prior to actually doing this video. I thought that Stage 1 charging, constant wattage, happened from 0 to 85%. Stage 2 charging, decreasing wattage, happened from 85 to 96% and then an extra Stage 3 from 96 to 100% that was a very low constant wattage. Now this was derived from a purely observational stand point even thought the Lithium-Ion specification only documents a Stage 1 and Stage 2 charging system.
Well found out I was off on my Stage 1 observation and by a lot. Stage 1 ends approximately between 71 to 72%. Stage 2 then kicks in and we see a very steady decline in wattage all the way thru to 100%. So there is no "Apple specific" Stage 3 as I thought. Kind of a let down actually. I was hoping that Apple was "different"
I was a little shocked to see Stage 2 kicking in so early on the iPhone. But the good news is, it allows the Lithium-Ion battery to start settling down to help extend the life of the battery. Which of course is both the design and desire.
The only bad news is, the Kill-A-Watt doesn't handle wattage readings below .9 watts. Which is a shame because I tried at the very end of the video to show the very last wattage used during the finally part of Stage 2 before shut off occurs.
Now if you paid really close attention at the end of the video you saw I turned the screen back on when the iPhone went from 100% charging to 100% not charging. The wattage was 1.1 when not charging. If we take out the .2 for not being calibrated, that leaves us with .9 being used while playing with the phone on the charger. What I found interesting was during the setup shots above we only have an average extra load of .5 watts.
I have a theory that should account for this .4 difference. I think during the entire video I was pulling .9 extra watts and robbing the charging system of .4 watts. And since we all knew that charging with the screen on takes longer, now we have conclusive proof of why.
So while there was really no Myth to how an iPhone charges, there were so many theories on how it did it over time that it took on a mythical quality. Now we have factual observable proof to work with. And that is a good thing in my opinion.
First lets start with the cliffnote's version of the answer. Drum roll please.
The answer is: Maybe!
Several factors come into play for this Myth.
1) Size of the App.
2) Amount of memory already in use.
3) The definition of "freeing memory".
Yes, you read that correctly. The definition of "freeing memory" is not very cut and dry. BTW, this is why there has been so much confusion over the years when people discuss this subject.
But first lets talk about how to kill an application on the iPhone.
Double click the home button.
Select the app and long press it.
Once it starts to wiggle release.
Now click Red and White symbol in the corner.
You just killed the app.
So lets start with a freshly hard booted* iPhone in airplane mode.
*See the myth "What survives a reboot" for the definition and procedure.
The image above is a lot to take in for the first time. It shows the five types of memory that iOS tracks. Lets break each one of them down.
1) Wired - This is the most important memory. Anything stored with this designator can not be touched by the operating system. This memory contains the mission critical programs and data needed for the OS to survive.
2) Active - This is the second most important memory. This is where programs and data are being actively run but can be released from memory if the OS determines it is needed to keep the OS running.
3) Inactive - This is memory that was either Wired or Active but no longer in use. This memory can be freed at will by the OS with no repercussions to performance. BUT if the user decides to load an Application and it is still loaded in the Inactive memory segment, it will move it back to active instead of reloading from the flash drive. This is done to conserve battery.
4) Other - This is purely program data that is non critical. The OS decides if Inactive memory or Other memory is freed first before loading more programs or data.
5) Free - This is memory that hasn't been allocated to anything. About the only time you will see this number this large is after a reboot
One last note about the image above. It was taken approximately two minutes after the phone was hard reset. So we will consider that our starting point.
So lets test what happens when Tiger 2012 is loaded into memory.
And presto! All the numbers have changed. Since I didn't write iOS or this App I will have to do some theorizing for part of my explanation.
Wired - Odds are that memory jump is part of the graphics library API loading up.
Active - This is where the core of the application is loaded.
Inactive - I launched the App and then went to the first hole. Odds are the original memory for the menu system is stored here before it loaded the first hole.
Other - This is the bulk of where the 3D data and textures (graphics) are stored.
Free - We used up 142.5 Megabytes of memory to load Tiger 2012. BTW, the disk size that is used by this Application is 402 MB. So as you can see only part of the application was loaded.
So what happens when we kill the application? Drum roll please...
There you go. Conclusive proof that when you kill an application it does free up memory. But notice something? We didn't get it all back. The reason for that is simple. iOS kept core parts of Tiger 2012 in memory just in case the user relaunches the application. Which, as I mentioned earlier, helps with battery life.
BTW that second to the last sentence is the KEY to showing why some people insist that killing an app "doesn't free memory". And remember, I stated at the very beginning that the answer is "Maybe". Now to explain that answer which will clear up this myth and turn it all into facts.
Every application is basically a different size. Lets take the System Status application, that we used for this test, as an example. It is only 1.6 MB in size. So when it loads into memory it takes up a very small foot print. And when we force kill it, there is nothing to free up. It simply moves from Active to Inactive memory. This is what happens with every small application of this nature. And considering that for the longest time most apps could fit in 50 MB of space or less, that is why people insist nothing happens when you kill an app. Their observations are 100% correct because "Free Memory" wasn't affected. It wasn't until very large apps with large amounts of data could show that killing an app actually can and does free up some memory.
Next time someone insists that killing an app doesn't do anything for iOS, you can now point them to this thread. Because we just proved it does do something but what it does all depends on the application and how big it is.
Here are the tools used for the project.
My iPhone 4S running iOS 5.1.1.
So what does survive a reboot? A lot more than you think actually.
First lets look at what the perception is. I turned off the phone and that should clear all the memory. For PCs, that is almost spot on. But the iPhone is just a tad different.
Things that survive a reboot.
Your task list.
That last screen you were on in certain apps like
About now you are probably asking "How is that possible"? The answer is due to the nature of the beast. iOS is a Unix based operating system. Unix based OSes are file based. To simplify a lot of material. Everything you do in Unix has an associated file handle on disk.
So when iOS reboots it finds those files still on disk and reads them as preferences.
Now, lets discuss the difference between a soft reboot and hard reboot.
Soft reboot is defined as holding down the standby button for 3 seconds and then sliding the "Slide to Power Off"
Hard Reboot is defined as holding down both the stand by button and home button until the white Apple logo appears.
The difference between the two is dramatic. Soft reboots tries to read every file on disk to get back to a known starting point. Hard reboot only reads back files that would be considered strong user or preferences.
So a hard reboot will clear certain errors that a soft reboot can't.
Here are the tools used for the project.
Some basic research.
So do we? The short answer is a resounding no. But..... Yeah, there is always a but.
First and foremost you aren't doing it to help the battery. In fact this whole deep cycle discharge doesn't do a thing for the battery except use up one of its 400 full cycle charges.
But the reason it is helpful is so that iOS can get a reading of what fully charged is versus fully discharged. Once it "memorizes" those two conditions it then builds a profile of its discharge rate which in turn is used to predict its current percentage of remaining charge.
So why does iOS use a prediction profile instead of a direct read of the battery? Easy. To get a reading requires the battery to be put under "a load". That load cause the battery to discharge. Do it every few seconds and you will help drain the battery faster for absolutely no gain. So instead iOS does periodic readings, based on an algorithm, to confirm what the profile prediction is vs the actual charge. And this process is what helps keep the profile up to date over time.
This question comes up a lot and everyone seems to have a slightly different answer. So lets start with some good questions to help answer the original question properly.
Can you be prosecuted for jailbreaking your iPhone? No.
Why can't you be prosecuted? The Library of Congress, in the summer of 2010, added an exemption to the DMCA to exclude jailbreaking from being a prosecutable offense. This was done in response to Apple trying to sue individuals that created jailbreaks. A copy of the request for exemption can be found here http://www.wired.com/images_blogs/th...dmcaexemps.pdf
Then why do some people say it is illegal? Just because you can't be prosecuted for jailbreaking doesn't mean there aren't consequences for the act of jailbreaking your iPhone. This is where Verizon Wireless has an air tight clause, that all VZW customers sign off on, that they have not invoked as of the posting of this article, that allows them to terminate the service of anyone that has jailbroken their phone.
In the VZW ToS they have a section titled: "What Are Verizon Wireless' Rights to Limit or End Service or End this Agreement"? Under section 2 subsection d) they have "modify your device from its manufacturer's specifications". That folks is exactly what jailbreaking does. And Apple will gladly back Verizon Wireless in court if anyone should ever try to go that far.
So what are the consequences that Verizon Wireless, and probably all other cellular providers, can invoke? They can terminate your service. And there is nothing you can do about it. Now for the really interesting part that most people don't realize. VZW customers are still responsible for the remainder of their contract. The only good news, you are only responsible for the balance of the contract or the ETF (Early Termination Fee) which ever is lower. But that could still put you out several hundred dollars.
As I stated earlier, and this bears repeating, VZW has not invoked this yet. The only question that no one can answer is, when will they?
So can they? Yes. Do they try? Not really. Have they caught anyone? Yes.
Can already see the questions forming. How can they catch someone if they don't really try? LOL. Easy. The user used a tethering program that mimicked the native hotspot feature of the iPhone. That would set off all kinds of red flags if you didn't have a hotspot tethering plan. Sometimes they catch people by their change in data usage behavior. IE the go from 1 gig to 50 gigs of data usage. But that is less likely to stand up in court.
So why don't they catch everyone? Because of the amount of money that is involved to do so. Will they ever spend that money? Probably not. Mainly because unlimited data plans are going the way of the Dodo.
So how do they catch someone if they do spend the money? Easy. Packet sniffing. But it takes a LOT of computer power to handle every packet and that isn't cheap. So lets go over how it is done should they ever try.
Every time you do something on the internet you generate a packet of data. This packet basically contains the following:
Your IP address. The responding computer has to know who to send it back to.
The IP address you want the packet to go to.
The data you want the address to receive.
So lets look at some technical parts of what is going on. Lets say you have a laptop and your iPhone is the hotspot for it. Your laptop gets an IP address from the iPhone of 192.168.0.2 (yours can be different). Your iPhone has an internal IP address of say 10.253.187.108 (yours will be different). Then your iPhone has an external address of 18.104.22.168 (yours will be different). That is a lot of IP addresses involved. So how does it all work? Well lets lay out the simple version.
NAT (Network Address Translation) is the process of taking one IP and allowing it to be used by as many internal IPs as the router can handle. So your iPhone is acting as a router and the cell tower is acting as another. So when your laptop sends a packet of data out the following basic steps occurs:
iPhone gets the packet.
iPhone strips the laptop's address (192.168.0.2) off the packet and memorizes it.
iPhone rebuilds the packet with its address (10.253.187.108).
iPhone sends the packet to the cellular tower.
Cellular tower sends the packet to the cellular providers router.
Cellular router strips the iPhone's address (10.253.187.108) off the packet and memorizes it.
Cellular router rebuilds the packet with the iPhone's external IP (22.214.171.124).
Cellular router sends the packet out to the internet.
When the answer packet finally comes back, the process is reversed and the addresses that were memorized are reapplied to the packet so it can finds its way back to the laptop.
About now everyone is probably saying "AHA!!!" the packet doesn't even look like it came from my laptop. It doesn't have anything to identify it as coming from it. And you would be 100% correct from a packet wrapper standpoint. But it is the data inside the packet that can give you away.
By looking at the data in the packet you can learn a lot about what is going on. So lets create a simple scenario to work with. Your laptop was last used 7 days ago. Been off the whole time. You put the iPhone in tether mode, fire up the laptop which is running Windows and connect to the internet. One of the first thing Windows does when it sees a live internet connection is check to see if a "Time sync" is scheduled. It's been 7 days and it needs one. So your computer goes thru the following basic steps:
Looks at the internet time server you have in your registry.
It sends a DNS (Domain Name Service) request to convert that entry (probably time.windows.com) to an IP address.
It uses that address to send a packet requesting the current time.
Anybody see the issue? Do you think your iPhone is ever going to make that request naturally? No?
They just caught you.
Of course the natural thought is "I will just turn that feature off". There are hundreds, if not thousands, of things like that with Windows, Linux, OSX and every other OS you can think of. And don't even mention hand held or console gaming units, they are even easier to spot. So lets skip all of that cat and mouse games and get straight to the end game. The infamous final stand that every user would attempt.
Now the really knowledgeable internet gurus already know this little secret. There is technically a way to "mask" this. Encrypt the data in the packet. But you have to have a service that will receive the data, decrypt it and finally pass it along. Some people call these encrypted proxies, or other names, and you can also use VPNs (Virtual Private Networks). Basically it doesn't matter how much hardware you throw at this new twist, there is no way to decrypt the packets fast enough. If at all.
Now a break from the serious to the ironic. Notice I just mentioned VPNs? Guess what all major businesses use for remote location data transfers? That's right, VPNs. Now guess who wants iPhones to be used in all those businesses? Apple. So much so that VPN is already built in to iOS. So Apple already gave users the tools to keep a cellular provider from snooping on what they are doing. Ironic isn't it.
Back to the serious. The gurus at the cellular providers know all of this as well. They played out the same exact scenario with the same exact outcome. And that is why they probably won't spend a dime on the problem. Switching everyone off of unlimited data plans is the only solution the end user has left them with. Plus they are going to make a lot more money because of it. So for them it is a true win/win.
So lets review. They can catch you, if you don't use point to point encryption, but it isn't worth the money to really try because they are going to start charging you by the gigabyte soon enough.
Kind of funny in my opinion. A very small group of end users, 5% based on numbers published by the cellular providers, just cost 95% of us our unlimited data plans.