Denying apps with android.permission.VIBRATE in manifest?

paulscode

My game submission was just denied, and I was given four items noted by the team (which I assume must all be addressed before the app will be accepted).  Three of them are simple nit-picky things which I'll have corrected in a few minutes.  The fourth, however, was puzzling to me:

During Install there is mention of the game controlling vibration, there is no vibration support

Well, big duh there is no vibrator support on the OUYA, but my game isn't built to only run on the OUYA.  It is built for any Android device, including some that do use the vibrator, and others which don't, like the OUYA.  Having the permission in there doesn't break anything, so I don't understand the concern.

I guess my question is, will every game submission be denied if android.permission.VIBRATE happens to be in the manifest?  The reason I ask is because I'd prefer not to have to modify the manifest and rebuild a separate APK every type I publish an update (mainly because I am bound to forget to at some point in the future).

Dreamwriter

I don't remember where it was, but at some point in the past they said that all OUYA games would have to have the exact same permissions.

paulscode

Found what you are talking about (this article):

Permissions. Instead of the standard Android behavior where each app has its own custom permissions, we will define a default set of application permissions that will apply to all games.

Sounds like removing the permission every time will be a requirement.  Oh well..

theengineco

Are you building all of your APKs by hand?  This type of issue would be solved pretty easily using a build script.  Rake is my favorite, but you could use ANT, etc...

Cheers,

Nate

littleguy77

I'd like to re-visit this topic.  There is no good reason not to allow the vibration permission.

Granting the permission does no harm
  I understand that the OUYA controller doesn't have a vibrator, but granting this permission does no harm.  Graceful failure in the absence of vibration hardware is contractually built into the Android SDK.  This is by-design, to alleviate the burden on developers to write lots of conditional logic every time they want to activate vibration. As a real-world example, my Nexus 7 does not have vibration hardware, but I run all sorts of apps that require the vibration permission without any issues whatsoever.  As an analogy, you can ask my permission to drive my Ferrari.  Even though I don't own a Ferrari, it's still perfectly logical for me to say "Yes!"

Denying the permission causes headaches for developers
  On the other hand, there are many existing games on the Google Play store that use the vibrator to provide haptic feedback (for virtual buttons) and a "rumble" experience.  For example, Mupen64Plus-AE (which I'm a contributing developer for).  Porting these games to the OUYA platform requires us to make a one-off build just for OUYA, with vibration permissions removed and all calls to the vibration API removed.  Alternatively we have to insert a bunch of logic that run-time tests for the vibration permission (and we still need to custom build with a one-off manifest).  Sure, we can write build scripts to streamline this process, but why make us deal with this at all?  This just represents more hoops to jump through and dampens my enthusiasm for the OUYA platform.

If there are any OUYA devs here, I humbly ask you to grant this permission moving forward.  Thanks...

alsutton

What were the other 3 items on the list?

littleguy77

See the date of the OP.  This topic is about the vibration permissions, not the other 3 things (which were resolved weeks ago).

alsutton

None of the posts here indicate that anyone has been rejected solely for the vibration permission.

littleguy77

So as a member of the OUYA team, can you confirm that a game with vibration permissions can be installed on a retail OUYA through the OUYA store?

alsutton

I'd like to understand why you think it can't be. Your post says;

"I'd like to re-visit this topic.  There is no good reason not to allow the vibration permission."

which indicates you think it's not allowed. The OP said it was 1 of 4 things raised, no-one here has said they've had their app rejected for it, but I'd like to understand why you have the impression that apps would be rejected.

littleguy77

Can you simply confirm that OUYA apps are allowed to have vibration permission?

paulscode

The question of whether or not vibrate is allowed is from me.  That is why I started this thread -- to get the official word one way or another (which I haven't yet).  That is also why littleguy is asking that the topic be re-visited, since it was never officially answered.

For reference, the 4 issues raised which I was referring to:

1.During Install there is mention of the game controlling vibration, there is no vibration support.
2. In the settings the controller layout does not correctly display the OUYA controller, or naming conventions https://devs.ouya.tv/developers/docs/interface-guidelines
3. Once you enter the controller diagnostics screen, there is no way to navigate out, forcing the user to restart the OUYA console.
4. System button is used as back button, and does not allow navigation back to the OUYA menu/system screen

Let me reiterate that all these items have been addressed, and only #1 is relevant to this thread.  #2 took about 2 minutes to correct, and Piers and I discussed #3 and #4 via emails (those turned out to be caused by the isRunningOnOuyaHardware bug where the published ODK version at the time did not match the testers' more updated firmware.  That was also a couple-minute fix.)

The assumption that vibration permission is prohibited isn't that hard to make here.  Not only is it item #1 on the list of issues, but in the absence of information about which items are critical and which are merely suggestions, whenever 4 issues are raised, then the logical conclusion is that they must all 4 be corrected.  If that assumption is wrong, and vibration is allowed, then I apologize (the feedback probably should have been clearer).

Like I said, we have already addressed all 4 issues.  The purpose of re-visiting this thread is to to hopefully get official confirmation once and for all on whether OUYA apps are allowed to have vibrate permission or not.

So are they?

Richarmeleon

I have a question for you: Are you not already building a custom APK to take advantage of the Ouya hardware? Other Androids won't have the controller and are highly likely to have touch screens instead.

Piers

Paul, I'm asking for clarification on vibrate functionality that's latent code since OUYA hardware would ignore it.  I'm also asking if we are or can clarify which items in a rejection email are must fixes vs. observed issues but ones we could live with.

littleguy77

@Richarmeleon - The app has had controller support long before OUYA was around.  It's an N64 emulator and many users play with gamepads and plug their phones into their HDTV.

@Piers - Why is this question so hard for team OUYA to answer?  You guys keep answering this question with more questions.  For the third time, Is it possible to install an app with the vibrate permission on the OUYA?  A simple yes or no answer will suffice.

Piers

We wouldn't fail only for vibration, tilt, etc., but if Android or iOS is mentioned it's a fail.  But giving users the impression there is functionality in the OUYA version that isn't there is not generally going to impress your customer.  Running a compile script to make changes for each platform isn't too hard, but it's work that we feel is well worth the minimal effort and tends to give potential customers a better impression of the product. 

@littleguy77 your question was about permissions, which has now been answered by default.  The more important question though was whether exposing this to the user as a feature is a failable issue.  It's not, but again it's best to script your APK versions appropriately as it only makes you look good.

littleguy77

You have to remember, this is a free open-source product, and we have real jobs by day.  We are adding value to your platform without so much as asking for a dime in return.  Our motives are different than your average indie developer looking to make a name and a buck for himself.  The "minimal effort" that it takes us to support custom builds cannot be justified by the usual monetary return on investment.

You also forget that just because the OUYA controller doesn't have a vibrator doesn't mean the feature is irrelevant on the OUYA platform.  Xbox 360 and PC controllers are compatible with OUYA and they do provide vibration support.  Keeping the feature in the OUYA build gives users the best experience possible.

Piers

We do appreciate that, which is why this is not a fail.  The suggestion to run a simple script is because it isn't too time consuming and will make your game better in the eyes of users.  It is possible users could plug in another controller and it might rumble, but for unofficially supported controllers and a rumble feature that's a lot of ifs :)  In any case, question answered and thanks for the great apps!

littleguy77

Just to be clear, the app already supports rumble on those controllers for all phones/tablets/consoles running Android 4.1.  It's a well-tested, stable feature of the app and O/S, not some new concept that we just started developing for OUYA.  So, not a whole lot of "ifs".

paulscode

@Piers, I agree that advertising a vibration feature on the OUYA would clearly be misleading to most users who might not realize the controller doesn't vibrate.  Either way, it isn't an issue with Mupen64Plus AE, since vibration isn't advertised like that... if vibration is supported, then it is used where applicable (such as Rumble Pak emulation).

@Richarmeleon, the only thing requiring a custom APK for OUYA was the lack of vibrate permission in the manifest.  I've mentioned this on other threads here, but I do not see the value in making custom APKs when sets of interfaces and features can simply be pipelined in a single APK.  If I have a tablet-sized display, optimize the controls for tablets.  If I don't have a touchscreen, use controller-based menu navigation and don't show the touchscreen controls.  If I don't have a vibrator, don't vibrate.  There's no reason to have a completely special build for every system.