Android’s much ballyhooed 1.5 release (aka Cupcake) seems to be imminent. Last week, Google released a preview version of the SDK, and I’ve dug through it a bit and kicked the tires. In honor of the impending 1.5 release, here are 15 neat features I really dig.
Archive for April, 2009
15 New Kick-Ass Cupcake Features
Monday, April 20th, 2009Changing Android DRM Breaks Apps
Tuesday, April 7th, 2009**UPDATE (4/20/2009) – a Google employee has commented on the open bug report and says this will be fixed in a future software release. Whether this makes it into the impending Cupcake update is anyone’s guess, though.**
Today we released the 1.1 update to RockOut Acoustic Pro. This update adds some neat new features like “Fretting Mode,” which lets you hold the screen to “fret” chords and strum using the trackball. We thoroughly tested the application for both new installs and updates from the old version, on both the Android emulator and an actual G1. Everything looked good.
But when we actually put the update on the Market, some users complained the app was automatically force closing (read: crashing) when they installed the update.
I couldn’t reproduce it, but then a user sent me his log files (thanks to the wonderful Log Collector app). Here’s some relevant parts, and then the explanation:
E/PackageManager( 51): Package com.activefrequency.android.rockoutacousticpro has mismatched uid: 10046 on disk, 10047 in settings; read messages:
...
E/Database( 228): sqlite3_open_v2("/data/data/com.activefrequency.android.rockoutacousticpro/databases/song_list.db", &handle, 6, NULL) failed
...
Here’s why this happened: When we first released RockOut Acoustic Pro we had copy protection turned on. I turned it off a day or two later because an odd Market bug that Google won’t really acknowledge causes copy protected apps not to show at all on the market on many phones (normal G1s, not just ADPs).
This only happened, as far as I can tell, to users who previously had the copy protected version of my app installed.
The copy protection mechanism changes the uid of the application, so that non-copy-protected versions of the same app signed by the same key are no longer recognized as the same application, and are denied access to the database and other resources for the application.
This is never documented anywhere in any official Market or Android documentation, as far as I can see.
Plus, we had no way to figure this out on our own because developers can never install their own paid apps off the market, therefore can never test the copy-protected versions of their apps!
Now that I actually know the root cause of the problem, it’s easy enough to google and I can see I’m not the first dev burned by it.
There’s a ticket to fix this but no progress that I can see. This means Google is aware of the problem, yet doesn’t tell you about it when they know you’re about to break updates for your app by checking or unchecking the copy protection box. This is a 100% predictable result, and should be simple to warn developers about before they hurt their reputation or suddenly get dozens of negative reviews.
The absolute bare minimum Google can do is DOCUMENT this. I can’t see it taking more than 10 minutes to add a warning box when you add or remove copy protection from an app already live on the market, and it would have saved me a good hour of frantic hunting for a bug in my code that wasn’t there.
Is just disclosing this to developers too much to ask?
MySQL WTF: “1, 2″ == “1″
Wednesday, April 1st, 2009MySQL, how ridiculous you are. But seriously, though – what are you thinking?
I learned today (belatedly perhaps) that joining a VARCHAR field to an INT field does something… interesting. To illustrate, try to follow along:
CREATE TABLE `test` (`col_int` INT, `col_str` varchar(10));
INSERT INTO test(col_int, col_str) VALUES (1, '1'), (2, '1, 2'), (3, '2, 3');
SELECT * FROM test t1, test t2 WHERE t1.col_int = t2.col_str;
A pickier database would probably scream about type incompatibilities. But MySQL… MySQL doesn’t care, and silently truncates “1, 2″ to “1″, which it then casts to an int. And this is how you get the string “1, 2″ being equivalent to the int 1.
Only in MySQL-land.
* PostgreSQL fans: I know, I know. Shut up already.