The accessory may not be supported prompt after iOS update

If you’ve recently updated your iOS device and started receiving a prompt telling you “The accessory may not be supported” when plugging in to a dock or clock radio – I feel your pain. I’m not sure why this seems to always coincide with iOS updates, but my theory is that the device manufacturers look at the MFI specification as if it’s the bare minimum they’re required to do. Rather than test that they conform to the entire spec, they instead test that the portion of the spec their product requires barely works.

I came to this theory after finding a really stupid trick that causes the Sony ICF-CS15iP that I just bought my girlfriend last year to work. I know – this product was already a year or two old in 2015, but I really didn’t trust “iHome” devices at the time. I remember when iHome made devices that sounded like garbage, felt cheap, and looked like they were constantly trying to ride Apple’s “iDevice” coattails. I definitely feel like I’ve made a mistake with this purchase after hearing and seeing the iHome clock/charging station I bought my girlfriend’s parents the same year – especially after seeing their device perform fine through iOS updates.

The reason I feel like this is a stupid trick and a mistake on Sony’s part – the prompt never shows up if the charging dock is tilted forward. I know this sounds insanely dumb, but the lightning plug dock is on a tilt swivel, and if you keep the dock tilted forward it seems like the connectors on the dock plug make a more solid connection with the contacts on the phone.

As seen in the photograph – the easiest way for me to accomplish this immediately was to shove two thin note pads behind the tiltable dock. As a more permanent solution I’ll be mounting some foam or plastic back there so that the large, obtrusive note pads aren’t necessary.

I did this all after cleaning the dock plug with 91% alcohol, as well as cleaning the lint out of both of our iPhones at home (powered off of course). Before you go to the Apple store with your iPhone or iPad that doesn’t charge when connected to a lightning cable – make sure to clean out the lint first, otherwise you may leave there feeling like an idiot.

So as far as I can tell, with various iOS updates Apple may push an update that has more strict requirements on lightning connections that device manufacturers may have been lax on implementing. While this solution won’t work for everyone, I hope it will help others troubleshoot their issues.

I have a repo that I’ve been keeping here which is a clone of a Microsoft script modified to work on modern Debian and Ubuntu systems. The problem is I just haven’t updated it in forever… I promise to update it this weekend!

android_wear_logo_new

Developers to Android Wear – Are We There Yet?

The short answer seems to be no, but maybe soon.

The long answer is quite a bit more involved.

Development

From a development aspect, starting an Android Wear project is straight forward and simple. In reality, creating a great Android Wear app is neither straight forward nor easy. I’ve been holding off on beginning any Android Wear projects that utilize features present in the Wear 2.0 Preview, so right now a developer usually ends up with a project that contains at least two modules: a handset app module and a wear app module. By default, you’re not presented with any shared code layer since the mobile app “depends” on the wearable, you can either move all shared objects to the wearable module (don’t do this), or you can create a new shared module that both the handset and the wear apps will depend on. This seems somewhat straightforward, but is yet another area developers are left on their own to figure out the quirks of the platform.

Deployment

Android Wear app deployment is hilariously convoluted. Currently, using the wearApp() gradle dependency the wearable app will only be packaged when the app is built using the release variant. What about a debug build? Don’t bother looking – Google’s documentation on this subject is sparse at best. Here’s what I ended up adding to my mobile app’s debug buildType:

gradle.taskGraph.whenReady { graph ->
    if (!graph.hasTask(assembleRelease)) {
        android.applicationVariants.all { v ->
            if (v.buildType.name == "debug") {
                v.preBuild.doFirst {
                    copy {
                        from("../wearable/build/outputs/apk") {
                            include "**/wearable-*.apk"
                            exclude "**/*-unaligned.apk"
                            rename "wearable-", "wearable_"
                            rename "-unsigned", "_unsigned"
                        }
                        into "./src/main/res/raw/"
                    }
                    println("Packaged Wearable APK in Mobile App")
                }
            }
        }
    }
}

But this isn’t all you need – you’ll also need to create a wearable_desc.xml file to tell your app what your wearable’s name under res/raw will be. BUT WAIT, THERE’S MORE! You’ll need this file to be different for release, because the release apk will be named android_wear_micro_apk.apk. Is this tiring you yet? We haven’t even touched the problems inherent when testing with a wear emulator and various versions of Google Play Services being outdated/out of sync, problems with the wear app properly syncing over to the wearable device, or the problems with synchronizing communications.

User Perception

Most Android users have no idea that a Samsung Gear S2 is any different than an Android Wear device, that it runs a different operating system (Tizen), or that it’s basically not compatible with anything you write for Android Wear. I’ve had requirements in the past that asked me to deliver an Android Wear application only to find out they had wrongly assumed Samsung’s Gear S2 devices would be supported. This fragmentation is bad for Google and for Samsung. Google gets wrongly accused of having no Wear apps (there are tons) when a user is only interacting with the Gear (Tizen) app store. For those in the know – they complain about Samsung selling them a wearable that’s not compatible with the much larger Android Wear ecosystem. Going forward this doesn’t seem like it will be as big of a deal as Android Wear looks to be the “Android” smartwatch platform with partners like Tag Heuer, Huawei, LG, Motorola, Fossil, and more, but for now this isn’t a stellar ecosystem for users to dive into without any guiding hand or clear answers.

Wear Are We Going?

Wear isn’t leaving us – as Google presented a brand new 2.0 redesign of Wear at this year’s I/O conference, it’s only getting better. The redesign is a huge improvement in terms of usability that goes toe-to-toe with Apple’s WatchOS 3.0, and I truly hope that Google only postponed the 2.0 release because it wanted to make the development story less of a headache. Developers need a better way to test on the emulator without worries of remembering all the little tricks they need to do in order to test and debug their apps. Developers need the emulators to update Google Play Services, if we want them to, just like a real device does. And finally, developers need users to somewhat understand and adopt the platform so their apps are seen and used. There’s nothing more satisfying than seeing someone using your app in public, and there’s nothing more heartbreaking than developing for a half-baked platform created by a multi-billion dollar company.

Microsoft’s Surface PC Event

With Microsoft’s new announcements, including the new Surface Studio PC – it seems like they’re finally trying to go after what remains of the PC market. Microsoft is finally at the table, trying to eat Apple’s lunch. With Apple’s “Hello Again” event tomorrow, it will be nice to see if Apple is going to take another year off, or if they’re finally ready to make some much needed updates and improvements to their Mac lineup.

Driver Problems with ALC1150, DSP, and Windows 10

Having trouble getting a driver installed with your fancy onboard sound card such as the Realtek ALC1150 115dB SNR HD Audio, or any of the new sound cards with onboard DSPs, DACs, and so on in Windows 10?

You may want to check your BIOS to see if there’s an option to the likes of “Audio DSP” and disable that. Once disabled, Windows should properly detect your ALC1150 and install the drivers automatically. It seems as though the drivers haven’t really been updated to support all of the features that the sound cards offer in Windows 10, and only basic Windows 10 support has been included. Hopefully in a few months these driver woes will disappear.

gigabyte motherboard

New Motherboard Restarts After Reboot: Enable Power Loading

After booting once, shutting down, and rebooting, my new home server was in trouble.

It just kept restarting.

It would power up for maybe 10 seconds, and shutdown. Power up again for another 5 seconds, and shut down again. All the meanwhile no PC speaker noises (I actually harvested an old speaker from a long unused machine to test) and no motherboard display error codes (the Gigabyte motherboard I have actually has a two character 8 segment display). I thought maybe it was a problem with one of the components, the power supply was bad, or possibly something wasn’t seated properly (RAM, CPU, etc.), but none of those issues ended up being the case.

Instead, it seems as though the new motherboard and processor use so little power during boot up that it causes the power supply to shut off.

Enter, a new setting in the BIOS: “Power Loading”.

Power Loading, as described by Gigabyte, “enables or disables a dummy load. When the power supply is at low load, a self-protection will activate causing it to shutdown or fail. If this occurs, please set to Enabled.”

Awesome. Having “Power Loading” enabled keeps enough load on the power supply that when the motherboard and processor are being super efficient during POST, the computer doesn’t shut down.

iPhone 6s

iPhone 6S $20/month at T-Mobile – Not so Simple

I just wanted to clear up some misconceptions about T-Mobile’s new $20/month plan for the iPhone 6s:

  1. Yes, you can get the upgraded storage specs – you simply put $100 or $200 down on the phone before you begin the $20 payments each month depending on if you want the 64gb or 128gb respectfully. Your card will not be charged until the device is shipped.
  2. Yes, you can stop paying monthly before your 18 months are up. Tired of your payments? Cancel your plan, pay the remaining months, and send back your phone or pay the pay-off amount and keep your phone. You won’t get the $7 monthly bill credit this way, so you’ll end up paying full retail price for your phone, but if you decide to leave T-Mobile before the 18 months are up you do have a way out. If you stay the full 18 months, you’ll end up saving yourself $125 on the cost of the device by joining their Jump on demand leasing program (so long as you pay the pay-off amount at the 18 month mark so that you leave the program and own the device).
  3. Don’t like the phone or service in the first month? Take it back for a full refund. Seriously. 30 days and you can return it to T-Mobile for a 100% refund including any down payment you’ve made or any service costs you’ve paid for.
  4. Go to a T-Mobile store if you want to sign up. You cannot sign up for this plan over the phone unfortunately.

I hope this clears some things up for anyone considering these new plans from T-Mobile. Thanks to the new LTE and 700mhz support, my girlfriend and I preordered these yesterday after about an hour in the T-Mobile store. Hopefully your T-Mobile store experience is speedier than mine.

The mail server “imap.gmail.com” is not responding problem on iOS with Mail.app

This was a new annoyance on my phone for personal (mostly spam) gmail accounts as of iOS 8.3. The issue became a lot more frequent as of iOS 8.4 and I believe I’ve found a fix to the problem.

This issue seems not to affect google apps accounts, at least in my experience, but has affected any “free” gmail accounts I had added to the system mail app.

To solve the problem:

  1. Remove all of your affected accounts from mail.
  2. Re-add the accounts, but do not select “Google” from this screen and instead select other.
      
  3. Choose add mail account.
  4. Enter your gmail information including the name that you want your recipients to see.
  5. On the following screen, add your information again. You’ll also need to add the SMTP and IMAP servers as well as your gmail address and password to additional fields on this screen 
  6. Choose if you want to sync notes on the next screen
  7. That’s it!

You should be all set with your gmail account added to mail again bypassing the failing Google oauth authentication method. You may also need to enable IMAP on gmail if you have not done so at some point already.

It should be noted that using this method will no longer sync your calendar or your contacts. In order to sync those using open protocols and their standard authentication mechanisms rather than using the “Google” account in iOS to sync everything (which uses Oauth2 I believe), you’ll need to add your contacts using CardDav and your calendar using CalDav.

To fix this and get your contacts and/or calendar syncing on iOS again:

  1. Go to Settings.
  2. Mail, Contacts, Calendars
  3. Add Account
  4. Other
  5. Add CardDav or Add CalDav
  6. On the next screen:
    Server: google.com
    User Name: Enter your full Google Account or Google Apps email address.
    Password: Your Google Account or Google Apps password.
    Description: Whatever you want to call this account.
  7. You’re finished!

I hope this helps you resolve your gmail issues with iOS’ mail app.

Fix for Chromium Network Location Provider Returning Error Code 403

I had been using Chromium and wondered why it kept returning error code 403 and the message that’s in the title of this post when using the html5 geolocation features. It turns out that Chromium does not ship with Google’s API credentials as the normal build of Google Chrome does so those services are unavailable (Chrome/Chromium does not use the operating system’s built in location services and instead relies on Google’s API). After reviewing the Chromium documentation here, I’ve come up with the following steps to properly enable Chromium’s google services. It’s a lot of work, but I hope this is useful for the many people using Google’s open source Chromium on Linux, OS X, or Windows.

  1. Join the chromium dev group here by subscribing. You don’t have to receive email updates, you just have to be a member of the group in order for the right APIs to show up in the developer console.
  2. Visit the Google API Console and create a new project.
  3. Visit your project’s page in the console, click the APIs link in the left menu, and begin subscribing to developer APIs of your choice. In order to resolve network location provider issues when using Chromium, you’ll need the “Google Maps Geolocation API”. The Chromium documentation notes the following as useful APIs for Chromium:
    • Chrome Remote Desktop API
    • Chrome Spelling API
    • Chrome Suggest API
    • Chrome Sync API
    • Chrome Translate Element
    • Google Maps Geolocation API – (requires enabling billing but is free to use; you can skip this one, in which case geolocation features of Chrome will not work)
    • Safe Browsing API
    • Speech API
    • Time Zone API
    • Google Cloud Messaging for Chrome
    • Drive API (Optional, enable this for Files.app on Chrome OS and SyncFileSystem API)
    • Google Now For Chrome API (Optional, enabled to show Google Now cards)
  4. Click the settings gear after enabling the APIs of your choice and choose “Project Billing Settings”.
  5. Click “Enable Billing”, choose a personal billing account, and enter your billing information. Yes, in order for Google Maps Geolocation API calls to work, you have to have a payment method on your account. Having a payment method tied to your account won’t affect the fact that the quota for API calls to the Geolocation API is 100 calls per day and 100 calls are billed at $0.0 for personal accounts. If you’re still worried, check out Google’s documentation on Geolocation pricing here.
  6. Click the “Credentials” link in the left menu under “APIs & auth” on the Google API Console.
  7. Click “create new key”, then click “server key”, then click “create”. This is your “GOOGLE_API_KEY” which you’ll need later.
  8. Under “OAuth”, click “Create new Client ID”, choose “Installed application” and click “Configure consent screen”. Fill in the required information in the form and click “save”.
  9. Choose “Installed application” again, and click “Create ClientID”. Now you have your GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET which you’ll need later.

Now you’ll need to setup some environment variables for Chromium to pick up when it’s launched, the rest of these instructions are specifically for OS X using launchd, though with a little bit of googling it should not be that difficult for you to find a solution that works with your OS’ service/startup/daemon manager:

  1. Create a new script in your home directory, mine is named ‘.setGoogleEnvVars.sh’
  2. Add the following to the script, replacing the XXXs with appropriate values from your Google API developer console:
    launchctl setenv GOOGLE_API_KEY XXX
    launchctl setenv GOOGLE_DEFAULT_CLIENT_ID XXX
    launchctl setenv GOOGLE_DEFAULT_CLIENT_SECRET XXX
    
  3. Create a new launchd service in your home’s LaunchAgents directory, ~/Library/LaunchAgents/, mine is called local.setGoogleEnvVars.plist with the following contents, replacing the label and program argument of “~/.setGoogleEnvVars.sh” if necessary:
    <?xml version="1.0" encoding="UTF-8"?>                                                                                  
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
      <key>Label</key>
      <string>local.setGoogleEnvVars</string>
      <key>ProgramArguments</key>
      <array>
        <string>sh</string>
        <string>-c</string>
        <string>~/.setGoogleEnvVars.sh</string>
      </array>
      <key>RunAtLoad</key>
      <true/>
    </dict>
    </plist>
    
  4. Make sure your startup script is executable by using the terminal and chmod +x to set the executable bit like this, replacing the script name if necessary:
    chmod +x ~/.setGoogleEnvVars.sh
  5. At this point, you can either restart your computer or load the service with launchctl load ~/Library/LaunchAgents/local.setGoogleEnvVars.plist, replacing the plist name if necessary.

    That’s it! It’s a lot of work, but you’ve now enabled any of your selected Google APIs in Chromium, and you should no longer receive error messages like network location provider at 'https://www.googleapis.com/' : returned error code 403. code 2 if you’ve chosen to enable the Geolocation API and billing.