Re: [android-developers] Camera preview sizes on Galaxy Nexus (ICS)

[Alex Cohn]

On Monday, May 28, 2012 1:48:35 PM UTC+3, Mark Murphy (a Commons Guy) wrote:
>
> On Mon, May 28, 2012 at 2:39 AM, Alex Cohn wrote: 
> > but also exposes a problem with the 
> > Camera API of Android: there is no way for Camera.setParameters() to 
> fail or 
> > report anything about parameters inconsistency. 
>
> This is due to backwards compatibility, because 
> getSupportedPreviewSizes() is relatively new, so developers were 
> welcome to pass in whatever values they want. 
>
> -- 
> Mark Murphy (a Commons Guy) 
> http://commonsware.com | http://github.com/commonsguy 
> http://commonsware.com/blog | http://twitter.com/commonsguy 
>
> Android Training...At Your Office: http://commonsware.com/training 
>

I cannot agree with you, Mark.

This walks and quacks like a bug specific to Galaxy Nexus. See 
https://code.google.com/p/android/issues/detail?id=24563 for a related 
problem. 

In the nutshell, camera may throw a runtime exception if set previewSize is 
not correct. But in this device, the list of "supported" sizes is simply 
incorrect, and in some cases setParameters() results in an exception, but 
sometimes it pretends to accept the new value. Unfortunately, there is no 
direct way to find that this was "just for show".

When used with setPreviewCallback(), you can see that the size of preview 
buffer does not match expected width*height*3/2.
When used with setPreviewCallbackWithBuffer(), you get buffer == null.

BR,
Alex Cohn

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

[android-developers] Re: camera preview formats and sizes

[Alex Cohn]

Actually, I found a post 
http://code.google.com/p/zxing/issues/detail?id=343 that mentions that at 
least some Sciphone devices support the RGB565 format. Unfortunately, I can 
derive from this discussion that these devices cannot be trusted.

BR,
Alex

On Monday, May 28, 2012 9:19:30 AM UTC+3, Alex Cohn wrote:
>
> I have not seen single Android device to support rgb preview format. On 
> the other hand, what is the scenario that you cannot convert the yuv 
> preview frames to rgb?
>
> Sincerely,
> Alex
>
> On Monday, May 21, 2012 2:41:48 AM UTC+3, Marco wrote:
>>
>> hello, 
>> i would need to process camera preview frames of high quality in 
>> android. 
>> Is there a list of devices which are capable of using the 
>> ImageFormat.RGB_565 camera preview format? 
>>
>> i would need to know supported preview formats and supported preview 
>> size before buying the device... (i can't use the YUV420 format, i 
>> need color information of the frame)
>
>

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

[android-developers] Camera preview sizes on Galaxy Nexus (ICS)

[Alex Cohn]

The camera of Galaxy Nexus (software v. 4.0.2) reports *
preview-size-values=1920x1080,1280x720,960x720,800x480,720x576,720x480,768x576,640x480,320x240,352x288,240x160,176x144,128x96
*; and really, it is possible to set *Parameters.setPreveiwSize(320, 240) *and 
after that *Camera.getParameters().getPreviewSize()* will return *320x240*.

The problem is that the camera itself seems to silently ignore this 
setting: *onPreviewFrame() *callback arrives with preview buffer of *460800 
*bytes and contains a VGA preview (*640x480*).

This looks like a bug in Galaxy Nexus, but also exposes a problem with the 
Camera API of Android: there is no way for *Camera.setParameters()* to fail 
or report anything about parameters inconsistency.

Sincerely,
Alex

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

[android-developers] Re: camera preview formats and sizes

[Alex Cohn]

I have not seen single Android device to support rgb preview format. On the 
other hand, what is the scenario that you cannot convert the yuv preview 
frames to rgb?

Sincerely,
Alex

On Monday, May 21, 2012 2:41:48 AM UTC+3, Marco wrote:
>
> hello, 
> i would need to process camera preview frames of high quality in 
> android. 
> Is there a list of devices which are capable of using the 
> ImageFormat.RGB_565 camera preview format? 
>
> i would need to know supported preview formats and supported preview 
> size before buying the device... (i can't use the YUV420 format, i 
> need color information of the frame)

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

[android-developers] Re: Add Native Support not found in Eclipse

[Alex Cohn]

On Jan 11, 12:25 am, John-Marc Desmarais  wrote:
> Hi,
>
> Thanks for your help. I installed Sequoya and MTJ but, I still have no
> "AddNativeSupport" under Android Tools.
>
> I have also tried installing android-ndk-r6b and having
> C:\android\android-ndk-r6b in the path. But, currently, I have
> C:\android\android-ndk-r7 installed and in the system path.
>
> Maybe Indigo is the problem. I'll try Helios.
> -jm

I have Sequoya with plain minimal Indigo Eclipse (not for C/C++), it
works (almost) with android-ndk-r7. "Almost" has nothing to do with
Eclipse, the same "almost" applies to command line build of the
project: it's some funny cygwin issues with the NDK.

Maybe your problem is this "C/C++" version? Sequoya assumes you can
build a usual Android app (that is, JDK, Android SDK, ADT are all
installed and working with Eclipse).

Hope this helps,
Alex

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

[android-developers] Re: Using queueEvent for OpenGL

[Alex Cohn]

On Thursday, August 18, 2011 10:46:11 AM UTC+3, Jeffrey wrote:
>
>
> public boolean onTouchEvent(final MotionEvent event) { 
> queueEvent(new Runnable(){ 
> public void run() { 
> mRenderer.setColor(event.getX() / getWidth(), 
> event.getY() / getHeight(), 1.0f); 
> }}); 
> return true; 
> } 
>
> does not not work. I get the following error "The method 
> queueEvent(new Runnable(){}) is undefined for the type Main" 


The method queueEvent() is defined for 
android.opengl.GLSurfaceViewclass.
 You are trying to call it from class Main which does not extend this 
view class.

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

[android-developers] Re: How to control the speed of the OpenGL thread?

[Alex Cohn]

Usually, the GL thread calls your override of 
android.opengl.GLSurfaceView.Renderer.onDrawFrame()method.
 You can add there 
SystemClock.sleep(millis)or
 something similar to slow down this thread.

But maybe you need the 
onPause()and
 
onResume()methods
 ofGLSurfaceView
.

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

[android-developers] CHANGE_WIFI_MULTICAST_STATE

[Alex Cohn]

Please help me find a reasonable explanation of this permission. When
should I use it?

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

[android-developers] Re: Eclipse + cupcake + other android projects in build path = VerifyError

[Alex Cohn]

I wholeheartedly agree with Guillaume that Android lib projects would
be a good feature. But maybe the case I have in mind requires
something different.

I have ported to Android an LGPL library, libdmtx. This library has
native code and JNI wrapper. I created an org.libdmtx APK which
installs the native library (and the icon). The standard access rules
to /data/data/org.libdmtx/lib folder allow the native library to be
used from any application. But to work with this library, for every
application I must copy the libdmtx.jar file to the project libs
directory. Also, creating libdmtx.jar is a separate manual step in
Eclipse, and I must not forget to do this when some sources of libdmtx
change.

I would expect there to be a more straightforward and automatic way to
do all this. At least, luckily I can tell Eclipse that the application
references the libdmtx project (in the same workspace) and it will
install libdmtx.apk together with my application apk when I debug it
or run it as Android application.

Thanks,
Alex

From: Guillaume Perrot 

Android lib projects would be a good feature.
But why not having a dependency system between APKs like debian
packages ?

2009/5/1 Xavier Ducrohet 

> Hello,

> Editing the .classpath is a good solution. Let me explain why.

> ADT supports referenced projects so that you can have library projects
> reused by your main Application project.

> In the past, the build system provided by ADT just looked at the list
> of referenced projects, and added their output (bin/*/*.class) to the
> classes.dex of the application project.

> The main issue here is that those referenced projects should never
> have been Android project themselves.

> The reason is that those Android projects could have resources, which
> in turn creates an R.java file, which in turn is potentially used by
> the library project classes. Even if the resources from the library
> projects are copied into the main application project, there's no
> guarantee that the IDs in R.java will be similar between the projects.
> Therefore, at runtime, the classes from the library would access the
> wrong resources.

> We noticed this when we implemented the JUnit support. Instrumentation
> projects (look under samples/ApiDemos/test/) must reference the
> project they're testing to be able to compile, but they shouldn't
> include the code of the application they test.
> To fix this, we've restricted support of referenced projects to
> projects that are not Android projects (ie, do not have the Android
> Nature).

> Now, we do realize that you may still want to be able to share code
> that reference or extend Android classes, and this is not convenient.
> The solution to edit the .classpath to remove the nature and builder
> is one that will work, as long as you ensure that you are not using a
> previously generated R.java.
> For code that doesn't reference Android code, just make a standard Java
> project.

> In the future we will probably add a new type of Android project
> (maybe Android Library Project), that will allow you to compile
> against the Android framework but doesn't support Android resources,
> and doesn't generate R.java classes.

> Xav

> On Thu, Apr 30, 2009 at 7:26 AM, JMoger  wrote:

> > I've got a working solution to this similar to your hint about J2SE
> > projects.  Assuming your lib project is an android project, modify
> > the .project file to remove all Android builders and Android natures.
> > I removed the "resourcemanagerbuilder", "precompilerbuilder",
> > "apkbuilder", and "androidnature".  My lib project does not have any
> > resources so I don't know what happens in that situation; its just my
> > android code common to multiple projects.

> > The .classpath file remains unchanged:

> > 
> >        
> >        
> >         > path="com.android.ide.eclipse.adt.ANDROID_FRAMEWORK"/>
> >        
> > 

> > This allows the project to compile against the Android library
> > specified by the new "default.properties" file without manually
> > specifying the android.jar and your dependent applications projects
> > still compile in Eclipse and generate proper APKs.

> > This is still less than ideal, but it has allowed me to get back on
> > track.  YMMV.

> > -J

> --
> Xavier Ducrohet
> Android Developer Tools Engineer
> Google Inc.

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

To unsubscribe, reply using "remove me" as the subject.

[android-developers] LGPL on Android

[Alex Cohn]

Hi,

I have a question regarding the licensing. LGPL, as I understand it,
requires an Application to use "at run time a copy of the Library
already present on the user's computer system" and to provide
Installation instructions that enable the end user to choose a
modified version of the Library. But if I bundle a library (such as
libgdx) with my application, there is no way the user can upgrade this
library without recompiling my whole application. The only way to
comply with LGPL is to provide (as open source) an thin interface
layer that will work as a Service or as an Activity, which will answer
some custom Intent.

For a JNI shared lib, there is a potential to allow chosing an
alternative location of the .so file. But libgdx has, if I understand
correctly, important Java interfaces that cannot be easily wrapped in
terms of Service or Activity. Please correct me if my argument is
flawed.

Sincerely,
Alex Cohn

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

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words "REMOVE ME" as the subject.