So happy you're building this, @yixler! Thank you!
As all us programmers (and probably anyone who's ever interacted with a programmer -- or even anyone who makes anything, involving code or not) know, the most likely failure mode here is simply that something will distract you before you get it to the point that it's ready to ship.
So you may not need to beemind time spent, but in terms of assuring us that this will really happen, I think it's a great way to do it. Kind of like how @bee committed to spend 20 hours/week  on the last 5 autodata integrations until they were done. Which ended up taking 5 months but she was very firmly on the hook to ship eventually, and did.
You may not want that hard of a commitment (and certainly not that amount of time) but if you add a simple "no guarantee I won't flatten or archive this, subject to the akrasia horizon" then you're probably retaining plenty of flexibility while still, from our perspective, drastically increasing the probability that Android GTBee will see the light of day. Because I think it's rare for such projects to get deliberately abandoned. More often the developer gets briefly distracted with still a strong intention to resume work "tomorrow" but then you end up in a "one more day won't matter" slippery slope of sorrow.
In conclusion, you should totally beemind time spent! Something super conservative that you could only derail on by wandering away altogether. Also it's just nice to see the metric, right? How many hours will it actually take compared to how many it seems like it should...
Alternatively we could just start a betting pool for when this will ship, and encourage you to participate. (:
 With her derailments and initial flat spot the actual average was about 16 hours/week. Oh, and I guess it was deemed fair that the spirit of the commitment was half her Beeminder time, so she was allowed to make the road shallower during a couple trips when she dialed down her main Beeminder meta road from 40 hours/week.