Revise dangerous restrictions

[M66B]

There is too much confusion about dangerous restrictions.
For this reason I will remove the associated setting and simplify most of the logic.
Basically only restricting categories will not restrict dangerous functions.
(this needs to be done manually case by case).
The template will restrict dangerous functions in the new situation, when selected in the template.

[M66B]

Remaining logic for system applications:

• Display reddish background
• Filter on system applications

Remaining logic for dangerous methods:

• Display reddish background
• Set dangerous function not restricted when restricting category (also when restricting category using on demand restricting, but only if category restriction changes to deny)
• Migration of legacy XML settings files
• Dangerous functions will not be selected when selecting the category in the template (unless the function was (un)selected before)
• Default to unrestricted for dangerous function restrictions which were never set (compatibility)
• Set newly added dangerous functions as not restricted (update service)
• Always export dangerous function restrictions (compatibility)

[M66B]

There is a problem reported in the test version: if you had enabled 'restrict dangerous' before, all functions were restricted by default. If you never have change the dangerous function restrictions, all dangerous functions will be not restricted in the test version.

[M66B]

Existing dangerous restriction will be migrated, so please check if everything is alright after the update service has done its work.

[an0n981]

I had the same issue we discussed yesterday. But it didn't look like it affected every app this time. Would a log of the update process be of any help?

[M66B]

You can easily check the logcat yourself.

Basically dangerous function restrictions which are unset (and formerly defaulted to restricted when 'restrict dangerous' was enabled) and have the category restricted are set to restricted by the upgrade process. Each change is written to the logcat, so you can easily check with the uid of the application if the migration was done.

Before the upgrade process the old 'restrict dangerous' setting is used to provide the old default. After the upgrade process the 'restrict dangerous' setting is erased.

[an0n981]

Found a bug in the template when a new app is installed. For non dangerous the template applies [ ] [?] for dangerous [ ] [ ] regardless of what the template has. If I then manually apply the template everything works

[M66B]

Actually the template wasn't applied at all, which should be fixed in the just released 2.0.29 test version (I have no time to test, since I have to go).

[an0n981]

It is properly applied now

[an0n981]

However, now there is a problem when importing, only 'dangerous methods' are applied from the xml, even if I define them as not dangerous in the template. Also when I manually uncheck then check a category none of the methods are restricted (this may have already been present)

[M66B]

The UI has the same problem. Unfortunately I cannot fix this right away.