News

Apple Releases Web Tool for Deactivating iMessage
  • Comments are Closed

Apple Releases Web Tool for Deactivating iMessage

Not long ago the internet was abuzz with articles and posts about Apple’s issues with iMessage. Users were concerned about not getting texts from iPhone users if they switched to another device. The issue stemmed from how iMessage works on the iPhone. When a user enables iMessage on their iPhone the phone sends a silent text message to either an SMS short code associated with the carrier the phone is being used on, or to one of several phone numbers in the United Kingdom if the phone is on a network that does not officially support the iPhone and is using the ‘unknown’ carrier bundle. This phone number responds with an activation message that uses a protocol called Application Port Addressing to direct the message to a specific process on the phone. If this completes successfully the phone number is registered with Apple’s servers as a number linked to an iPhone and all iOS and OS X devices are able to send iMessages to that phone number. In addition, all iMessages directed at that phone number will be pushed to all devices associated with the Apple ID on the iPhone.

This is where the issue would arise for users that switch from an iPhone to a smartphone running another operating system. When switching to another device, if the user does not go to the messages section of the iOS settings application and deactivate iMessage other iPhones will be unaware that the phone number is no longer being used on an iPhone and that it should be messaged using SMS. This posed a serious issue for users who lose their iPhone or have it damaged in such a way that they are unable to use it to disable iMessage. To make matters worse, if the user has iMessage enabled on other devices like an iPad or a Mac they must also deactivate it on those devices as even after deactivating on their iPhone the phone number will still be listed as an iMessage receiving address on those devices. This causes messages that should be sent by SMS to the new device to be sent as iMessages which are never received by the new phone.

Although this issue had existed since iMessage was released with iOS 5, it only became widely publicized during the last year. Apple has finally released a tool that allows users who cannot access their iPhone to deactivate the iMessage registration of their phone number. By inputting your phone number into the field on the website, Apple will send you an SMS message with a confirmation code. This code can then be entered into the website which will deactivate the iMessage registration for that phone number. It’s good to see that there is finally a solution for users suffering issues receiving text messages after switching from the iPhone, but it certainly did take a while. 

Source: Apple via The Verge

Quick Note: Android Camera2 and Support For External ISPs
  • Comments are Closed

Quick Note: Android Camera2 and Support For External ISPs

While we’ve written about Android’s Camera2 API before, there was one notable aspect of the discussion that was missing. The missing piece was a discussion of the physical link needed to enable all of the controls that were previously discussed. This isn’t necessarily complicated, but it does represent a potential pitfall for updates to current devices. In short, the current protocols for using an external ISP provide insufficient bandwidth to support the full feature set needed for the new camera API.

This means that some of the interesting features, such as per-frame controls are impossible to enable. As a result, many devices that we’ve evaluated before such as the Galaxy S4 Snapdragon, Motorola Moto X (2013), HTC One (M7), and One (M8) won’t support per-frame controls and similarly bandwidth-heavy features. The Galaxy Note 3, S5, S4 Exynos, Note 4, and all Nexus device should support the full set of features in camera2 as they seem to only use an on-die ISP.

To understand why this is, we must understand the protocol that is used for communication. Today, the de facto standard for interfacing between the AP (application processor), ISP, and camera is MIPI’s CSI protocol. By and large, CSI-1 and CSI-2 are the most common iterations of this protocol. While the transport protocol (D-PHY) that actually carries the images has immense amounts of bandwidth (up to 10 Gbps), the control protocol defined has almost no bandwidth in comparison. Instead, the control protocol relies on fast-mode i2c, which can only provide 400 kbit/s of bandwidth.

While this may be an issue now, it seems that in the future this won’t be an issue. According to Arrow Devices, the MIPI CSI-3 protocol merges control and transport protocols into a single M-PHY bus for up to 18.6 Gbps of bandwidth. It’s likely that the demand for 4K60 video and 20+ megapixel burst mode functionality will drive adoption of this newer protocol. However, even now the disclosure of such protocols is rare, so it’s hard to say whether we’ll see widespread adoption of CSI-3 any time soon.

Quick Note: Android Camera2 and Support For External ISPs
  • Comments are Closed

Quick Note: Android Camera2 and Support For External ISPs

While we’ve written about Android’s Camera2 API before, there was one notable aspect of the discussion that was missing. The missing piece was a discussion of the physical link needed to enable all of the controls that were previously discussed. This isn’t necessarily complicated, but it does represent a potential pitfall for updates to current devices. In short, the current protocols for using an external ISP provide insufficient bandwidth to support the full feature set needed for the new camera API.

This means that some of the interesting features, such as per-frame controls are impossible to enable. As a result, many devices that we’ve evaluated before such as the Galaxy S4 Snapdragon, Motorola Moto X (2013), HTC One (M7), and One (M8) won’t support per-frame controls and similarly bandwidth-heavy features. The Galaxy Note 3, S5, S4 Exynos, Note 4, and all Nexus device should support the full set of features in camera2 as they seem to only use an on-die ISP.

To understand why this is, we must understand the protocol that is used for communication. Today, the de facto standard for interfacing between the AP (application processor), ISP, and camera is MIPI’s CSI protocol. By and large, CSI-1 and CSI-2 are the most common iterations of this protocol. While the transport protocol (D-PHY) that actually carries the images has immense amounts of bandwidth (up to 10 Gbps), the control protocol defined has almost no bandwidth in comparison. Instead, the control protocol relies on fast-mode i2c, which can only provide 400 kbit/s of bandwidth.

While this may be an issue now, it seems that in the future this won’t be an issue. According to Arrow Devices, the MIPI CSI-3 protocol merges control and transport protocols into a single M-PHY bus for up to 18.6 Gbps of bandwidth. It’s likely that the demand for 4K60 video and 20+ megapixel burst mode functionality will drive adoption of this newer protocol. However, even now the disclosure of such protocols is rare, so it’s hard to say whether we’ll see widespread adoption of CSI-3 any time soon.

  • Comments are Closed

The Apple iPad Air 2 Review

As we approach the holidays, Apple has launched a new iPad as expected. As one might expect from the name, the iPad Air 2 is more of an evolution of the original iPad Air than a clean-sheet design. This doesn’t mean that there’s little to …

  • Comments are Closed

The Apple iPad Air 2 Review

As we approach the holidays, Apple has launched a new iPad as expected. As one might expect from the name, the iPad Air 2 is more of an evolution of the original iPad Air than a clean-sheet design. This doesn’t mean that there’s little to …