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
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
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
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
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
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
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
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
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
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 intent-filter
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
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
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
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:
/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
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
:
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
.
On Thu, Aug 8, 2013 at 2:17 PM, Digipom Inc. digi...@gmail.com 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
, 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
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
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
--
H
On Mar 19, 2013, at 8:06 PM, Digipom digi...@gmail.com 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
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
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
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
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
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
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
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
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
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
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
On Thu, Aug 16, 2012 at 7:57 AM, Mark Murphy mmur...@commonsware.comwrote:
On Thu, Aug 9, 2012 at 11:23 AM, Digipom digi...@gmail.com 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
.
On Thu, Aug 16, 2012 at 10:29 AM, Mark Murphy mmur...@commonsware.comwrote:
On Thu, Aug 16, 2012 at 10:19 AM, Digipom Inc. digi...@gmail.com 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
34 matches
Mail list logo
