[android-developers] Re: LVL: possible to check license for a different app?

[digipom]

I'm looking to do this too as i'm investigating a way to migrate from a 
free app + paid purchase to a free app + IAP purchase. However as 3c said, 
simply doing the check from another app won't work as that will result in 
a ERROR_INVALID_PACKAGE_NAME error.

Anyone else ever migrate from a separate paid version to IAPs? How did you 
manage it?

On Wednesday, 5 January 2011 20:27:25 UTC-4, andfan22 wrote:
>
> Hi all 
>
> Just wondering if I can use LVL to check that the user is licensed to 
> use a DIFFERENT app from the current one -- ie. one with a different 
> package name. 
>
> Why would I want to do this?  I'm developing an app which I'm 
> considering publishing using a free + pro license model.  The main app 
> would be a free, ad supported app.  To turn off ads the user would 
> purchase a pro license key from the market (published as a paid app 
> containing no functionality).  The user would continune to use the app 
> that was downloaded for free, which checks if the paid app is 
> installed, and if so it disables ads.   I prefer this model to a fully 
> featured paid app model, as it eliminates the need to migrate data 
> from the free version to the paid when the user upgrades. 
>
> Under this model I would like the free app to check if the paid app is 
> installed, and if so the free app would then use LVL to check if the 
> user has purchased the paid app via the market.  Will it be possible 
> for the free app to pass the package name of the paid app to LVL, and 
> to get back a result confirming whether the paid app has been 
> purchased or not? 
>
> Looking at the LVL source code I suspect I can do this by modifying 
> the constructor of LicenseChecker to set mPAckageName to a supplied 
> argument rather than setting it to mContext.getPackageName(). 
>
> Are there any gotcha's I may be missing? 
>
> Thanks ... 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/30f28ccd-dae1-4c59-814f-04e31fbf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] How to replace GLSurfaceView with TextureView in Android Ice Cream Sandwich?

[digipom]

There is a dearth of high-quality information on this topic -- any updates 
on the crashes or on syncing the thread, or on best practices using 
TextureView with OpenGL? I'm looking to migrate from GLSurfaceView to 
TextureView to work around some issues with view composition, but the lack 
of an official solution makes me nervous. I've noticed that even when using 
Choreographer, there are inexplicable jitters in the displayed frames that 
don't occur with GLSurfaceView and are not visible by observing the logs or 
frame timestamps.

On Wednesday, 11 July 2012 16:43:50 UTC-4, mor...@gmail.com wrote:
>
> Hi Romain,
>
> I am wondering about the Thread.sleep() call in the rendering thread's run 
> loop. Is that technically necessary? If so, may I ask why? And if so, then 
> how would one implement a high-framerate OpenGL game (for instance) using 
> TextureView?
>
> What prompted these questions is that I have run into a few devices where 
> this code 'crashes' with (randomly) one of the two following errors. Are 
> you able to comment on this?
>
>
>1. queueBuffer: slot 2 is current! 
>2. dequeueBuffer: buffer 0 is both FREE and current! 
>
>
>
> Many thanks,
> -Nathan Morse
>
>
> On Wednesday, November 23, 2011 9:17:28 AM UTC-8, Romain Guy (Google) 
> wrote:
>>
>> GLSurfaceView handles GL setup for you, which TextureView will not do. A 
>> TextureView can be used as the native window when you create an EGL 
>> surface. Here is an example (the interesting part is the call 
>> to eglCreateWindowSurface()):
>>
>> @Override
>> public void onSurfaceTextureAvailable(SurfaceTexture surface, int 
>> width, int height) {
>> mRenderThread = new RenderThread(getResources(), surface);
>> mRenderThread.start();
>> }
>>
>> private static class RenderThread extends Thread {
>> private static final String LOG_TAG = "GLTextureView";
>>
>> static final int EGL_CONTEXT_CLIENT_VERSION = 0x3098;
>> static final int EGL_OPENGL_ES2_BIT = 4;
>>
>> private volatile boolean mFinished;
>>
>> private final Resources mResources;
>> private final SurfaceTexture mSurface;
>> 
>> private EGL10 mEgl;
>> private EGLDisplay mEglDisplay;
>> private EGLConfig mEglConfig;
>> private EGLContext mEglContext;
>> private EGLSurface mEglSurface;
>> private GL mGL;
>>
>> RenderThread(Resources resources, SurfaceTexture surface) {
>> mResources = resources;
>> mSurface = surface;
>> }
>>
>> private static final String sSimpleVS =
>> "attribute vec4 position;\n" +
>> "attribute vec2 texCoords;\n" +
>> "varying vec2 outTexCoords;\n" +
>> "\nvoid main(void) {\n" +
>> "outTexCoords = texCoords;\n" +
>> "gl_Position = position;\n" +
>> "}\n\n";
>> private static final String sSimpleFS =
>> "precision mediump float;\n\n" +
>> "varying vec2 outTexCoords;\n" +
>> "uniform sampler2D texture;\n" +
>> "\nvoid main(void) {\n" +
>> "gl_FragColor = texture2D(texture, outTexCoords);\n" +
>> "}\n\n";
>>
>> private static final int FLOAT_SIZE_BYTES = 4;
>> private static final int TRIANGLE_VERTICES_DATA_STRIDE_BYTES = 5 
>> * FLOAT_SIZE_BYTES;
>> private static final int TRIANGLE_VERTICES_DATA_POS_OFFSET = 0;
>> private static final int TRIANGLE_VERTICES_DATA_UV_OFFSET = 3;
>> private final float[] mTriangleVerticesData = {
>> // X, Y, Z, U, V
>> -1.0f, -1.0f, 0.0f, 0.0f, 0.0f,
>>  1.0f, -1.0f, 0.0f, 1.0f, 0.0f,
>> -1.0f,  1.0f, 0.0f, 0.0f, 1.0f,
>>  1.0f,  1.0f, 0.0f, 1.0f, 1.0f,
>> };
>>
>> @Override
>> public void run() {
>> initGL();
>> 
>> FloatBuffer triangleVertices = 
>> ByteBuffer.allocateDirect(mTriangleVerticesData.length
>> * 
>> FLOAT_SIZE_BYTES).order(ByteOrder.nativeOrder()).asFloatBuffer();
>> triangleVertices.put(mTriangleVerticesData).position(0);
>>
>> int texture = loadTexture(R.drawable.large_photo);
>> int program = buildProgram(sSimpleVS, sSimpleFS);
>>
>> int attribPosition = glGetAttribLocation(program, "position");
>> checkGlError();
>>
>> int attribTexCoords = glGetAttribLocation(program, 
>> "texCoords");
>> checkGlError();
>>
>> int uniformTexture = glGetUniformLocation(program, "texture");
>> checkGlError();
>>
>> glBindTexture(GL_TEXTURE_2D, texture);
>> checkGlError();
>>
>> glUseProgram(program);
>> checkGlError();
>>
>> glEnableVertexAttribArray(attribPositi

[android-developers] When recording from a Bluetooth mic, the recording is silently switched to the main mic when switching apps.

[Digipom]

On a Nexus 5 running Android 5.0.1, when recording from the bluetooth mic 
with startBluetoothSco(), the recording switches to the phone mic if the 
app is switched. Please see below:

The recording is silently switched to the main input mic. 
SCO_AUDIO_STATE_DISCONNECTED is never received.

03-04 15:13:26.0261453-2016/? D/audio_hw_primary﹕ out_set_parameters: 
enter: usecase(1: low-latency-playback) kvpairs: routing=2
03-04 15:13:26.0491453-1997/? D/audio_hw_primary﹕ select_devices: 
out_snd_device(0: none) in_snd_device(32: speaker-mic)
03-04 15:13:26.0491453-1997/? D/audio_hw_primary﹕ disable_audio_route: 
reset and update mixer path: audio-record bt-sco
03-04 15:13:26.0611453-1997/? D/audio_hw_primary﹕ disable_snd_device: 
snd_device(44: bt-sco-mic)
03-04 15:13:26.0611453-1997/? D/msm8974_platform﹕ 
platform_send_audio_calibration: sending audio calibration for snd_device(32) 
acdb_id(11)
03-04 15:13:26.0611453-1997/? D/﹕ Failed to fetch the lookup information of 
the device 000B
03-04 15:13:26.0611453-1997/? E/ACDB-LOADER﹕ Error: ACDB AudProc vol 
returned = -19
03-04 15:13:26.0611453-1997/? D/audio_hw_primary﹕ enable_snd_device: 
snd_device(32: speaker-mic)
03-04 15:13:26.0651453-1997/? D/audio_hw_primary﹕ enable_audio_route: apply 
and update mixer path: audio-record


This will also happen if the screen is switched off. Wondering if anyone 
has any ideas about this and preventing it, if possible?

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: startBluetoothSco() not routing input audio through Bluetooth on Android Lollipop 5.0.1

[Digipom]

So the answer, at least for Lollipop, seems to be to 
use AudioSource.VOICE_COMMUNICATION instead of AudioSource.MIC, which is 
what is used on earlier versions.

On Thursday, February 26, 2015 at 9:24:07 AM UTC-5, Digipom wrote:
>
> I've been having some issues with startBluetoothSco() on my Nexus 5 on 
> Android Lollipop 5.0.1, where startBluetoothSco() will work and my 
> broadcast receiver will be called with an intent indicating that a 
> Bluetooth mic is connected, but when a recording is started, the audio is 
> recorded from the device's main input mic rather than the Bluetooth mic. 
> This issue is also reproducible on the Nexus 7 and may affect other devices 
> running 5.0.1 as well.
>
> Here is some example test code:
>
> http://pastebin.com/aEbEUhfy
>
> Does anyone know why this is happening? The same code works fine on 
> earlier versions of Android, and I can record from the Bluetooth mic there. 
> On 5.0.1, I still get an intent indicating that the mic is connected, but 
> the device will record from the on-device mic rather than the Bluetooth mic.
>
> The sample code requires these permissions in the manifest:
>
> 
> 
>  android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
> 
>
> The layout needs one button with android:id="@+id/recordStopButton".
>
> I also opened up this bug report: 
> https://code.google.com/p/android/issues/detail?id=156264
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: startBluetoothSco() not routing input audio through Bluetooth on Android Lollipop 5.0.1

[Digipom]

So the answer, at least for Lollipop, seems to be to 
use AudioSource.VOICE_COMMUNICATION instead 
of AudioSource.VOICE_COMMUNICATION instead of AudioSource.MIC, which is 
what is used on earlier versions.

On Thursday, February 26, 2015 at 9:24:07 AM UTC-5, Digipom wrote:
>
> I've been having some issues with startBluetoothSco() on my Nexus 5 on 
> Android Lollipop 5.0.1, where startBluetoothSco() will work and my 
> broadcast receiver will be called with an intent indicating that a 
> Bluetooth mic is connected, but when a recording is started, the audio is 
> recorded from the device's main input mic rather than the Bluetooth mic. 
> This issue is also reproducible on the Nexus 7 and may affect other devices 
> running 5.0.1 as well.
>
> Here is some example test code:
>
> http://pastebin.com/aEbEUhfy
>
> Does anyone know why this is happening? The same code works fine on 
> earlier versions of Android, and I can record from the Bluetooth mic there. 
> On 5.0.1, I still get an intent indicating that the mic is connected, but 
> the device will record from the on-device mic rather than the Bluetooth mic.
>
> The sample code requires these permissions in the manifest:
>
> 
> 
>  android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
> 
>
> The layout needs one button with android:id="@+id/recordStopButton".
>
> I also opened up this bug report: 
> https://code.google.com/p/android/issues/detail?id=156264
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] startBluetoothSco() not routing input audio through Bluetooth on Android Lollipop 5.0.1

[Digipom]

I've been having some issues with startBluetoothSco() on my Nexus 5 on 
Android Lollipop 5.0.1, where startBluetoothSco() will work and my 
broadcast receiver will be called with an intent indicating that a 
Bluetooth mic is connected, but when a recording is started, the audio is 
recorded from the device's main input mic rather than the Bluetooth mic. 
This issue is also reproducible on the Nexus 7 and may affect other devices 
running 5.0.1 as well.

Here is some example test code:

http://pastebin.com/aEbEUhfy

Does anyone know why this is happening? The same code works fine on earlier 
versions of Android, and I can record from the Bluetooth mic there. On 
5.0.1, I still get an intent indicating that the mic is connected, but the 
device will record from the on-device mic rather than the Bluetooth mic.

The sample code requires these permissions in the manifest:






The layout needs one button with android:id="@+id/recordStopButton".

I also opened up this bug 
report: https://code.google.com/p/android/issues/detail?id=156264

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] License client issue: can NOT_LICENSED be returned due to being off-line?

[Digipom Inc.]

Without going into details since this is a public forum, suffice it to say that 
it might not be in your best interest to delicense the app when it has been 
licensed successfully in the past. This approach has helped us in dealing with 
these issues, and perhaps a similar approach might help out in your case.

On Apr 1, 2014, at 11:48 AM, Ted Hopp  wrote:

> I'm not sure I understand this suggestion. What state are you tracking? How 
> is it "separate from what Google Play returns"? As I described, we are 
> already separately maintaining the last definitive response received. Do you 
> do something beyond that?
> 
> More to the point: our app seems to be receiving a NOT_LICENSED response in 
> situations where it is technically impossible that any response was received 
> from the Google Play license server. How would we distinguish these responses 
> (received from the licensing client running on the device) from legitimate 
> NOT_LICENSED responses (which would also be delivered via the licensing 
> client)?
> 
> On Tuesday, April 1, 2014 9:38:40 AM UTC-4, Digipom wrote:
> I've run into similar issues, and found that it's more reliable in terms of 
> impact on the end user to implement a second level of state tracking 
> separately from what Google Play returns. So, you might want to do that 
> depending on what your license policy is.
> 
> 
> -- 
> 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
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Android Developers" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/android-developers/2-FuY6eO1cQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: License client issue: can NOT_LICENSED be returned due to being off-line?

[Digipom]

I've run into similar issues, and found that it's more reliable in terms of 
impact on the end user to implement a second level of state tracking 
separately from what Google Play returns. So, you might want to do that 
depending on what your license policy is.

On Monday, March 31, 2014 9:32:41 PM UTC-4, Ted Hopp wrote:
>
> We have an app that uses the following license policy:
>
>- if a definitive response of LICENSED is stored in the app's 
>preferences and has not expired, allow access.
>- if a definitive response is not stored in the app's preferences, or 
>if it has expired, or if the cached response is NOT_LICENSED, request 
>a license check from the server.
>- if a definitive response (LICENSED or NOT_LICENSED) is received, it 
>is stored in the prefs, along with the license validity period returned by 
>the server. Access is permitted if the definitive response is LICENSED.
>- if anything other than a definitive response is received (airplane 
>mode, server error, etc.), the last stored definitive response is used to 
>determine access, even if expired. If no response is stored, allow access.
>
> (This is basically the same as the LenientPolicy described in this 
> thread.
>  
> We're aware of its weaknesses, but generally it works for us.)
>
> The problem is that we occasionally receive reports of customers being 
> denied use of the app due to a license problem. These are installations 
> that definitely should be receiving a server response of LICENSED. When 
> the problem happens, and when we've been able to obtain details, it always 
> turns out that the user's device was not fully connected. When full network 
> connectivity was restored, the app ran fine. Here's (part of) a report from 
> a customer who has been unusually helpful:
>
> I'm using an Acer Iconia A500 tablet, running Android 4.0.3, kernel 
> 2.6.39.4+. . . . So, I don't seem to be able to simulate it with airplane 
> mode on. I also tried turning airplane mode back off, and it works fine 
> right now. The situation where this happened to me it happened three 
> different times, it was during a reading group at another person's house, 
> and I don't have any access to their wifi network.  So, there was wifi in 
> the area, but I wasn't connected to any at all, but I wasn't on airplane 
> mode either. . . If it happens again, I will try to watch more closely and 
> take note of any network circumstances.
>
> We have not been able to reproduce the problem on either an emulator or on 
> our test devices. As far as I can tell from our code, our app will always 
> run unless it receives a response of NOT_LICENSED from the license 
> client. Our assumption had been that this was only possible if the 
> licensing client successfully contacted the license server and received a 
> response of NOT_LICENSED (or had an unexpired NOT_LICENSED server 
> response previously cached). But perhaps our assumption is wrong. Is there 
> any situation where the licensing client on the device will return a 
> response of NOT_LICENSED due to a communication problem (or any other 
> reason besides having received that response from the license server)? Is 
> there anything we could ask the customer to do that might help sort out 
> what's going wrong?
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Why apps not developed in C ?

[Digipom]

Here are some thoughts that would help bias the default choice toward Java:

   - There are more Java programmers out there, and Java is taught more 
   than C or C++. This leads to a bigger audience of developers for Google 
   Play.
   - The level of skill required to use C & C++ effectively is higher than 
   it is for Java, since the legacy of the languages is older and there are 
   more pitfalls and gotchas to worry about, like undefined behaviour, memory 
   corruption, and so forth.
   - Tooling and library support has historically been better for Java than 
   it has been for C / C++. 
   - Using a virtual machine means that apps don't need to be recompiled to 
   support future platforms. It may also give more freedom in other areas.

The downside is that the performance can sometimes be terrible under 
Dalvik. ART aims to ameliorate this, but I don't know if it can close the 
gap as well as Java on the desktop/server has been able to, relative to 
native performance. I've seen differences of 10x or more between native and 
Dalvik, depending on what the code is doing. For most non-game applications 
this won't be an issue, but for some applications, it is, and the Google 
team acknowledges this and gives you access to C / C++ via the NDK (Native 
Development Kit), if you really want it. There'll be a few limitations:

   - Code will be more complex due to the need to mix Java, C / C++, and 
   JNI glue code.
   - Most Java APIs are not directly accessible from the native layer.
   - You're limited as to which native libraries you can portably use 
   across different versions of Android.

If you're only looking for native performance without the hassle of using 
the NDK, RenderScript might be a better bet.

C/C++ might still make sense if you have existing libraries, a 
multi-platform code base such as a game engine, and Google doesn't prevent 
you from using native languages if you really want to. You can even use 
Fortran and other languages too, if you want! The native layer is not a 
first-class citizen on Android's platform, so using Java & RenderScript 
will lead to less pain, but the option is still there if you really want to 
use it.

On Monday, March 31, 2014 7:19:14 AM UTC-4, NewToAndroid wrote:
>
> Hi all,
>
> I have this question out of curiocity.
> Android is based on Linux, which is basically written in C. Why Android 
> apps are not written in C ? Why Java?
>
> I accept that , I might have big gaps in my understanding of Android, 
> which is what I want to clear.
>
> Thanks in advance
>
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Re: Issues with KitKat 4.4.2, the recent apps list, and startForeground(): What criteria does KitKat use to kill an app when swiped away from the recent apps list?

[Digipom]

Stuff I've tried:

1) Removed all broadcast receivers from AndroidManifest.xml.
2) Removed all sendBroadcast calls from the code.
3) Removed all broadcast receivers from the code.
4) Removed all calls to AppWidgetManager. 
5) (I don't have any calls to AlarmManager)
6) Delete all "" from the manifest, except for the launcher.
7) Change android:targetSdkVersion="19" to different levels all the way 
down to 14.

At this point, I think the only safe way to handle this might be to 
override onTaskRemoved only for API 19 and use that to safely stop the app 
(since onDestroy doesn't get called), and display a warning / clear ongoing 
notifications so that the user at least knows that they stopped their task 
by swiping the app away.

Does anyone have ideas on how I could trace this further and figure out 
what's triggering the app to get killed? Otherwise it's a wait to API 20 
and hope it's fixed there.

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [android-developers] Re: Issues with KitKat 4.4.2, the recent apps list, and startForeground(): What criteria does KitKat use to kill an app when swiped away from the recent apps list?

[Digipom Inc.]

Based on those threads and the issues list, it seems that receiving a broadcast 
is the main known way that this is triggered (aside from not having a 
foreground service, but I do have one), but I have logs on all my onReceive and 
it doesn't seem to be that. :(

On Mar 13, 2014, at 2:45 AM, Pent  wrote:

> Try a search of the forum. There are some long threads on this issue.
> 
> It's also on the Android issues list in various guises.
> 
> Pent
> 
> 
> -- 
> 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
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Android Developers" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/android-developers/3SBriAT632M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Issues with KitKat 4.4.2, the recent apps list, and startForeground(): What criteria does KitKat use to kill an app when swiped away from the recent apps list?

[Digipom]

I decided to dig further into this based on readings from Googling, and 
here are some stats from adb shell dumpsys activity:

Here's the last line I see an instant before the app is killed (I'm just 
running it over and over):

 Proc # 4: prcp  F/S/IF trm: 0 17361:com.mypackage.name/u0a241 (fg-service)


With this in LogCat:


 I/ActivityManager( 1743): Killing 17361:com.mypackage.name/u0a241 (adj 0): 
remove task


It doesn't always get killed, but it does get killed pretty often. If it 
doesn't get killed right away (within 5 seconds or so) then it seems to 
persist.

Here's what I see run another other app that doesn't get killed:

 Proc # 4: prcp F/S/IF trm: 0 17539:com.anotherpackage.name/u0a118 
(fg-service)

With dab shell dumpsys meminfo (IIRC), this other app was also consuming 
significantly more memory than my own, yet not getting killed. So, I'm not 
really seeing much difference and not understanding why my app is getting 
killed. :(

On Thursday, March 13, 2014 12:36:03 AM UTC-4, Digipom wrote:
>
> I'm running into an issue with my app on KitKat 4.4.2: when it's 
> recording, and the user later sends it to the background and swipes it away 
> from the recent apps list, the app is killed, even though it called 
> startForeground!
>
> This did not happen on 4.3, and to add insult to injury, the notification 
> doesn't disappear and the app services still appear in the "running 
> services" in the device settings.
>
> However, I see that this isn't happening for all apps. I downloaded some 
> other recorders, and I can confirm that their processes remain active in 
> memory even though I've also removed them from the recent apps list using 
> the same method; they remain active even if not recording! I thought it 
> could be an issue with the target API, but lowering that to 14 didn't help 
> (I don't think I could lower it further than that if using Action Bar 
> Sherlock).
>
> Does anyone have any ideas? It's definitely not cool from a customer's 
> point of view, so I really want to find a solution.
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Issues with KitKat 4.4.2, the recent apps list, and startForeground(): What criteria does KitKat use to kill an app when swiped away from the recent apps list?

[Digipom]

With dumpsys activity | grep "Proc #" | grep my.package.name  It looks like 
the app was in "fg-service" before getting killed.

Looking at the source code here: 
6968<http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4.2_r1/com/android/server/am/ActivityManagerService.java#6968>,
 
it seems that the process should only be killed if "non-interactive".

On Thursday, March 13, 2014 12:36:03 AM UTC-4, Digipom wrote:
>
> I'm running into an issue with my app on KitKat 4.4.2: when it's 
> recording, and the user later sends it to the background and swipes it away 
> from the recent apps list, the app is killed, even though it called 
> startForeground!
>
> This did not happen on 4.3, and to add insult to injury, the notification 
> doesn't disappear and the app services still appear in the "running 
> services" in the device settings.
>
> However, I see that this isn't happening for all apps. I downloaded some 
> other recorders, and I can confirm that their processes remain active in 
> memory even though I've also removed them from the recent apps list using 
> the same method; they remain active even if not recording! I thought it 
> could be an issue with the target API, but lowering that to 14 didn't help 
> (I don't think I could lower it further than that if using Action Bar 
> Sherlock).
>
> Does anyone have any ideas? It's definitely not cool from a customer's 
> point of view, so I really want to find a solution.
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Re: Issues with KitKat 4.4.2, the recent apps list, and startForeground(): What criteria does KitKat use to kill an app when swiped away from the recent apps list?

[Digipom]

With dumpsys activity | grep "Proc #" | grep my.package.name  It looks like 
the app was in "fg-service" before getting killed.

Looking at the source code here: 
6968,
 
it seems that the process should only be killed if "non-interactive". The 
latest is 4.4.2 so not sure exactly what 4.4.3 is using if different.

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Issues with KitKat 4.4.2, the recent apps list, and startForeground(): What criteria does KitKat use to kill an app when swiped away from the recent apps list?

[Digipom]

I'm running into an issue with my app on KitKat 4.4.2: when it's recording, 
and the user later sends it to the background and swipes it away from the 
recent apps list, the app is killed, even though it called startForeground!

This did not happen on 4.3, and to add insult to injury, the notification 
doesn't disappear and the app services still appear in the "running 
services" in the device settings.

However, I see that this isn't happening for all apps. I downloaded some 
other recorders, and I can confirm that their processes remain active in 
memory even though I've also removed them from the recent apps list using 
the same method; they remain active even if not recording! I thought it 
could be an issue with the target API, but lowering that to 14 didn't help 
(I don't think I could lower it further than that if using Action Bar 
Sherlock).

Does anyone have any ideas? It's definitely not cool from a customer's 
point of view, so I really want to find a solution.

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[android-developers] Using the new SurfaceFlinger features in Android 4.4 KitKat

[Digipom]

According to the new KitKat documentation, the new SurfaceFlinger supports 
additional features, as described below:
"
GLES2.0 SurfaceFlinger

Android 4.4 upgrades its SurfaceFlinger from OpenGL ES 1.0 to OpenGL ES 
2.0. This boosts performance by using multi-texturing, and it improves 
color calibration and supports more advanced special effects.
New Hardware Composer support for virtual displays
The latest version of Android Hardware Composer, HWComposer 1.3, supports 
hardware composition of one virtual display in addition to the primary, 
external (e.g. HDMI) display, and has improved OpenGL ES interoperability."

Does anyone know if any of these features (such as color calibration and 
special effects) are exposed in the SDK, and if so, how? I looked on the 
Android dev site myself but I didn't see specific changes related to this.

Thanks!

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: Gradle build is screwing up in weird ways on 5% of devices when used with Proguard -- same config and source works fine in Eclipse build

[Digipom Inc.]

So after some further follow-up I can confirm there are two fixes:

1) Just print out the value of the variable in a Log.d. Believe it or not,
that "fixes" the code.
2) Change "float" into "double".

Based on customer reports I received, the bug only affected users running
API 15 or 16, and only some models of phones, not all (again, based on
customer reports). Still if you guys switch to Gradle using Proguard 4.9
with obfuscation on (even with optimization off), might want to watch out
for floating point conversions in your code, or just compile with
obfuscation off or export with Eclipse.

On Thu, Aug 8, 2013 at 2:17 PM, Digipom Inc.  wrote:

> Interesting, I wasn't aware of the strictfp modifier. It seems that
> changing one of the floats to a double may have fixed it... I sent out
> several more specific tests and waiting for the remote debugger to confirm.
> :)
>
>
> On Wed, Aug 7, 2013 at 5:12 PM, Nobu Games wrote:
>
>> If it is floating point related you could try adding the "strictfp"
>> modifier to your methods or classes that rely on platform-independent
>> floating point arithmetics.
>>
>>
>> On Wednesday, August 7, 2013 12:02:04 PM UTC-5, Digipom wrote:
>>>
>>> I figured it out -- I seem to have run into some sort of an obscure
>>> floating-point optimization bug that occurs on certain devices. I opened
>>> https://code.google.**com/p/android/issues/detail?**id=58698<https://code.google.com/p/android/issues/detail?id=58698>to
>>>  track the issue. I haven't found a workaround yet aside from exporting
>>> from Eclipse for now, but I'm trying different things like replacing floats
>>> with doubles to see if that makes a difference. It's slow-going since I
>>> can't reproduce the issue locally and rely on remote debugging. ;)
>>>
>>> On Sunday, August 4, 2013 3:42:52 PM UTC-4, Digipom wrote:
>>>>
>>>> Hello,
>>>>
>>>> I recently moved to Gradle from Eclipse so that I could have an easy
>>>> time of building from the command line, and at first I was very happy with
>>>> the Gradle build, until about 5% of the customers started emailing me and
>>>> complaining that the app was behaving strangely and not working correctly.
>>>> No crashes, just... behaving oddly, and only on 5% of the devices. The code
>>>> & Proguard config is identical, so it seems something bad is happening with
>>>> the way that the code is being generated. I haven't figured it out yet, but
>>>> I'm digging into things with apktool and I'm seeing a lot of differences
>>>> with the generated classes from the same class files, which I find strange
>>>> because the Proguard config that I'm feeding in is the same. Unfortunately,
>>>> I have to go back to manual builds with Eclipse for now due to this issue.
>>>>
>>>> Does anyone else have any similar experiences or insight into this? Are
>>>> the Eclipse / Gradle builds using different build tools behind the scenes
>>>> which could lead to differences in the generated code and cause some files
>>>> to be mis-generated? Thank you!
>>>>
>>>  --
>> 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
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Android Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/android-developers/h48v0STCW5o/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> android-developers+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> --
> Digipom
> http://www.digipom.com
>



-- 
-- 
Digipom
http://www.digipom.com

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: Gradle build is screwing up in weird ways on 5% of devices when used with Proguard -- same config and source works fine in Eclipse build

[Digipom Inc.]

Interesting, I wasn't aware of the strictfp modifier. It seems that
changing one of the floats to a double may have fixed it... I sent out
several more specific tests and waiting for the remote debugger to confirm.
:)

On Wed, Aug 7, 2013 at 5:12 PM, Nobu Games  wrote:

> If it is floating point related you could try adding the "strictfp"
> modifier to your methods or classes that rely on platform-independent
> floating point arithmetics.
>
>
> On Wednesday, August 7, 2013 12:02:04 PM UTC-5, Digipom wrote:
>>
>> I figured it out -- I seem to have run into some sort of an obscure
>> floating-point optimization bug that occurs on certain devices. I opened
>> https://code.google.**com/p/android/issues/detail?**id=58698<https://code.google.com/p/android/issues/detail?id=58698>to
>>  track the issue. I haven't found a workaround yet aside from exporting
>> from Eclipse for now, but I'm trying different things like replacing floats
>> with doubles to see if that makes a difference. It's slow-going since I
>> can't reproduce the issue locally and rely on remote debugging. ;)
>>
>> On Sunday, August 4, 2013 3:42:52 PM UTC-4, Digipom wrote:
>>>
>>> Hello,
>>>
>>> I recently moved to Gradle from Eclipse so that I could have an easy
>>> time of building from the command line, and at first I was very happy with
>>> the Gradle build, until about 5% of the customers started emailing me and
>>> complaining that the app was behaving strangely and not working correctly.
>>> No crashes, just... behaving oddly, and only on 5% of the devices. The code
>>> & Proguard config is identical, so it seems something bad is happening with
>>> the way that the code is being generated. I haven't figured it out yet, but
>>> I'm digging into things with apktool and I'm seeing a lot of differences
>>> with the generated classes from the same class files, which I find strange
>>> because the Proguard config that I'm feeding in is the same. Unfortunately,
>>> I have to go back to manual builds with Eclipse for now due to this issue.
>>>
>>> Does anyone else have any similar experiences or insight into this? Are
>>> the Eclipse / Gradle builds using different build tools behind the scenes
>>> which could lead to differences in the generated code and cause some files
>>> to be mis-generated? Thank you!
>>>
>>  --
> 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
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Android Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/android-developers/h48v0STCW5o/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
-- 
Digipom
http://www.digipom.com

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Gradle build is screwing up in weird ways on 5% of devices when used with Proguard -- same config and source works fine in Eclipse build

[Digipom]

I figured it out -- I seem to have run into some sort of an obscure 
floating-point optimization bug that occurs on certain devices. I 
opened https://code.google.com/p/android/issues/detail?id=58698 to track 
the issue. I haven't found a workaround yet aside from exporting from 
Eclipse for now, but I'm trying different things like replacing floats with 
doubles to see if that makes a difference. It's slow-going since I can't 
reproduce the issue locally and rely on remote debugging. ;)

On Sunday, August 4, 2013 3:42:52 PM UTC-4, Digipom wrote:
>
> Hello,
>
> I recently moved to Gradle from Eclipse so that I could have an easy time 
> of building from the command line, and at first I was very happy with the 
> Gradle build, until about 5% of the customers started emailing me and 
> complaining that the app was behaving strangely and not working correctly. 
> No crashes, just... behaving oddly, and only on 5% of the devices. The code 
> & Proguard config is identical, so it seems something bad is happening with 
> the way that the code is being generated. I haven't figured it out yet, but 
> I'm digging into things with apktool and I'm seeing a lot of differences 
> with the generated classes from the same class files, which I find strange 
> because the Proguard config that I'm feeding in is the same. Unfortunately, 
> I have to go back to manual builds with Eclipse for now due to this issue.
>
> Does anyone else have any similar experiences or insight into this? Are 
> the Eclipse / Gradle builds using different build tools behind the scenes 
> which could lead to differences in the generated code and cause some files 
> to be mis-generated? Thank you! 
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Gradle build is screwing up in weird ways on 5% of devices when used with Proguard -- same config and source works fine in Eclipse build

[Digipom]

Hello,

I recently moved to Gradle from Eclipse so that I could have an easy time 
of building from the command line, and at first I was very happy with the 
Gradle build, until about 5% of the customers started emailing me and 
complaining that the app was behaving strangely and not working correctly. 
No crashes, just... behaving oddly, and only on 5% of the devices. The code 
& Proguard config is identical, so it seems something bad is happening with 
the way that the code is being generated. I haven't figured it out yet, but 
I'm digging into things with apktool and I'm seeing a lot of differences 
with the generated classes from the same class files, which I find strange 
because the Proguard config that I'm feeding in is the same. Unfortunately, 
I have to go back to manual builds with Eclipse for now due to this issue.

Does anyone else have any similar experiences or insight into this? Are the 
Eclipse / Gradle builds using different build tools behind the scenes which 
could lead to differences in the generated code and cause some files to be 
mis-generated? Thank you! 

-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] OpenGL Tracer not working with a Nexus 7?

[Digipom Inc.]

Thanks, I've added my info to the bug. Hope that we can figure out a
solution.

On Tue, Mar 19, 2013 at 2:34 PM, Harri Smått  wrote:

> Hi,
>
> There's this one rather recent issue which might be related to what you're
> seeing;
> https://code.google.com/p/android/issues/detail?id=52446
>
> --
> H
>
> On Mar 19, 2013, at 8:06 PM, Digipom  wrote:
>
> > I'm also seeing the same problem with a Galaxy Nexus, just like this
> guy:
> http://stackoverflow.com/questions/15317083/android-opengl-tracer-not-working:(
> >
> > Anyone have any idea?
>
> --
> --
> 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
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Android Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/android-developers/Pd736gu6I2U/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, send an email to
> android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
-- 
Digipom
http://www.digipom.com

-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: OpenGL Tracer not working with a Nexus 7?

[Digipom]

I'm also seeing the same problem with a Galaxy Nexus, just like this 
guy: 
http://stackoverflow.com/questions/15317083/android-opengl-tracer-not-working 
:(

Anyone have any idea? 

On Monday, March 18, 2013 2:05:41 PM UTC-4, Digipom wrote:
>
> Hello,
> I have a Nexus 7 running 4.2.2. I'm trying to trace an OpenGL ES 2.0 
> application, but I can never seem to get OpenGL ES Tracer to work. I'm 
> following the instructions here: 
> http://developer.android.com/tools/help/gltracer.html
>
> The tracer seems to load fine, and when I put in the package and activity 
> class, the right application is launched and the activity starts, and 
> Tracer says that it's tracing. However, the size always stays at 0MB and 
> the trace file remains at 0 bytes. Occasionally I'll see a socket write 
> error right away, but usually I won't. If I then click "Enable" next to 
> "Collect Framebuffer contents on glDraw*()", then I always see a 
> "Connection reset by peer: socket write error" error message.
>
> I'd really like to get this to work. I played around with different 
> settings in the Developer options to no avail. I even tried on OS X in case 
> it was a Windows issue, and I had the same problems there.
>
> Thanks!
>
>
>
>
>
> <https://lh6.googleusercontent.com/-Cjjc0k7qa2g/UUdW6TKRDcI/AAM/s1q3j4RZat8/s1600/socket-write-error.png>
>
>
>
> <https://lh6.googleusercontent.com/-va1y14LW0y8/UUdXENDe2PI/AAc/SzoBs9P33cs/s1600/socket-write-error-2.png>
>
>

-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] OpenGL Tracer not working with a Nexus 7?

[Digipom]

Hello,
I have a Nexus 7 running 4.2.2. I'm trying to trace an OpenGL ES 2.0 
application, but I can never seem to get OpenGL ES Tracer to work. I'm 
following the instructions 
here: http://developer.android.com/tools/help/gltracer.html

The tracer seems to load fine, and when I put in the package and activity 
class, the right application is launched and the activity starts, and 
Tracer says that it's tracing. However, the size always stays at 0MB and 
the trace file remains at 0 bytes. Occasionally I'll see a socket write 
error right away, but usually I won't. If I then click "Enable" next to 
"Collect Framebuffer contents on glDraw*()", then I always see a 
"Connection reset by peer: socket write error" error message.

I'd really like to get this to work. I played around with different 
settings in the Developer options to no avail. I even tried on OS X in case 
it was a Windows issue, and I had the same problems there.

Thanks!









-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: Different sets of widgets for pre-3.0 and post-3.0 devices?

[Digipom Inc.]

Hi Al,

Thanks, this seems like a good approach. This was just what I was wondering
-- how to statically configure things so as to avoid the Android bugs with
runtime enabling/disabling. I'll give this one a shot! :)

On Tue, Feb 19, 2013 at 3:08 AM, al  wrote:

> You can "statically" configure this:
>
> In AndroidManifest.xml for the widget receivers add:
> ...
> ...
>
> Then define the booleans depending on the versions:
> In values/bool.xml
> 
> false
> true
> 
>
> values-v11/bool.xml
> 
> true
> false
> 
>
> I have an app in the play store using this approach. I'm not aware of
> problems with it.
>
>
> Am Dienstag, 19. Februar 2013 03:00:40 UTC+1 schrieb Digipom:
>
>> Hello,
>>
>> I was wondering if it's possible to have a different set of widgets for
>> pre-Honeycomb devices and post-Honeycomb devices? The reason why I ask is
>> because I currently have a 1x1, 2x1, 3x1 etc widget for the different
>> possible sizes, as Gingerbread and earlier didn't support resizeable
>> widgets, but this is redundant for Honeycomb and above because widgets can
>> be resized, and it would be cleaner if there was just one widget in the app
>> drawer rather than several. I've heard that runtime enabling/disabling of
>> widgets is unreliable and doesn't work properly, though I can't remember
>> where I read that now.
>>
>> What do you guys recommend?
>>
>  --
> --
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
-- 
Digipom
http://www.digipom.com

-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Different sets of widgets for pre-3.0 and post-3.0 devices?

[Digipom]

Hello,

I was wondering if it's possible to have a different set of widgets for 
pre-Honeycomb devices and post-Honeycomb devices? The reason why I ask is 
because I currently have a 1x1, 2x1, 3x1 etc widget for the different 
possible sizes, as Gingerbread and earlier didn't support resizeable 
widgets, but this is redundant for Honeycomb and above because widgets can 
be resized, and it would be cleaner if there was just one widget in the app 
drawer rather than several. I've heard that runtime enabling/disabling of 
widgets is unreliable and doesn't work properly, though I can't remember 
where I read that now.

What do you guys recommend?

-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: Debugging beta apps

[Digipom]

A few recommendations from my experiences:

1) If you use Proguard, then keep a copy of your "proguard" folder for each 
release that you do. This will help you make sense of the market exceptions.

2) Use something like ACRA (https://github.com/ACRA/acra) to log all items 
of interest, including uncaught exceptions. This will give you a lot more 
detail than the market crash reports.

So for example, in your code you can do something like this:

void someMethod() {
   // Do something
   MyLogger.log(Something interesting...);
}

On Friday, February 15, 2013 1:40:01 PM UTC-5, dashman wrote:
>
> How do users debug their beta apps - once it's released 
> to users. I'd like to get a better feedback than 'app crashed.
>
> Can users send back log files etc.
>
> I was thinking about using ASSERT.
>
> Is the java assert feature recommended or the Assert class.
>
> I noticed that the latter does not display a message on the screen.
>
>
> Help appreciated.
>
>

-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: best way to copy an existing application

[Digipom Inc.]

Ok, I was just wondering, as I once turned an app project into a library
project by simply checking the checkbox, kept the old package name for the
library and created a new app project with a different package.

I was just wondering if there was something I might have overlooked or some
bad side effect to just checking that box, though it seems to have worked
to date. ;)

On Wed, Feb 13, 2013 at 9:25 AM, RichardC wrote:

> You could do that but you might end up with package name problems if you
> want to keep your existing package name for your old application (and a new
> package name for the 2nd application).
>
> So you will probable need to rename the package of the library and this
> will have some knock-on effects on your existing code.
>
> From John Merlino's posting I assumed he was new to Android library
> projects and tried to keep my suggestions to him as simple as possible.
>
>
> On Wednesday, February 13, 2013 2:05:34 PM UTC, Digipom wrote:
>>
>> Hi Lew,
>>
>> Do you kindly have any evidence or documentation to back up your claims?
>> I'm just curious. Why can't one just check the library checkbox?
>>
>> On Tuesday, February 12, 2013 5:13:25 PM UTC-5, Lew wrote:
>>>
>>> bob wrote:
>>>
>>>> Does he really need to create a new library project?
>>>>
>>>>   Yes.
>>>
>>>
>>>> Or can he just check the Is Library checkbox on his existing project?
>>>>
>>> No.
>>>
>>>
>>>> RichardC wrote:
>>>>>
>>>>> Create an new Android Library project.
>>>>> Put all your existing shared code and resources into it.
>>>>> Create 2 new Android Projects (one with your old package name and the
>>>>> other with a new package name), and set them to use your Android Library
>>>>> project.
>>>>> Put the different resources into the Application Projects.
>>>>>
>>>>> To setup a Library project see:
>>>>> http://developer.android.com/**tools/projects/projects-**eclipse.html#
>>>>> **SettingUpLibraryProject<http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject>
>>>>>
>>>>> John Merlino wrote:
>>>>>>
>>>>>> I have an application already created and up and running on google
>>>>>> play. I need to create a second application where everything is the
>>>>>> same, other than the background views. So I am wondering the easiest
>>>>>> way to essentially clone an application so that all I have to do is
>>>>>> create new keys and change the background images. thanks for
>>>>>> response.
>>>>>>
>>>>>
>>> --
>>> Lew
>>>
>>>
>>  --
> --
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
-- 
Digipom
http://www.digipom.com

-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: best way to copy an existing application

[Digipom]

Hi Lew,

Do you kindly have any evidence or documentation to back up your claims? 
I'm just curious. Why can't one just check the library checkbox?

On Tuesday, February 12, 2013 5:13:25 PM UTC-5, Lew wrote:
>
> bob wrote:
>
>> Does he really need to create a new library project?
>>
>>   Yes.
>  
>
>> Or can he just check the Is Library checkbox on his existing project?
>>
> No.
>  
>
>> RichardC wrote:
>>>
>>> Create an new Android Library project.
>>> Put all your existing shared code and resources into it.
>>> Create 2 new Android Projects (one with your old package name and the 
>>> other with a new package name), and set them to use your Android Library 
>>> project.
>>> Put the different resources into the Application Projects.
>>>
>>> To setup a Library project see:
>>>
>>> http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject
>>>
>>> John Merlino wrote:

 I have an application already created and up and running on google 
 play. I need to create a second application where everything is the 
 same, other than the background views. So I am wondering the easiest 
 way to essentially clone an application so that all I have to do is 
 create new keys and change the background images. thanks for response. 

>>>
> -- 
> Lew
>  
>

-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: ALL DEVELOPERS PIRATED APPLICATION ALL OVER!

[Digipom]

My take on things is that the less you piss off your users, the better. 
Unfortunately, Google's default licensing mechanism is not only cracked in 
5 seconds, but it also pisses off users if they try to use your app outside 
of a network connection. You can still stay with Google's method, but 
you'll need to do some customization and ensure that any roadblocks you put 
in place for piracy do not have the side effect of pissing off the people 
actually paying for your app.

P.S. was it really worth digging up an old thread just to complain about 
someone's spelling?

On Friday, January 25, 2013 1:27:20 PM UTC-5, JackN wrote:
>
> We can tell you're new to development, and spelling too.
>
> On Wednesday, July 22, 2009 10:28:50 AM UTC-7, astrocogz wrote:
>
>>
>> I'm new to this whole thing about being a developer but, if you think 
>> making your app hack safe and, your app's are not going to lose you your 
>> user base. Then say a hello to the new world order of android. Stop 
>> bitching and think of it as contributing to your community. I don't steel 
>> but I don't look a gift horse in the mouth either so shut up and programme 
>> like your told and stop helping to force the world in to a new world police 
>> globe or pay the hundred and move to iphone.
>>
>

-- 
-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[android-developers] Re: fatal_error

[Digipom]

Depends on what you're trying to accomplish. Normally an uncaught exception 
will just terminate your app anyways, so there's no need for fatal_error 
type stuff. If the error comes from code that doesn't throw, you can just 
throw your own exception; no need to kill the process. That way, you also 
get the benefit of on-the-field reports via Android's error handler.

On Thursday, September 6, 2012 11:29:45 AM UTC-4, bob wrote:
>
> Back in the day, when I used to program Windows and other systems, I had a 
> function like this:
>
>
> void fatal_error(char *msg)
>
> {
>
> cout << msg << endl;
>
> exit(1);
>
> }
>
>
>
> Is there an easy way to make something similarly elegant and useful in 
> Android?
>
>
>

-- 
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

Re: [android-developers] Re: Static vs Dynamic vertex buffers?

[Digipom]

I think it doesn't hurt to try that. WIth an index buffer you can just pass 
in the offset to glDrawElements (You'll need to target API 9 or higher to 
get the right method).

On Friday, August 24, 2012 6:17:29 PM UTC-4, Braindrool wrote:
>
> Eh, I believe I know what I'm doing. I've been programming for years. But 
>> I have very little experience with 3D and OpenGL in general.
>>
>
> And a question still remains. How would I get the correct offset for the 
> buffers? I've read plenty of tutorials on how to use the buffer, but they 
> only use 1 object. Would I just have to record how many bytes it puts in?
>
>>
>> On Friday, August 24, 2012 2:46:20 AM UTC-5, Fabien R wrote:
>>>
>>> On 23/08/2012 23:32, Braindrool wrote: 
>>> >   
>>> >> Just a side note that the .obj decoder obviously isn't complete. Just 
>>> >> waiting for an answer first. Thought I'd point out the obvious. 
>>> >> 
>>> >> 
>>> >   
>>> You may have a look at min3d to see how the OBJ decoding is performed. 
>>> - 
>>> Fabien 
>>
>>

-- 
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

Re: [android-developers] Re: service dies without calling onDestroy()

[Digipom Inc.]

Well, it makes sense, "expected" or not. Many applications do use the
MediaRecorder in the background as most users expect to be able to continue
recording when they do other tasks, not just when they have the activity in
the foreground. If the use case wasn't expected, it probably should have
been.

On Thu, Aug 16, 2012 at 10:29 AM, Mark Murphy wrote:

> On Thu, Aug 16, 2012 at 10:19 AM, Digipom Inc.  wrote:
> >> Not everything is designed to be used indefinitely by a service.
> >
> > It's hard to think of something more suited to a service than recording
> in
> > the background.
>
> You presume that "recording in the background" is part of the expected
> use cases for MediaRecorder.
>
> --
> Mark Murphy (a Commons Guy)
> http://commonsware.com | http://github.com/commonsguy
> http://commonsware.com/blog | http://twitter.com/commonsguy
>
> Android Training in NYC: http://marakana.com/training/android/
>
> --
> 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
>



-- 
-- 
Digipom
http://www.digipom.com

-- 
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

Re: [android-developers] Re: service dies without calling onDestroy()

[Digipom Inc.]

On Thu, Aug 16, 2012 at 7:57 AM, Mark Murphy wrote:

> On Thu, Aug 9, 2012 at 11:23 AM, Digipom  wrote:
> > I got bitten by this the hard way. The official documentation on services
> > doesn't have any warnings about this, so I figured onDestroy() was good
> > enough. I had some audio shut down code in onDestroy() that wasn't
> getting
> > called when the phone was being shut down, so I'd have a corrupt file
> > because the MP4 file would not be properly finished by Android's
> > MediaRecorder.
> >
> > What would you recommend as an ideal way to handle this? Trap the shut
> down
> > intents?
>
> If by that you mean register a BroadcastReceiver from the service for
> ACTION_SHUTDOWN, that's certainly worth a shot.
>

I hooked onto this as well as the HTC equivalent, and it seems to work. I
opened a bug against the documentation for onDestroy(), and it's been filed
for a future release.


>
> > Unfortunately, it seems that won't handle other instances where the
> > app might kill the service, though I do register it as a foreground
> service.
>
> Not everything is designed to be used indefinitely by a service.
>

It's hard to think of something more suited to a service than recording in
the background.

However, with foreground mode + the broadcast receiver for shut down, this
captures most of the cases. At least on newer versions of Android, I
haven't seen it kill the service otherwise. I suppose it's still possible
which is really unfortunate, because MP4 and 3GP files that haven't been
terminated properly are a pain to repair. WAVE on the other hand is no big
deal.

For anyone else reading this, it also seems that Android's media recorder
is not smart enough to terminate the file if it runs out of disk space, so
you'll also need to filestat the file and make sure you're not dangerously
low on free space remaining.


>
> --
> Mark Murphy (a Commons Guy)
> http://commonsware.com | http://github.com/commonsguy
> http://commonsware.com/blog | http://twitter.com/commonsguy
>
> Android Training in NYC: http://marakana.com/training/android/
>
> --
> 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
>



-- 
-- 
Digipom
http://www.digipom.com

-- 
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

Re: [android-developers] Re: service dies without calling onDestroy()

[Digipom]

I got bitten by this the hard way. The official documentation on services 
doesn't have any warnings about this, so I figured onDestroy() was good 
enough. I had some audio shut down code in onDestroy() that wasn't getting 
called when the phone was being shut down, so I'd have a corrupt file 
because the MP4 file would not be properly finished by Android's 
MediaRecorder. 

What would you recommend as an ideal way to handle this? Trap the shut down 
intents? Unfortunately, it seems that won't handle other instances where 
the app might kill the service, though I do register it as a foreground 
service.

On Thursday, August 11, 2011 5:16:41 PM UTC-4, Mark Murphy (a Commons Guy) 
wrote:
>
> On Thu, Aug 11, 2011 at 4:58 PM, Mikael Kuisma > 
> wrote:
> > System.exit()?
>
> No, a regular stopSelf() / IntentService should be fine.
>
> > Since Android keeps the DVM around even after I terminate my
> > services and activities, I thought it would be a nice place to store the
> > state via a singelton object to save flash writes.
>
> As a cache, sure. Don't count on it though -- save your data before
> onHandleIntent() returns or you call stopSelf(). Static data members
> are *only* to be used as a cache.
>
> >> Users don't like sloppy developers who keep services in RAM for no
> >> good reason. Guess what? Users win.
> >
> > A good reason is to save unnecessary flash writes, wouldn't you say?
>
> Users don't notice "unnecessary flash writes", assuming that they are
> done on a background thread. They do notice services running 24x7.
> Developers who create such everlasting services have harmed Android's
> reputation and spawned the creation of task killers and equivalent
> capabilities within the OS itself.
>
> You are welcome to write daemon processes that run forever on your 8GB
> RAM Web server. Please don't do it on a 192MB RAM phone.
>
> >> You have to know "how long the next sleep will be", by definition.
> >> After all, you have to tell Android when to resume operation of your
> >> code, regardless of how you accomplish it (AlarmManager,
> >> Thread.sleep(), postDelayed(), etc.).
> >
> > I don't control the user, I'm sorry.
>
> Then who is calling set() on AlarmManager to trigger your PendingIntent?
>
> -- 
> Mark Murphy (a Commons Guy)
> http://commonsware.com | http://github.com/commonsguy
> http://commonsware.com/blog | http://twitter.com/commonsguy
>
> Android Training in Oslo: http://bit.ly/fjBo24
>
>

-- 
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