[danm]

The Symbian Signed improvements which you'll have read about on the Symbian Blog, and in postings made here, are taking a look at the whole Symbian Signed process. We're looking at the process from the point of view of the developer, the OEM, the Operator and the others involved to try to identify where we can change things to make the process quicker, cheaper and less complex.

The Symbian Signed Test Criteria are key to the Symbian Signed process. They define the tests which an application must pass before it can be Symbian Signed. The criteria are used by developers to test their applications before submission, and by the test houses when conducting Express Signed audits or testing an application which has been submitted through Certified Signed. Developers need to use the criteria to test their application before submitting to Express Signed, too.

The test criteria have been reviewed many times before, and tests have been added, changed and removed. But this time, we've taken a more fundamental approach. We have looked at what we believe Symbian Signed should be testing and derived test cases from there. We believe that the two key aims of Symbian Signed are to guarantee the origin of the application and to ensure that the application is "well-behaved" when installed onto the device.

The draft of the test criteria attached which I've posted up for review today is early in the process. We believe that it's important to get as many eyes on this as possible as soon as we can. Developers, OEMs, Operators, Symbian Employees and interested observers of the process all have very valuable opinions on Symbian Signed, and we want to hear from all of you.

At this early stage of the process, we are interested to hear your broad thoughts on the criteria. Do you think that we are testing enough? Is there anything in there which a developer would find hard to fulfil? Are the tests fair? Is there anything you think we should be testing, but which isn't included? Is there anything we have included which you think shouldn't be in Symbian Signed?

Finally, please remember that the old criteria (version 3.0.3 issued November 2008) are still in force and we'll give plenty of notice before we switch over to using the new criteria.

[gailu76]

Hi,

There is a major difference between 3.0.3 and 4.0.8 criteria that is going to affact significant number of applications and I would like to point it out here.

Background:
There is a big strength of Symbian over Apple iPhone that it can run background application. Generally application running in background does not have UI inbuilt, so doesn't appear in tasklist. However developers provide UI seprately (Application Menu) to start-stop the application (generally via inter-process communications). This is a very very common practice in symbian.

Test Criteria 3.0.3: Test UNI05:
In Test Criteria3.0.3 there was specific Exception to cater this situation


UNI-05.EX3: Application Meets End User Expectations
With certain types of applications it is inherent in their functionality that they are not intended to close. Providing the application clearly functions within the end-user expectations of the application it can receive an exception from being closed via the task list. However in such case the user must be able to close the application from an Exit or Close option in the application menu.

Test Criteria 4.0.8: Test02:

This has similar compliance requirement but no exceptions are allowed.

No exceptions are available for this test case. Any non-compliant applications
must be accompanied by a waiver request.

All the application that are approved previously with UNI-05.EX3 now required a seprate waiver submission which is going to hurt lots of developers. I request you to please revist Test02 and allow an exception for such a simple use case.

[rodb]

Thanks for the comments. This is exactly the reason why we wanted to bring an early version to developers for review. These are the kinds of practical issues that we need to think about.

[bbj]

In our view its a complete nonsense to have a test criteria that says "Meets end user expectations" without a very strict definition of who the end user is + precisely what they are allowed to expect - in the test criteria. Its far too subjective.

Its totally impossible for a Test House to meaningfully interpret this + come to the same interpretation as the developer - which is exactly where it all becomes very painful. E.g. If we are producing a quick + dirty app as an internal proof of concept but want it signed to stop a certain level of in house support or need it signed for some of the capabilities then the 'end user expectation' is going to be radically different to say a general commerically available consumer facing app.

At best this type of 'test' is only relevant to publically available commerical products + should probably only be relevant to a particular distribution scenario and even then one users expectation is entirely different to anothers.

[danm]

Originally Posted by bbj

In our view its a complete nonsense to have a test criteria that says "Meets end user expectations" without a very strict definition of who the end user is + precisely what they are allowed to expect - in the test criteria. Its far too subjective.

I agree. That's why all testing of "meeting user expectations" is removed from the latest draft of the Test Criteria. The quoted text in the earlier comment was taken from the old test criteria rather than the new proposal.

[gailu76]

Hi,

Please note that I am not saying that you have copy-paste the text from Old Criteria. All I am saying is that look for the reason why that exception was there earlier (simply because there are uses cases for that).

Agreed that there must be strict well defined criteria unstead of loose words; however If I need to submit a waiver request for new version of the application that was approved already and nothing changed with respect to task list compliance, I would rather decide not to create the new version.

Creating a UI in a console application solely for the reason that it appears in the task-list is simplay waste of resource and will adversly affect user experience as it will hog memory resource that is not equired by application at all but to fulfill test criteria.

[simonjudge]

Test 06 Autostart doesn't say if autostart can be On by default. This is required for many applications otherwise they wont work as desired.

(The current autostart test case says the app needs to ask the user at startup)

Simon

[danm]

Originally Posted by simonjudge

Test 06 Autostart doesn't say if autostart can be On by default.

Enabling auto-start by default will NOT cause your application to fail the test.

This was one of the most common issues with the previous test criteria, and so we decided that so long as the user could disable auto-start functionality, the application can set auto-start to "on" when first installed.

[brian_____]

RE: TEST 04 - No disruption to text messages:

Let's say there is an SMS based application like (e.g. Twitter) that sends/receives messages with a well-known SMS code (e.g. 40404). If an application has an option to intercept messages from this well-known number and display them in some specialized way (e.g. refreshing a Twitter timeline), would it be violating this criteria? If the application changes the notification settings for this number (e.g. silent ringtone, turns off notifications) would it be violating this criteria?

RE: TEST 07 - UI Layout Behaviour:

If an application passes this test, but afterward a new device is released on which the application would fail the test, will the application's signature get revoked?

I would like to propose a new test: Application does not attempt to install an older or incompatible version of 3rd-party packages. For example, let's say the phone has EUserHL 1.2 installed. An application must not attempt to install EUserHL 1.0. The compliance checking tools can automatically check that all embedded SIS installations are conditionally done only if the installed version of the package is lower than the version to be installed. Applications that use the installer API to install libraries must be checked manually.

In the Installer UI thread on the UI Council list, there seemed to be some agreement that granting all applications the ability to install any package they want if they have TrustedUI is a mistake. Should the Symbian Signed test criteria restrict usages of the silent installer API to a package's dependent libraries and upgrades to the package?

[bbj]

Firstly, whilst we applaud the attempts at simplification, test cases are notoriously hard to write such there is no ambiguity. Easy the most frustrating part of the current tests is the test houses read the tests one way, developers another.
The following are a (no so) brief set of points following a reasonably quick read through of the latest pdf, trying not to duplicate others comments so far.

Test 02 -
---------------------
i) Says 'Start the application as per TEST 02. But this is Test02. It cant be refering to 01 as thats all about installation etc.


Test 03
-------
What constitutes an incoming call indication ?. E.g. for apps that are full screen is a 'ringing' sound sufficient or do all apps have to display visual components.

Given you dont tend to have audible call termination what is required for part 3?.

Part 5 explictily states UI - so presuambaly Audio is not acceptable ? - in which case what are full screen apps supposed to do so its consistent across ALL apps - else how is the user supposed to know whats going on.

Test 04
-------
Call / SMS testing.
This entirely depends on the network as well as apps + devices.
SMS in particualar is susceptable to significant network delays and uses a NON guaranteed delivery transport. Any test that assumes SMS will a) both go through the network in something close to acceptable time or b) ever gets to the remote phone is fundamentally flawed given the limitations of the transport. E.g. O2 in UK last week couldnt deliver SMS for about 6 hrs - so we get failed apps because of network delays = pretty unacceptable.

Test 05
-------
This assumes devices have the named apps included. As far as I am aware it is not mandatory for all Symbian devices to include such apps - so why is is reasonable to state you have to test these apps ?

- part 5
Again this fundamentally assumes that both the phone has been configured correctly and the network is operating - and is entirely outside the control of the very vast majority of applications. E.g. all data access on O2 was broken last week for several hours - so there is potential for the test to fail totally outside the control of the app itself - thus a dubious test criteria.
The point is the test criteria does not state that you have to have a working SIM, network connection etc - yes its all implied but the crash test dummies are not reasonably allowed to make assumptions.


Test 07
Please add a statement to the effect that it is entirely reasonable and appropriate for an application to display different amounts of information on different screen orientations. (And yes we have previously been failed because the testers seemed to think you have to display the exact same info on different layouts.)

Test 07
Stating that an application 'continues to be usable' is far too vague. One persons view of 'usable' is not the same as anothers. E.g. an application that does not rotate with the screen rotation is in our view unusable as you cant read the vertical text very easily, drive around a 90 degree rotated course. I am sure others will disagree with that statement - and thats the entire point - its subjective again.

Test 07
UI layout.
What about apps that are designed to support a range of devices, but not the entire range of possible scn sizes that have ever existed. E.g. apps support 240x320, 320x240 360x640, 640x360 BUT NOT 176x208 208x208, 352x416, 416x352 and 352x800 (effectively obsolete devices) - exactly what will the testers be doing here.

Test 07
We have never yet actually understood the drivers for this test criteria: (other than a rather misplaced view that this might reduce fragmentation - whereas in reality all it does is increase it!)
i) Practically all distribution sites do so by device and not by screen size - so its irrelevant as a test.
ii) Completely irrespective of this test, if you want to you can claim compatibility with other screen sizes on distribution sites - i.e. it has no value as a test as there is no mechanism to enforce the results.
iii) We have to support the end users so have strong disincentive not to claim compatibility with devices an app does not work properly on - so whats the point of the test - it has no value to us or consumers?.
iv) Most proper distrib sites test apps on devices anyway so its totally irrelevant whether this test has been passed or not, the app is tested again.
v) Different S60 devices with the same LCD size have different amounts of pixels available to apps. E.g. the 320x240 E60 has differnt number of pixels to a 320x240 E71 within the ApplicationRect(). Some applications cannot resize as easily as others + the 2 pixel difference in the above can make quite a bit of difference to the app. Given the test has nothing to do with the 'quality of the UI' presented exactly what is it attempting to acheive ?
vi) most of our support is associated with people that have gone out of their way to ignore any indication of device support from their chosen distribution channel and have attempted to install apps on unsupported devices. This test does not magically make apps support such devices or stop consumers totally ignoring any online 'compatibility lists' or indeed the 'This device is not supported' messages displayed on installation - they simply contact us. This test does not fix the distributor, consumer nor our support requirement so in our view its value is negligible at best.


Test 08
This appears to be about as unscientific as you can get.
E.g. Bus no 1 - the criteria presuppose that contacts, messages etc apps do not manipulate their stores to an extent that no difference of 10K occurs berteen the two pionts in time. (e.g. a background compress that frees spece or increases used space on flash)

Test 08 refers to Test 09 - which does not exist.

Why 10K, what is so magical about that. What if apps want to leave more than that. E.g. You have a database app. User adds 100K, 10MB whatever of records to their DB. They uninstall the app - e.g. because they want to install an upgrade. This test critera says app writers have to delete all their data. Pretty unfriendly for the user etc.

By definition, if you follow the steps in Test 01, you will have re-installed the app. Yes pedantict - but the crash test dummies simply follow instuctions to the letter....

Generally there appear to be significant areas open to interpretation and this is where the test criteria keep falling down. They have to be as watertight as possible so that all parties have a clear understanding of what is required in ALL scenarios. The trouble is this is very hard to achieve.

[bbj]

""Application does not attempt to install an older or incompatible version of 3rd-party packages""

Presumably what is incompatible for one app is not incompatible for another... otherwise they would presumably not actually be attempting to install it in the first place - as such its going to be practically impossible to enforce.

[bbj]

Component SIS files.

Currently the test criteria are a bit of a nightmare with component SIS files as the test houses basically (and not unreasonably) dont have much of a clue as to what functionality may be in a component SIS and what may be in the primary SIS. As such they land up testing incorrect things.

[aolammi]

Hi, I quite like the simplicity of the new Criteria. But I do have a worry with the TEST.08: In the previous version of the Criteria it was explicitly mentioned that after un-install it is allowed to leave some user generated files, such as downloaded files etc. This is really something I want to retain in my application, so that it can be uninstalled without removing the valuable user created files.

[brian_____]

Testing for "incompatible" might be unrealistic but checking for conditional installation based on the installed package can be automated. Think about the problem with components like QT that get distributed by many applications. If I am using v.1.1 of the QT release and my competitor only requires v1.0, a competitor could overwrite v1.1 with v1.0, making my application fail. There is the same problem with EUserHL. Or, if there is a security fix in QT or EUserHL or some other 3rd-party lib, then a seemingly-innocent application could install the old, vulnerable version over the fixed version, to re-enable exploits.

I heard that soon there will be a redistributable version of QT, which requires a newer version of OpenC. It is likely that the initial release of QT and/or the new OpenC will have bugs fixed in subsequent versions. So, package version management will be critical. This is something that isn't even checked even though it is much easier to get it wrong than to get it right.

[brian_____]

Check 02. The Platform UID specifies the range of target devices for the application. So, how can the Platform UID test ever fail? For the Vendor ID, shouldn't the requirement be more strict--that is, the Vendor ID must be the ID of the vendor making the submission? Similarly, since the vendor name from the PKG file is presented to the user during installation, the Vendor name has to be the same as the name from the Publisher ID. Otherwise, how can the user decide whether to trust the vendor? (I heard that this is one thing that the recently Symbian Signed malware did).

Check 03.3: Version number formatting caused some people problems when publishing to Ovi Store. I forget the specific problem, but it was something along the lines of the Ovi Store requiring the version number to be formatted differently in the About dialog than the way it is presented in the installer. So, the application could be forced to display the version number in two different ways (one in the installer, one in the About dialog), making CHECK 03.3 imposible to satisfy.

CHECK 03.4 What would cause an application to fail this check? AFAICT, you would have to describe a totally different application in order to fail the criteria.

TEST 01.2 Presumably "an icon" should be "one or more icons."

TEST 02.2
An application that somehow hides itself from the task list on receipt of an exit command (without exiting) would pass this test. IMO, if the user is closing an app from the task list then he probably realy wants the application to terminate, not just disappear from the task list.

TEST 03.4 says there must be a visual indication of a call when the application is in front. Is it the case that a visual indicator must remain on screen as long as a call is in progress? If there are multiple calls in progress (e.g. call waiting) then does that have to be visually indicated too?

TEST 07: Doesn't the second sentence in TEST 07.1 handle exemption 1? Isn't exception 2 handled by CHECK 02? Based on CHECK 02 I assume my applications will pass as long as they work on devices listed as compatible, even if they fail on other devices.

TEST 08: If the application installs third-party packages, what should happen with those packages at uninstallation time?

[marran]

Actually new criteria is very significant change in Symbian Sign.

But in general Symbian Sign should be more then just protect device from malware.

You need look at Apple Store (iPhone) and look at OVI. How can OVI protect full version with DRM from warez destribution?

Just try copy-paste-improve Apple store to Symbian Sign - OVI and you will earn some more money and allow to earn some money for us (3rd party shareware developers).

Good luck!

[killermobile]

Originally Posted by danm

I agree. That's why all testing of "meeting user expectations" is removed from the latest draft of the Test Criteria. The quoted text in the earlier comment was taken from the old test criteria rather than the new proposal.

This is probably the best news I've heard in a while! It was ridiculous how test houses essentially used this test case to try and dictate what they deemed to be our user's expectations. I think normal market conditions do a good job of this already. If our apps are buggy and don't work, then clearly the application won't be downloaded, installed and used. Not to mention if they put any Nokia device against these Test Criteria many devices would never see the light of day.

I do agree that a simple exception to the Task List compliance needs to be kept. We held out for an eternity before caving in to the demands of our users and setting up the application to not be closed down every time they pressed the hangup key. No user would expect/want this, and since it's already required that you have an EXIT option in the application, it's redundant. Perhaps just make this test case a bit clearer. "The user must be able to access the application from the task list or the installed applications folder (an either/or scenario), open the application UI and exit the application". That's the point of this test case anyways.

Cheers!

Josh

[killermobile]

Will there be exceptions for Tests 3 and 4? Any call management or "Filtering" type application woud clearly fail these tests.

Cheers!

JOsh

[danm]

Originally Posted by killermobile

Will there be exceptions for Tests 3 and 4? Any call management or "Filtering" type application woud clearly fail these tests.

The current thinking is that you would have to file a waiver at submission time for such apps.

How common are such applications? I have not seen many come through Symbian Signed at all...

[tony]

Originally Posted by danm

The current thinking is that you would have to file a waiver at submission time for such apps.
How common are such applications? I have not seen many come through Symbian Signed at all...

At Webgate we have a lot of call/SMS managing apps (http://www.webgate.bg/products/). Our products are very popular and we have more than 300 builds for different partners and channels. Every build is Symbian Signed. If we have to file a waiver at each submission then you will make the process really painful for us.

[danm]

Originally Posted by tony

At Webgate we have a lot of call/SMS managing apps (http://www.webgate.bg/products/). Our products are very popular and we have more than 300 builds for different partners and channels. Every build is Symbian Signed. If we have to file a waiver at each submission then you will make the process really painful for us.

We're also working on the waiver process currently, so hopefully we could make the process of applying for (and getting a decision on) a waiver much simpler than it is currently.

Whilst you are producing applications which genuinely need to interfere with voice calls and text messages to function, we do need to ensure that someone doesn't submit an application which prevents the user from making voice calls.

We could return to saying "if the purpose of the application is to deal with voice calls, then this test does not apply" but then we get back to the problem of the tests being subjective, which is one of the greatest complaints with the test criteria as they stand today...

Would making the waiver application process very simple help you out?

[danm]

A lot of good comments there - a few comments from me...

Originally Posted by bbj

This assumes devices have the named apps included. As far as I am aware it is not mandatory for all Symbian devices to include such apps - so why is is reasonable to state you have to test these apps ?

You're right. A device could be made which doesn't have one or more of these apps. If your application was designed for (and only installed on) such devices then you wouldn't have to pass the test. We could maybe tidy up the wording of that, though, I agree.

Originally Posted by bbj

The point is the test criteria does not state that you have to have a working SIM, network connection etc - yes its all implied but the crash test dummies are not reasonably allowed to make assumptions.

In section 1.6, we mention what you'll need to run the tests. Do you think we should include some more on SIM cards and devices in there?

Originally Posted by bbj

Please add a statement to the effect that it is entirely reasonable and appropriate for an application to display different amounts of information on different screen orientations. (And yes we have previously been failed because the testers seemed to think you have to display the exact same info on different layouts.)
(SNIPPED following comments on UI layout testing)

This is a very good point, and gets to the heart of one of the biggest problems with the test criteria. The Scalable UI test is, probably, the least popular test in the current criteria.

What we have tried to do is revise the UI layout testing to remove the ability to fail because of a slight layout problem.

Personally speaking, I don't think an application should fail on the basis of drawing problems - that'll just lead to the application getting bad reviews and market forces will drive the developer to do something about it - but we have seen applications which freeze if the screen orientation is changed, and that should be a failure I think.

Do you have any suggestions for how we can word the tests more clearly?

Originally Posted by bbj

Why 10K, what is so magical about that.

There's nothing magical about 10K. We're interested to hear what kind of information developers like to leave behind on the device. We're happy to move that figure up or down based on the feedback from developers.

Bear in mind that the user is quite often uninstalling the application because they want to free up some space on their device. If the app leaves all its data behind, then is it reasonable to expect the user to launch a file manager and go and clear that data up manually?

We need to set a limit on the amount of data which can be left behind after uninstall, but we do need to leave room for the application to do things such as leave a key behind to enforce a trial period, for instance.

Of course, in the rare case that you need to leave more data behind, you can submit a waiver request - which will be easier to do with the new process!

Originally Posted by bbj

By definition, if you follow the steps in Test 01, you will have re-installed the app. Yes pedantict - but the crash test dummies simply follow instuctions to the letter....

That's a good point. I shall look at shuffling around the order of the testing in the next draft to remove that problem. I've tried to make the test criteria flow as easily as possible, so that the end state of one test leads nicely into the initial state of the next. Thanks for spotting that!

Originally Posted by bbj

Generally there appear to be significant areas open to interpretation and this is where the test criteria keep falling down. They have to be as watertight as possible so that all parties have a clear understanding of what is required in ALL scenarios. The trouble is this is very hard to achieve.

You're absolutely right. We have to strike the balance between making the tests tight enough but without limiting the ability of developers to write interesting and novel applications.

[danm]

Originally Posted by brian_____

CHECK 03.4 What would cause an application to fail this check? AFAICT, you would have to describe a totally different application in order to fail the criteria.

Yes - believe it or not - it does happen. We do get applications submitted with a description which says "just install this app".

Currently, there's nothing in the test criteria which means this would fail - but I think it's reasonable to ask the developer to provide an accurate one/two sentence description of their application during submission...

Originally Posted by brian_____

TEST 08: If the application installs third-party packages, what should happen with those packages at uninstallation time?

That is a very interesting question.

Personally, I would be happy for the third party packages to remain, so long as they themselves we uninstallable afterwards.

Do you have any thoughts on this yourself?

[tony]

Originally Posted by danm

Would making the waiver application process very simple help you out?

An example is when we make an upgrade. We build 10+ builds for different partners and channels. As I said every build is Symbian Signed. Currently it is ok because we use Express Signed procedure. I am afraid that raising a waiver for each submission will slow down dramatically the process and will increase our cost.

Originally Posted by danm

We could return to saying "if the purpose of the application is to deal with voice calls, then this test does not apply" but then we get back to the problem of the tests being subjective, which is one of the greatest complaints with the test criteria as they stand today...

I believe the best solution is to define text good enough to escape subjectiveness.

[simonpope]

Having just read the draft doc I have some comments: -

Apps should not be tested across all devices but the developer MUST be able to say what devices / S60 version their application should be tested against. This shouldn't be determined by the signing house or the foundation. In my view. :-)

I have only skimmed through the document but I am assuming there will be no need to state which capabilities will be used by a particular application. Please can this be clarified.

The Test Houses need to be consistent and made fully aware of the test criteria and the changes. Particularly around voip applications they have been inconsistent with what they pass and fail. The section on making a successful call should help to make this clearer.

Generally looks like a big improvement.

The only other change I would like to see eventually is alignment between this Test Criteria and the Ovi Store QA mysterious test process. Having the two processes with different criteria just deters developers away from Symbian. Blackberry and Apple do not have this issue.

thanks

[bbj]

Originally Posted by danm

In section 1.6, we mention what you'll need to run the tests. Do you think we should include some more on SIM cards and devices in there?

Depends on who you think is going to be using the test script. Without specifying the environment 100% there is scope for testers to go wrong. Clearly common sense suggests that you have working phones SIMS etc, but unfortunately we have been badly bitten by Symbian Signed so many times over the past 5 yrs or so that without nailing down everything 100% its a big hole in the test spec.

Originally Posted by danm

This is a very good point, and gets to the heart of one of the biggest problems with the test criteria. The Scalable UI test is, probably, the least popular test in the current criteria.

What we have tried to do is revise the UI layout testing to remove the ability to fail because of a slight layout problem.

Personally speaking, I don't think an application should fail on the basis of drawing problems - that'll just lead to the application getting bad reviews and market forces will drive the developer to do something about it - but we have seen applications which freeze if the screen orientation is changed, and that should be a failure I think.

Do you have any suggestions for how we can word the tests more clearly?

As suggested, we are very unclear on the validty/value of the test at all to anyone. From your comment above, why exactly is an app failure at scn orientation change any more or less severe than application failure at any other point - e.g. Camera being used by app 1 and app 2 crashes is just one example of literally 100s we can think of very quickly. If you are going to have tests that attempt to measure a level of quality in the UI, then you need a full suite of tests that cover pretty much all scenarios. If you are not attempting to generate such a measure then there is little/no value in picking on a single failure simply because some apps in the past freeze on one particular test.

Originally Posted by danm

There's nothing magical about 10K. We're interested to hear what kind of information developers like to leave behind on the device. We're happy to move that figure up or down based on the feedback from developers.

Bear in mind that the user is quite often uninstalling the application because they want to free up some space on their device. If the app leaves all its data behind, then is it reasonable to expect the user to launch a file manager and go and clear that data up manually?

We need to set a limit on the amount of data which can be left behind after uninstall, but we do need to leave room for the application to do things such as leave a key behind to enforce a trial period, for instance.

Of course, in the rare case that you need to leave more data behind, you can submit a waiver request - which will be easier to do with the new process!

I believe a previous requirement for apps that have lots of associated user data was to have an uninstall option of removing app only or app and data. Perhaps thats the way to go.
Anything that requires the use of a File Manager is not acceptable in our view, not least of which built in FM cant view app private folders.

Still unclear on why there is a need to set a limit. What exactly is it attempting to achieve ? If apps can get waivers to allow more than arbitary chosen limit behind then the limit is effectively redundant. In which case why have it in the first place. And anyway its entirely trivial to get around this type of test if required. All its doing is adding another hoop for well behaved apps.

In another post it is suggested that its reasonable for 3rd party libraries to remain installed on a device after app that used them is uninstalled. Why is it reasonable for 3rd party librairies (binary data) to remain on device yet app level binary data have an arbitary limit imposed ? - both are occupying space. Any suggestion that a normal user whould know that they goto the App Manager and choose 'Uninstall blah 3rd party add on originally installed with App XXX' has to be wrong.

[bbj]

Express Signed apps should have the ability to specify which test house is to be used:
i) any
ii) very specific one

should the app be chosen to be audited.

Certain companies/tech has restrictions on who they are prepared to deal with/territories they allowed to deal with - either politically or technical reasons can be behind this.

[aolammi]

danm, any comment on my earlier point about TEST.08 and data files left behind un-installation?

[asheesh]

Is the test criteria for Symbian Signing and Symbian Certification different? If not, the testing is very basic, eg no stress testing is being done. If yes, what are the test criteria for Symbain Certification?

[danm]

Originally Posted by asheesh

Is the test criteria for Symbian Signing and Symbian Certification different? If not, the testing is very basic, eg no stress testing is being done. If yes, what are the test criteria for Symbain Certification?

These are the proposed tests for both Express Signed and Certified Signed.

We think it'd be confusing for developers to have a different set of criteria for each of the signing options...