[Android Software/Hacking General [Developers Only]] pjc21:
Ok I believe I have found a bug/glitch in aroma with using the "writetmpfile" command.

I was trying to setup my theme mod so that it will auto-detect weather the rom installed is DEODEX or ODEX and not having used the writetmpfile command before had some issues getting the correct syntax to start with, got some help here and got it to work correctly about half the time as you will see below.

In aroma-config I have if statement like so:

if
file_getprop("/system/build.prop", "ro.build.display.id") == "TF300 CROMi-Xenogenesis 4.4 - 10.6.1.14.4/WW DEODEX" ||
file_getprop("/system/build.prop", "ro.build.display.id") == "TF300 CROMi-Xenogenesis 4.4 - 10.6.1.14.4/US DEODEX" ||
file_getprop("/system/build.prop", "ro.build.display.id") == "TF700 CROMi-Xenogenesis 4.4 - 10.6.1.14.4/WW DEODEX" ||
file_getprop("/system/build.prop", "ro.build.display.id") == "TF700 CROMi-Xenogenesis 4.4 - 10.6.1.14.4/US DEODEX"
then
writetmpfile("type.prop", "TYPE=DEODEX");
endif;

if
file_getprop("/system/build.prop", "ro.build.display.id") == "TF300 CROMi-Xenogenesis 4.4 - 10.6.1.14.4/WW ODEX" ||
file_getprop("/system/build.prop", "ro.build.display.id") == "TF300 CROMi-Xenogenesis 4.4 - 10.6.1.14.4/US ODEX" ||
file_getprop("/system/build.prop", "ro.build.display.id") == "TF700 CROMi-Xenogenesis 4.4 - 10.6.1.14.4/WW ODEX" ||
file_getprop("/system/build.prop", "ro.build.display.id") == "TF700 CROMi-Xenogenesis 4.4 - 10.6.1.14.4/US ODEX"
then
writetmpfile("type.prop", "TYPE=ODEX");
endif;

and in the updater-script:

#################### ROM TYPE ############################

ui_print("Detecting Rom Type");

if
file_getprop("/tmp/aroma-data/type.prop","TYPE") == "DEODEX"
then
ui_print("DEODEX Detected...");
endif;

if
file_getprop("/tmp/aroma-data/type.prop","TYPE") == "ODEX"
then
ui_print("ODEX Detected...");
endif;

set_progress(0.10);
################### SYSTEM TYPE & COLOR ################################

ui_print("System Type & Color");

if
file_getprop("/tmp/aroma-data/system.prop","selected.0") == "1" && file_getprop("/tmp/aroma-data/systembar.prop","selected.0") == "1" && file_getprop("/tmp/aroma-data/type.prop","TYPE") == "DEODEX"
then
ui_print(" - Blue - Stock");
package_extract_dir("SystemUIs/DEODEX/Blue/Stock", "/system");
endif;

if
file_getprop("/tmp/aroma-data/system.prop","selected.0") == "1" && file_getprop("/tmp/aroma-data/systembar.prop","selected.0") == "1" && file_getprop("/tmp/aroma-data/type.prop","TYPE") == "ODEX"
then
ui_print(" - Blue - Stock");
package_extract_dir("SystemUIs/ODEX/Blue/Stock", "/system");
endif;

The first time I tried this I got the following error in the updater-script:

so I changed the type.prop path in updater-script to "/tmp/aroma/type.prop" and it worked fine, no errors

the second time i tried I then got error:

tried again and it was fine - I have tested about 10 times now and each time it changes where the type.prop is created between the two paths :confused:

so 1st time type.prop is created in /tmp/aroma

2nd time in /tmp/aroma-data

3rd time in /tmp/aroma

4th time in /tmp/aroma-data

5th time in /tmp/aroma

and so forth

I think (but have not tried yet) I can get get around this with something like below to include both paths but just wanted to know if there was a solution to this issue/bug?

if
file_getprop("/tmp/aroma-data/type.prop","TYPE") == "DEODEX" || file_getprop("/tmp/aroma/type.prop","TYPE") == "DEODEX"
then
ui_print("DEODEX Detected...");
endif;

Thanks

Paul.