Languages

Menu
Sites
Language
App failed validation due to using eina_array_grow that it doesn't even use

I've submitted an update to my 2.3 native mobile app, but unlike with the previous submit now it's failed because of claimed API usage violation. It uses the same APIs as before, so I'm not sure what could have changed -- other than the online validation got stricter for whatever reason. The APIs in question are:

eina_init
eina_shutdown
eina_array_grow

Now, my app indeed uses eina_init and eina_shutdown, so I can easily comment those out to conform the new API rules.  But, my app source has no eina_array_grow in it, so I cannot remove that API use. What my app uses is eina_array_push, and that particular API call calls eina_array_grow.  But my app doesn't call eina_array_grow explicitly, so how can I solve this issue?  Other than not using eina_array_push, of course.  At this point I feel the new API rules are both too strict and very inconsistent in the same time. If it's prohibited to use eina_array_grow, then why is it fine to use eina_array_push?  And why is eina_array_grow prohibitied anyway?

Thanks,
Tamas

List

Responses

8 Replies
Alex Dem

Hi,
Try to ask In Tizen Store->Support ->My Q&A also.
Alexey

Tamas Miklos

Thank you, I've just done that. I was hoping maybe there's an actual -- publicly stated -- explanation on why the API validation got stricter. I see no harm in using the eina_array_grow API for example, unless someone would like to quickly fill the whole RAM from an app. But such malicious activity should be easily spot during the validation process anyway, so it wouldn't require blocking the API...

Tamas Miklos

I've got a response from Tizen Store Seller Office Team, and as I've expected, they simply redirected me to here.  The way Samsung supports native app developers is simply amazing, and I don't mean that in a good way.  I can and have to work around many issues I'm facing while developing a native Tizen app, but when the automated validation system tells me to f* off, complaining about something I simply don't do, and I get absolutely no help from the support even though I've reported a clear and obvious bug of the validation system, then I'm starting to question whether professionals drive the development of the Tizen platform. Or maybe I'm on the wrong path and shouldn't develop native apps at all?

What I would expect in such a situation is a short "Thank you for reporting the issue about our validation system, we are already working on the fix. Please re-submit your app, and this time it will work out fine". Or, if that's too much to ask to resolve a mistake of the validation system: "Thank you for report the issue, please use XXXX API call instead of YYYY API call to work around the issue". Is it too much to ask?

Carsten Haitzler

we absolutely should not respond to you like this. what you have is a bug from over-zealous lockdown where api's have not been checked carefully before locking things down.

i brought this and related issues up earlier in november and have pushed for the wheels to churn fast, but they aren't moving fast enough at the moment. stay tuned, but i hope this and related issues will be fixed soon.

please be aware that people helping you here generally have no ability to fix anything in the validation system or even make a call as to where the issue actually may be. they're working within limits.

Tamas Miklos

Thank you for your comment ;) I understand that people can make mistakes, APIs and validators can get overly sensitive, but I'd expect 2 crucial moves (by Samsung) about such issues:

1) Proper communications on how and when the validator gets updated, so I can prepare my app to comply with the new, stricter validator. I'd also expect guidelines on what alternative methods can one use, and ideally, an explanation on why the validator got stricter.

2) Proper explanation on the rejection, guiding developers to fix issues easily. Since my app was successfully validated previously, it's not my fault that now the new validator kicks it out. I've made a proper app before, complying to all the Tizen Store rules, and I haven't made any changes that would cause a rejection now. It's absolutely the right thing to point to specific API calls, but the system should take care of following inline code, and not complain about such calls that the app source doesn't include. Why would an app developer have to know about what further calls the API calls call or get transformed into? :)

BTW, a proper offline validator would also be a great help about such issues. Although, other companies with more experience in app platforms make huge mistakes about keeping offline and online validators in sync, so I don't get my hopes up about this :)

BTW #2, since I have quite an experience in developing apps for multiple app platforms and their store validation systems, I can see that none of them works properly. But I still would like to raise every single issue and expect them to be resolved. I'm sure one day all my issues get resolved, but due to the slowness of Samsung, until then I have to use my own tricks to get around the bugs of the Tizen platform and Tizen Store. It could be fun up to a point, but when I hit the wall, it starts to get very frustrating that I cannot speak to any proper technical persons from the Samsung staff...

colin Rao

Hi,

I don't find such api eina_init and eina_shutdown from the help doc of Tizen SDK 2.3.1. Suggest to use eina_array_new() and eina_array_free() to instead of them.

Also, I don't find the eina_array_grow(), but from the api description seems the eina_array_push() will call it dynamically while append new item to a full array. 

Is it possible,  in your app call the push function very frequently, try to set a larger step when you call eina_array_new(). 

 

Or, possible you should to implement a C like array by yourself.

Tamas Miklos

Thank you for your response. I think I got the idea of using eina_init and eina_shutdown from one of the Tizen native mobile app samples. I definitely didn't find those in the API docs. And the 3 API calls in question never caused an API violation until the end of October, so something definitely got stricter in the Tizen Store validation system. I wouldn't have a problem with that, if it is properly documented, properly communicated to developers, and also implemented flawlessly.  But as far as I can tell, none of those boxes are ticked at this time: no documentation on which APIs to avoid from now on and why, no emails received about those changes, and the whole system works incorrectly about eina_array_push.

Anyway, what I've done is exactly what you recommended. I've implemented my own eina_array_push, since the original one used static inline code, which led my app to call eina_array_grow without me intending to do that or being responsible for it. Now, with those workarounds the app update was approved. Hopefully no more such surprises will block us from issuing further app updates in the future.

Abhilash Kankokkaran

Hi,

I am also facing rejection with similar APIs.

eina_value_type_check[dehazez3]
eina_value_inner_alloc[dehazez3]
_EINA_VALUE_TYPE_BASICS_START[dehazez3]
eina_value_new[dehazez3]
eina_value_inner_free[dehazez3]
eina_array_grow[dehazez3]
_EINA_VALUE_TYPE_BASICS_END[dehazez3]
eina_value_copy[dehazez3]
eina_value_struct_member_find[dehazez3]

 

 

But i am not using any of the above APIs.

Only eina APIs i can see is,  EINA_TRUE, EINA_FALSE and Eina_Bool.

Is this causing the issue ?

Any inputs are welcome.

 

Thanks in advance

Abhilash K