red frame border disabled

[nikomweb]

no more red border after apllied my fix: in build.prop change

ro.build.type=eng
ro.build.user=xxxxx

to

ro.build.type=user
ro.build.user=root

and compile

info from http://forum.tegraowners.com

[Lu Patrick]

Thanks for sharing it!

I'll try it when I get home.

Patrick

[Alvin Wong]

I thought `ro.build.user` only specifies the user who built the
Android rootfs.

[Ooop Yooo]

In fact the correct ICS setting is almost the same as the one for Honeycomb with little change. lol ;)

2012/2/23 Alvin Wong <alvin...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-x86...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-x86?hl=en.

[Christopher Hrabia]

Could you explain that? In honeycomb I was able to disable the red frame border with the system.prop entry persist.sys.strictmode.visual=0, but this is not working with ics.

Thank you!

2012/2/23 Ooop Yooo <ooop...@gmail.com>

--
Mit freundlichen Grüßen

Christopher Hrabia

(c.hr...@gmail.com)

[StefanS]

You don't need to set ro.build.user.
But otherwise, I can confirm that changing the build type from "eng" (=engineering) to "user" (=end user) does remove the red border issue.

Stefan

[Robill Tian Supatrio]

Hi,

it seems there is a problem with build type "user". I have tried that in order to get rid of red border flashing,

but end up getting NO audio instead (it indeed got rid of the red border though). Then I noticed Chih-Wei

RC1 build is using "userdebug" type, I did the same, and voila, audio is working again. No idea what the

difference between them though.

regards,

Robill

--

You received this message because you are subscribed to the Google Groups "Android-x86" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/amh8QI7CCFQJ.

[Ooop Yooo]

Here are the correct settings to disable the Red Frame Border :

persist.sys.strictmode.visual=0

persist.sys.strictmode.disable=1

To be added to your system.prop file. :P

May be the first one can be ommited, but haven't got time to test only with the second setting, due to my slow laptop.

But both settings won't harm your build anyway and this is 100% working. lol

2012/3/1 Christopher Hrabia <c.hr...@gmail.com>

[Hoàng Tùng]

Only visit /system 

Edit build.prop and edit

> ro.build.type=eng

 to
> ro.build.type=user

Red Frame Boder is remove. ( Test with android-brazos)

[Ooop Yooo]

Why do you want to change official frameworks codes when adding a simple line in custom target system.prop or build.prop will do the job ???

2012/3/8 tabletsx86 <rbg.tab...@gmail.com>

possible solution?:

At frameworks/base
diff --git a/core/java/android/os/StrictMode.java b/core/java/android/
os/StrictM
index 4d7a9bb..cc98e69 100644
--- a/core/java/android/os/StrictMode.java
+++ b/core/java/android/os/StrictMode.java
@@ -113,7 +113,8 @@ public final class StrictMode {
    private static final String TAG = "StrictMode";
    private static final boolean LOG_V = Log.isLoggable(TAG,
Log.VERBOSE);

-    private static final boolean IS_USER_BUILD =
"user".equals(Build.TYPE);
+    //private static final boolean IS_USER_BUILD =
"user".equals(Build.TYPE);
+    private static final boolean IS_USER_BUILD = true;
    private static final boolean IS_ENG_BUILD =
"eng".equals(Build.TYPE);

    /**

from:
http://groups.google.com/group/android-platform/browse_thread/thread/9493f311b743c86a/c8daa45e17fa2663?hl=en&lnk=gst&q=strictmode#c8daa45e17fa2663

On Mar 1, 5:17 am, Robill Tian Supatrio <rsupat...@gmail.com> wrote:
> Hi,
>
> it seems there is a problem with build type "user". I have tried that in
> order to get rid of red border flashing,
> but end up getting NO audio instead (it indeed got rid of the red border
> though). Then I noticed Chih-Wei
> RC1 build is using "userdebug" type, I did the same, and voila, audio is
> working again. No idea what the
> difference between them though.
>
> regards,
>
> Robill
>
>
>
>
>
>
>

> On Thu, Mar 1, 2012 at 5:51 PM, StefanS <andr...@stefanseidel.info> wrote:
> > You don't need to set ro.build.user.
> > But otherwise, I can confirm that changing the build type from "eng"
> > (=engineering) to "user" (=end user) does remove the red border issue.
>
> > Stefan
>
> > On Wednesday, February 22, 2012 8:27:25 PM UTC+1, nikomweb wrote:
>
> >> no more red border after apllied my fix: in build.prop change
>
> >> ro.build.type=eng
> >> ro.build.user=xxxxx
>
> >> to
>
> >> ro.build.type=user
> >> ro.build.user=root
>
> >> and compile
>

> >> info fromhttp://forum.tegraowners.com

[StefanS]

On Thu, Mar 8, 2012 at 22:10, Ooop Yooo <ooop...@gmail.com> wrote:
> Why do you want to change official frameworks codes when adding a simple
> line in custom target system.prop or build.prop will do the job ???

Yes, I have the same opinion!
But I think there might be an official problem with "StrictMode"
anyway, because even if you set the official property to disable the
visual feedback (red flashing border), it will not disable it. But it
should be addressed with the AOSP gerrit.

Stefan

[StefanS]

On Thu, Mar 8, 2012 at 22:31, tabletsx86 <rbg.tab...@gmail.com> wrote:
> was just pointing there are other issues with strictmode...
>
> adding a simple line to system.prop or build.prop is not really a
> solution, it's a bandaid IMO
> as strictmode is only a developer tool and should not be set in final
> user releases...
And it isn't! I always set my build type to "user", Chih-Wei uses
"userdebug". Both work and do not have the red frame border problem
(although I have to disable ProGuard to build "user").
If you repo sync and make, your build type will be "eng"
(engineering), so it's perfectly valid to have strict mode visual
indicator there.

Stefan

>
> should it be set for RC1/RC2...??? I personally don't feel it should
> be....

>
> On Mar 8, 4:10 pm, Ooop Yooo <ooop4...@gmail.com> wrote:
>> Why do you want to change official frameworks codes when adding a simple
>> line in custom target system.prop or build.prop will do the job ???
>>

>> 2012/3/8 tabletsx86 <rbg.tablets...@gmail.com>

>>
>>
>>
>>
>>
>>
>>
>> > possible solution?:
>>
>> > At frameworks/base
>> > diff --git a/core/java/android/os/StrictMode.java b/core/java/android/
>> > os/StrictM
>> > index 4d7a9bb..cc98e69 100644
>> > --- a/core/java/android/os/StrictMode.java
>> > +++ b/core/java/android/os/StrictMode.java
>> > @@ -113,7 +113,8 @@ public final class StrictMode {
>> >     private static final String TAG = "StrictMode";
>> >     private static final boolean LOG_V = Log.isLoggable(TAG,
>> > Log.VERBOSE);
>>
>> > -    private static final boolean IS_USER_BUILD =
>> > "user".equals(Build.TYPE);
>> > +    //private static final boolean IS_USER_BUILD =
>> > "user".equals(Build.TYPE);
>> > +    private static final boolean IS_USER_BUILD = true;
>> >     private static final boolean IS_ENG_BUILD =
>> > "eng".equals(Build.TYPE);
>>
>> >     /**
>>
>> > from:
>>

>> >http://groups.google.com/group/android-platform/browse_thread/thread/...

[Ooop Yooo]

Don't know how you used the property, but this is working for me and also with Christopher Hrabia new ICS build ?!?!?!

I'm not using build.prop, so can't say how it works, but only system.prop.

Have you made the change without rebuilding or partially rebuilding ?

Since this is related with frameworks, you have to remove the out folder completely and rebuild from new.

Or you may have an issue with ccache... ^^

2012/3/8 StefanS <and...@stefanseidel.info>

[StefanS]

On Thu, Mar 8, 2012 at 22:40, Ooop Yooo <ooop...@gmail.com> wrote:
> Don't know how you used the property, but this is working for me and also
> with Christopher Hrabia new ICS build ?!?!?!

Sorry if this wasn't clear: I was talking about that
persist.sys.strictmode.visual=0
is not working. ro.build.type=user is working.

Stefan

[Ooop Yooo]

Ok, but as I mentioned in one of my previous post : there were 2 properties to be used in system.prop.

I suggested to test if the second one was enough, and if it's not working that means you have to use both of them.

I always used both as there was no problem doing so... ^^

I guess Christopher did the same as he told me this was working.

[jacksp]

Hi guys, i just followed your suggestions and edited build.prop but i did it just after i installed android, not before build, and it works as well.

Just wanted to let you know since it saves a lot of time.

Cheers

[Ooop Yooo]

Back again on the properties,

I retreaved my above mentioned post :

"persist.sys.strictmode.visual=0

persist.sys.strictmode.disable=1

To be added to your system.prop file. :P

May be the first one can be ommited, but haven't got time to test only with the second setting, due to my slow laptop.

But both settings won't harm your build anyway and this is 100% working. lol"

Now to clarify both : the first property : persist.sys.strictmode.visual=0 -> this one comes from Honeycomb.

The second one :                               persist.sys.strictmode.disable=1 -> is the one I found out and specifically for ICS !!!

So if you indeed use : persist.sys.strictmode.visual=0 with ICS, this definitely won't work !

I thought the first one was well known to be used with Honeycomb to disable Red Frame Border (but sounds like this is not the case). ;-)

Hope I've been clear now... :P

So you've got 2 for the same price. lol

[Ooop Yooo]

There are many roads to Rome... :-)))))

2012/3/9 jacksp <theha...@gmail.com>

Hi guys, i just followed your suggestions and edited build.prop but i did it just after i installed android, not before build, and it works as well.

Just wanted to let you know since it saves a lot of time.

Cheers

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/6C-Zny4CcKkJ.

[StefanS]

Yes, I know that user build fails. That's why I wrote about disabling ProGuard, I think that made it work.

Stefan

On Mar 14, 2012 9:51 PM, "tabletsx86" <rbg.tab...@gmail.com> wrote:

as a side note to your comment about user & userdebug...

have also observed the following...

mk newdir
cd  newdir

init & repo sync ics-x86

build any flavor with target_build_varient = user and the build will
fail...
(haven't tried your "disable ProGuard ")

change target_build_varient = userdebug and it builds fine...

??? haven't checked the audio failing yet...

the little inconsistencies must drive Chih-Wei and other developers
crazy...LOL



On Mar 8, 5:38 pm, StefanS <andr...@stefanseidel.info> wrote:

> > For more options, visit this group athttp://groups.google.com/group/android-x86?hl=en.

[Robill Tian Supatrio]

with s103t target it does NOT fail. I did the following to build:

> source build/envsetup.sh

> choosecombo release s103t user

> make -j8 iso_img

it compiles fine, but when I install the resulting ISO, I have 'no audio' issue. Logcats, kernel logs shows nothing

suspicious. No clue and no motivation to find out why since 'userdebug' works :)

Robill

[StefanS]

you need to exclicitely include alsa_amixer in your PRODUCT_PACKAGES.

Stefan

[Robill Tian Supatrio]

Ahh, that explains it! Thanks Stefan!

LOCAL_MODULE_TAGS := debug

LOCAL_MODULE := alsa_amixer

everything under external/alsa-util is tagged with 'debug', therefore they will not be built if

tag is 'user' only. I think for alsa-util it should be 'optional', shouldn't it? Since they are

really necessary for audio? I know 'optional' sounds incorrect, but it is the tag

for necessary modules (I don't know why android team describe it as optional though :) )

One mystery solved.

regards,

Robill

[StefanS]

On Thu, Mar 15, 2012 at 15:09, tabletsx86 <rbg.tab...@gmail.com> wrote:
> http://groups.google.com/group/android-x86/browse_thread/thread/1e82e2b8a6a5eaac/2dc278b39e287fe8?lnk=gst&q=PRODUCT_PACKAGES#2dc278b39e287fe8

No idea what you're trying to say.

Stefan

>
>
> On Mar 15, 6:11 am, Robill Tian Supatrio <rsupat...@gmail.com> wrote:
>> Ahh, that explains it! Thanks Stefan!
>>
>> LOCAL_MODULE_TAGS := debug
>> LOCAL_MODULE := alsa_amixer
>>
>> everything under external/alsa-util is tagged with 'debug', therefore they
>> will not be built if
>> tag is 'user' only. I think for alsa-util it should be 'optional',
>> shouldn't it? Since they are
>> really necessary for audio? I know 'optional' sounds incorrect, but it is
>> the tag
>> for necessary modules (I don't know why android team describe it as
>> optional though :) )
>>
>> One mystery solved.
>>
>> regards,
>>
>> Robill
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 15, 2012 at 5:52 PM, StefanS <andr...@stefanseidel.info> wrote:
>> > you need to exclicitely include alsa_amixer in your PRODUCT_PACKAGES.
>>
>> > Stefan
>>

>> > On Thu, Mar 15, 2012 at 10:31, Robill Tian Supatrio <rsupat...@gmail.com>

>> > wrote:
>> > > with s103t target it does NOT fail. I did the following to build:
>> > >> source build/envsetup.sh
>> > >> choosecombo release s103t user
>> > >> make -j8 iso_img
>>
>> > > it compiles fine, but when I install the resulting ISO, I have 'no audio'
>> > > issue. Logcats, kernel logs shows nothing
>> > > suspicious. No clue and no motivation to find out why since 'userdebug'
>> > > works :)
>>
>> > > Robill
>>

>> > > On Thu, Mar 15, 2012 at 5:51 AM, StefanS <andr...@stefanseidel.info>

>> > wrote:
>>
>> > >> Yes, I know that user build fails. That's why I wrote about disabling
>> > >> ProGuard, I think that made it work.
>>
>> > >> Stefan
>>

[Robill Tian Supatrio]

That was the basic instruction long time ago. No mentioning about explicit defining PRODUCT_PACKAGE +=
alsa_amixer. I saw alsa_amixer was mentioned several times, but didn't think it was necessary for the audio
to function correctly, until now. Anyway, if it is really necessary, putting it in PRODUCT_PACKAGE seems like a workaround to me if you are building with 'user' type. Specifying LOCAL_MODULE_TAGS := optional should be
the correct way. This will prevent 'no audio' issue to happen in any target.

Robill

On Thu, Mar 15, 2012 at 10:36 PM, tabletsx86 <rbg.tab...@gmail.com> wrote:

pointer to thread where Chih-Wei explains what Stefan refered to:

http://groups.google.com/group/android-x86/browse_thread/thread/1e82e2b8a6a5eaac/2dc278b39e287fe8?lnk=gst&q=PRODUCT_PACKAGES#2dc278b39e287fe8

On Mar 15, 6:11 am, Robill Tian Supatrio <rsupat...@gmail.com> wrote:
> Ahh, that explains it! Thanks Stefan!
>
> LOCAL_MODULE_TAGS := debug
> LOCAL_MODULE := alsa_amixer
>
> everything under external/alsa-util is tagged with 'debug', therefore they
> will not be built if
> tag is 'user' only. I think for alsa-util it should be 'optional',
> shouldn't it? Since they are
> really necessary for audio? I know 'optional' sounds incorrect, but it is
> the tag
> for necessary modules (I don't know why android team describe it as
> optional though :) )
>
> One mystery solved.
>
> regards,
>
> Robill
>
>
>
>
>
>
>

> On Thu, Mar 15, 2012 at 5:52 PM, StefanS <andr...@stefanseidel.info> wrote:
> > you need to exclicitely include alsa_amixer in your PRODUCT_PACKAGES.
>
> > Stefan
>

> > On Thu, Mar 15, 2012 at 10:31, Robill Tian Supatrio <rsupat...@gmail.com>

> > wrote:
> > > with s103t target it does NOT fail. I did the following to build:
> > >> source build/envsetup.sh
> > >> choosecombo release s103t user
> > >> make -j8 iso_img
>
> > > it compiles fine, but when I install the resulting ISO, I have 'no audio'
> > > issue. Logcats, kernel logs shows nothing
> > > suspicious. No clue and no motivation to find out why since 'userdebug'
> > > works :)
>
> > > Robill
>

> > > On Thu, Mar 15, 2012 at 5:51 AM, StefanS <andr...@stefanseidel.info>

> > wrote:
>
> > >> Yes, I know that user build fails. That's why I wrote about disabling
> > >> ProGuard, I think that made it work.
>
> > >> Stefan
>

[Chih-Wei Huang]

2012/3/16 tabletsx86 <rbg.tab...@gmail.com>:
> did you read the full post???

Hi tabletsx86,
I think you are sincere.
But if you don't really understand the problem,
please don't provide misleading info.

What Robill talked is a real problem for user mode.
Nothing to do with the post you mentioned.

I think WindRiver set alsa-utils to debug on purpose
(alsa porting was first developed by WindRiver)
since phone doesn't need that -- it's only for debugging.
However, it's seems to be necessary for some x86 chips/boards.
So yes, the right solution is set them to be optional.
I'll correct them.

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[venky6 babu]

On Fri, Mar 2, 2012 at 9:35 PM, Hoàng Tùng <hoangt...@gmail.com> wrote:

Only visit /system 

Edit build.prop and edit

> ro.build.type=eng

 to
> ro.build.type=user

Thanks for your info.. Great to solve red frame boarders.
Cani know exact reason behind  engineering and user modes.....

Thanks,
Venky.