This is only issue #164 on the list of most annoying Android bugs as measured by the number of people that got so annoyed that they hunted down the unfriendly Android open source issue tracker, searched through countless other issues for the one they were annoyed by, logged in or created an account, and starred the issue. Some of these bugs have been open for over 7 years.
I remember 7 years ago following this one: https://code.google.com/p/android/issues/detail?id=1109 (Alarm clock produces no sound or vibration). I was an "early adopter" of Android and, as result of this bug, got late for work two or three times. :)
They marked it as "obsolete", but - to be honest - I still wouldn't trust an Android as my alarm for anything.
I'm confident in saying the countdown timer is not 100% reliable, because several times the screen has very obviously said something like "-2'15" when the alarm has gone off. I didn't really pay this much mind this the first few times, because I mostly use it for timing food, and most food isn't sensitive to an extra 2 minutes. But then one day I was timing a bread roll (8 minutes) and after 10 minutes it was noticeably charred.
If they can't get the countdown timer right I don't see why there can't also be bugs in the alarm clock too. I use it every day, and it's mostly reliable, but I'm suspicious it's failed to go off a couple of times...
I think that's an intentional choice to show you how long past the timer you are if you haven't cleared the timer. It could be useful in some situations especially if you didn't notice the timer and need to know how ruined your food is going to be.
Yes - this is also with the phone right next to me the whole time, so it's not a case of me missing something. I assume it's possible for the phone to go into some kind of sleep mode whereby timers are checked much less frequently. Seems a bit daft to allow this if there's an active countdown timer that could expire before the next check...
Ah my mistake I thought you were talking about the negative time that shows up AFTER the timer has gone off but hasn't been acknowledged. I always use timers on my Moto 360 because it's much more pleasant than the default chirping to hear.
I'm using Fake Dawn as my alarm app. Hasn't failed me once. But I do use the Android alarm clock occasionally on non-working days, and I've slept through that more than once. It hadn't occurred to me yet that something basic as a timer alarm could be broken.
Oh, great, so it still happens? I really found the "obsolete" status on the issue rather strange, but (as I'm not using Android anymore) it was really just a suspicion.
If it happens to you, maybe you could create a new issue on the tracker, stating that 1109 isn't really obsolete - it still happens.
I have been using the stock android alarm clock for a couple of years (and Timely before that), both work like a charm.
I would not be too surprised if they were to fail someday (IIRC it happened multiple times with the iOS clock app), software & time are both complicated..
I'm not sure how Android development works but as a open source project, how come noone implemented simple things like "Add setting to disable all Heads-Up (POP UP) Notifications" yet? Is it the Android team rejecting patches or just lack of interest in getting involved?
Android also conflates language code (say, en-GB) with physical location for many apps. And does not provide a Canadian English (en-CA) -- so if you want to not have the phone constantly spellchecking your emails incorrectly when you type colour, neighbour, etc, and switch it to en-GB to get it to shut up it then starts giving you UK news in the News & Weather app, and reads your turn by turn directions with an English accent.
And there's a similar ticket open about the subject. Also ignored for many years by the Android team.
I've thought about raising a ticket internally (I work at Google) about it, but I imagine it would suffer the same fate.
On a related note, I live in Germany and like setting my device's language to en-US. I like the US news, as they are personalized to my taste anyway.
What I dislike is that temperature and distance in a couple of apps are now in US units, which I find unreasonable. I should be able to choose SI units if I want to.
Windows has been getting locale settings right for ages now. I find it sad that Android is so far behind in that regard.
I have my Android device set to use en-GB as its primary language for metric units, my spell checker is set to en-US, and my Google News is set to India.
What you want is already possible. However, I do wish the platform allowed a more direct customization of all LC_* stuff.
> Windows has been getting locale settings right for ages now.
Do you mean Windows phone? If so, I'm impressed. If you meant Windows, the computer OS series, well, that would not be a fair comparison for Android. Linux already gets that right.
When I switched from Android to Windows Phone back in 2012, I was surprised with the quality of the localization. I lived in a very small town in the middle of Brazil and even so, the dictionary knew all regional words, town names and prety much anything I tried to type on it.
Everytime I use iOS or Android, I'm quickly reminded that that is not the case outside windows phone.
> What I dislike is that temperature and distance in a couple of apps are now in US units, which I find unreasonable. I should be able to choose SI units if I want to.
And I'm in the opposite situation: I prefer British English but want traditional units only.
This really should be user-settable. Heck, even outside of America some folks prefer decimetres over centimetres!
Yes, and in regions outside of America there are folks who prefer to see lengths in decimetres and there are folks who prefer to see lengths in centimetres. Sure, it's easy to convert by sliding a decimal point, but they want to see the order of magnitude they're used to.
Windows has been getting locale settings right for ages now.
That's because those settings were designed before the era of "simplify everything that could even slightly potentially confuse an idiot user" and have been retained from then. I wouldn't be so sure if the future Windows versions will still be as customisable, given that they've already removed things like the ability to change fonts and colours in the UI. It's almost a given that sooner or later someone will come across it, think "let's overhaul/refresh/'enhance the UX'", and turn it into a totally sleek and stylish but less functional version of what it used to be.
Meh. iOS gets all of this trivial localization stuff right (correct timezones including UTC, en-CA spelling dictionaries, not conflating locale and location, etc), even though Apple is often accused of being the poster child for oversimplification
Apple manages to do it just fine. Although the advanced settings are a little threadbare on iOS they are very powerful on OSX and still serviceable on iOS.
OS X, just for example, hasn't allowed users to cut and paste files for years and years, for fear that the poor darlings might be confused when cut files, unlike cut text, remain in place until pasted. This isn't just a default setting; they removed file-cutting from the OS.
I love my MacBook, but Apple makes stupid decisions just like anyone else.
Right, but the Finder does have Copy and Paste. Cmd-C and Cmd-V have worked in the Finder since the very first Mac. It's even in the edit menu.
I suppose they expect you to click and drag to move a file, rather than the slightly unintuitive Cut and Paste on entire files. There's no real physical analogy for a cut.
All right. Refusing to implement a useful feature for anyone because it's deemed too confusing for novices isn't any better than removing a useful feature because etc., though.
(The recent addition of a special hotkey to paste-with-delete is not much of an improvement, since it still obfuscates the actual, expected behavior (of Ctrl-X) in favor of a different, more obscure, but notionally "friendlier" alternative.)
Amen to that. I find it clumsy to require two finder windows open to move a file between them. Why not cut a file from one directory, open another directory, and paste it there? Ugh!
Most people don't seem to know this, but you basically can cut and paste in the Finder.
First copy the files you want, then move them instead of pasting (Command-Option-V). This gives you the same behavior without the confusion/danger of the files being lost in limbo between cutting and pasting, which I think is honestly better UX design.
In windows if you don't paste the files somewhere they just go back to their original location like they were never "cut" in the first place. Cutting without pasting is not a dangerous or destructive operation.
I think the OP means in all other apps, cutting means removing the selection and put it in the clipboard until it is pasted somewhere. Windows Explorer override this behavior by turning cut into move, which break the semantic and may create confusion that the file might go away if user didn't choose to paste it, if user have used cut in other program but not Explorer.
The way this works on Windows (I think) is that internally, "cut" means "copy file path to clipboard", and "paste" means "move file from old place to new place". Thus, if you want to cut and paste from "Downloads" to "Documents", then it doesn't matter how big the file is: you just change a couple of directory entries without ever changing the file. If you want to do this across file systems, it has to do a copy.
That's the app developer's fault. They thought they were being smart by saying "oh, if you're in en_GB, lets give you Yelp.co.uk by default". And yeah, sure, that works for most users.
On the other hand, I don't think its fair to fault app developers for that, since there isn't otherwise a way to query the OS for "what country is this user in?" without asking for (and getting) full-precision location access.
Then simply ask them. The whole idea of an app automatically tracking your location and localizing the content without the ability to pin your location is frankly idiotic. It's like whoever comes up with that great plan doesn't know people travel. Websites are especially guilty of that.
On phones, http://developer.android.com/reference/android/telephony/Tel... is probably a better estimate of the user's home country and getNetworkCountryIso() is a good estimate of the user's current country. The fact that my Android phone doesn't have en_CA as a locale option (maybe because they're too cheap to localize the system apps for Canadians, who mix British and American spellings) means that anybody who tries to get the country from the locale region code won't recognize Canadians with this phone.
In this case the app developer is Google (News&Weather and navigation). So there's that.
And the stubbornness in refusing to add en_CA is confusing. How long could it take? At the risk of talking ill about my own employer (Android is a different team which I have no connection to tho) it seems rather culturally insensitive. I'd put the change together myself if I knew anything about it.
I should note that this is in stock Android on a Nexus. Motorola and others ship their Android with an en-CA locale.
What is good about en_CA? Do you just want colour in spell check instead of color? I have always left my machines in en_US to avoid any bugs due to strange keyboard mappings/layouts and general paranoia that things only get tested when in the standard configuration.
I already stated above. Lack of en_CA and use of en_US means it gives me news, weather from the US, and default measurement units in the wrong form, and it spell checks things wrong.
And switching to en_GB means getting dinged for words like organize, getting odd keyboard layouts, getting news and weather from the UK, and navigator speaking in English accent and dialect.
It's worth nothing that other manufacturers (such as Motorola) ship their Android with an en_CA locale. It's stock Android on Nexus that has the problem. That Google hasn't bothered is rather awful.
I have an Android Priv and it has the option for "English (Canada)" under "language & input", as well as "English (Canada)" for both keyboard inputs. The spell checker is set to "Use system language".
Oh, they should. Or preferably they should let you choose that specifically. I was responding towards the idea that they should include all variations when suggesting, not just what they see as your local variation.
Last I checked, the stock Clock app has a similar dysfunctionality: in the World Clock tab you can add multiple timezones but there is no option for either UTC or GMT. Weirdly, many of the listed cities are just plain wrong. IIRC, it had Santa Fe, NM listed as UTC+0:00.
Thanks for this post. Now I'll wait a bit longer before moving to an Android phone.
From a developer's point of view, Android is known to be a mess. I thought the reason was the lack of organization between the numerous manufacturers. Now I see that the reason is even more fundamental.
Reykjavik is available on the world clock, and if you go there it picks up the correct timezone automatically. The only missing part is that the system timezone widget which you would never normally use doesn't have it.
Also, while excluding a country would be a fairly crappy thing to do, Iceland is the 174th largest country in the world by population, so it's not big relative to very much at all
I hope it has improved since last time I've worked with it (3 years maybe now ?). But on top of my head this were the problems I faced (probably not up do date now, I hope it's much better now):
- The emulator was slow as hell
- Impossible to resize the emulator window dynamically so testing is really slow and painful
- Bugs with manufacturer roms & drivers (hello Samsung !) So you have to test with a lot of devices without guarantee it will work
- you have to copy all the fields yourself when your device pass in portrait mode since everything is being erased (even text fields)
- You need to create some strange XML for just about everything, nothing really works by default.
- No package manager for the libraries, you have to copy some random .jar here and there
- Really poor API. No usable date picker (I'm discarding the default one here), no file picker, no contact manager you can inherit from in built-in, you had to reimplement everything yourself, even a button with an image on it you had to do it yourself.
- Poor consistency in the XML names, it was difficult to guess what meant what.
- The documentation was also hard to browse
- The permission system is close to broken (they are working on that at the moment apparently).
- If your APK is too large, APK expansions (can't remember the exact name now) API's were borderline broken and buggy.
- SD card management was a mess.
- Everything related to layout was difficult to get it right and nothing would ever resize right unless you put a lot of effort into it (the opposite of the web on this).
- Android browser was close to unusable but now that I've checked a recent version, it seems they solved that.
The emulator is fast as hell now (faster than using an actual device, according to them). Many of the other issues you have mentioned here are fixed as well.
Not being an Android dev myself, these are some complaints I've heard: There are a ton of resolutions, aspect ratios, and screen sizes. There are a lot of GPU vendors. Driver quality, performance of specific features, little tricks to even use specific features, etc, vary between each of those vendors, and your program should support as many as possible. Different phones have different input methods and peripheral hardware (sensors, notification lights, vibration motors, 3D screens, slide-out keyboards, etc), and trends in the market shift over time.
Compared to Apple, there's a lot of variability in devices, and that may be what they were referring to.
> There are a ton of resolutions, aspect ratios, and screen sizes. There are a lot of GPU vendors. Driver quality, performance of specific features, little tricks to even use specific features, etc, vary between each of those vendors, and your program should support as many as possible.
IMO, variety is not a mess - this is has been the norm programming for the consumer space for decades (PC applications, all non-console games, web development). Fixed resolutions & hardware is the exception (consoles, and previously iPhones: now iOS devices are 'fragmenting' too)
This is endemic to a lot of Google products it seems. Google Calendar has no recognition of UTC/GMT either. It's really irksome since a lot of calendar invites I get that are sent out to global participants have their times in UTC/GMT, and I have to manually convert them to create calendar reminders that fire at the right time.
Any time I, as a human, have to do something that a computer can trivially do, and get right -every time-, is an indication of seriously bad UX.
I've never had a problem with calendar invites in other timezones on Google, and I suspect a number of those come in UTC. Is it possible that the UTC invites you are getting don't actually have the timezone attached? In the absence of a stated timezone I'd have thought assuming the user's current timezone was the safest course of action
You can't create a calendar invite in UTC. Period. This was a year ago; I don't remember the specifics, but either the invite I had was for UTC, and Google Calendar put it in in my own timezone, despite it being clearly UTC, or I had to enter it by hand, and there is no way to specify UTC/GMT by hand in Google calendar. The issue is not an import issue, it's that Google calendar literally does not have the option, at least that I can find. You have to select a region, and there is no special 'UTC' or 'GMT' region, and clicking on the UK does not give you "Greenwich" or "GMT" either.
Though per another comment, yes, if you happen to know a locale whose timezone is the same as UTC/GMT, you can use that, but that's still hilariously unfriendly to the user.
There are lots of tiny little issues like this in android that have been fixed for a long time in things like GNU. The worst part about android is that it's just so incredibly huge there's no way for anyone to come in and tweak little things.
It's actually pretty straightforward to come in and tweak little things, and there are lots of projects that do it. The problem is that nothing ever gets accepted upstream, and (therefore?) lots of projects never try.
How do you go about doing this? Last time I started I was told to pull down 100 GB of code. That's ~ the monthly limit of my connection so that wasn't happening
Right: It was designated with the letter "Z" quite a long time ago, and only later did military (esp. NATO) communication-guides bring "Zulu" into the picture, as a way to disambiguate individual letters like Z, T, C, D, etc. when spoken. </joke-frog-dissection>
Yes, I believe his joke/point is about the order of causation: The letter came first, and the name followed, rather than the letter being an abbreviation of the name.
I would be very glad if they just find a way to make android adjust the clock to the local timezone when I'm traveling. There is a option for that, obviously, but it simple don't work. iPhones and macs take 2 minutes or less to update the clock, but here I am, two days at my destination, and my Nexus 5 still shows home time.
I wish it was that easy. I tried, since I bought this phone, all combinations of turning off wifi, data, airplane mode, shutdown phone, hard reboot phone. ;(
And twice as long to code review! Meanwhile they're spending time on really useful features like full-screen album art that you can't turn off on your lock screen.
I'm not aware of anybody outside of IT who uses or even understands UTC in place of GMT, so making this change would be a significant backwards step in usability.
The problem to me seems like they are only offering political / locational zones. It does not seem like it would be a significant step backwards to offer an option to set your time zone to a manual fixed offset, which is all the people on the tracker seem to want.
Most people get timezone set correctly automatically to their current location, including folks in Iceland. Specialist users who want to do something odd might discover the unloved system settings widget (it's missing on a lot of phones anyway) and want that to cover their use case, which it couldn't without getting too complex for most users. The specialist timezones are available however, they just need an app like timezone changer to pick them.
I want advocating switching the main time zone selector over to a text box that says, "Enter a valid POSIX time zone string", I was suggesting that at the bottom of the list of selectable time zones (which you only reach generally if you turn off automatic time zone selection) there be a button that says, "choose a fixed offset". Seems like a no brainer.
Short of the very rare case of being a bona-fide expert and up to date in an area "I'm not aware of..." is a deeply flawed input for design and implementation.
I'm not the designer. I'm just suggesting reasons why the designers of Android may have chosen the design they did rather than the design the issue demands is the "correct" way
My point was, absent doing real work to find out the "right" answer for a range of users, what you or I are aware of is so full of selection bias as to be basically useless to generalize from. It's also an incredibly common failure mode, because you already "know" the answer.
Anyone who had to deal with time zones at least once in their lifetime, provided that they have a perfectly natural habit of reading Wikipedia when they find something new to them.
Looks like people cannot set their time zone to UTC. Depending on the device there might not be an UTC equivalent time zone to choose from either, like Reykjavik may not be available on all devices.
It sounds like this is more than just a request for a terminology change. If I'm reading it right, Android's notion of GMT is that it's British time, with a Daylight Saving Time offset in the summer.
Right, Britian uses GMT a portion of the year, and then switches to BST (British Summer Time) during the summer. BST is GMT+1. Android uses GMT and when summer comes around, Android's representation of GMT becomes GMT+1.
https://code.google.com/p/android/issues/list?can=2&q=&colsp...