[android-developers] Re: Google Play Game Services and In-app billing
Any idea? Any thoughts? 2014. július 27., vasárnap 17:43:38 UTC+2 időpontban Tamás Kovács a következőt írta: Hello, Are there any restrictions for Game Services in terms IAB/paid apps? I can't find anything in any Terms of Use about this. For example, Game Services states that each Achievement must be achievable by the player, but it doesn't state whether this is allowed to require any In-app Billing. Most games are freemium nowadays. I can imagine it's forbidden to ask for payment for an Achievement (I'm not planning such a thing), but in freemium games, this can be much more indirect. For example, a quest might not be available without an expensive item, but that item is only available via In-app Billing. With the following, I suppose I should be safe: the Achievement is reachable in theory in the game, but very difficult to reach it (very much playing to reach the XP without In-app Purchase items). Therefore, if the player really wants it, he can reach the Achievement without any In-app Purchase. Any definitive answer in this matter? -- 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] Google Play Game Services and In-app billing
Hello, Are there any restrictions for Game Services in terms IAB/paid apps? I can't find anything in any Terms of Use about this. For example, Game Services states that each Achievement must be achievable by the player, but it doesn't state whether this is allowed to require any In-app Billing. Most games are freemium nowadays. I can imagine it's forbidden to ask for payment for an Achievement (I'm not planning such a thing), but in freemium games, this can be much more indirect. For example, a quest might not be available without an expensive item, but that item is only available via In-app Billing. With the following, I suppose I should be safe: the Achievement is reachable in theory in the game, but very difficult to reach it (very much playing to reach the XP without In-app Purchase items). Therefore, if the player really wants it, he can reach the Achievement without any In-app Purchase. Any definitive answer in this matter? -- 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] In-app billing: different prices for countries?
Hello, Something isn't clear to me. The In-App Billing Pricing says: At this time, you will be able to sell in-app items in your home currency, which is generally the currency of the country registered on your Google Play account. (Source: https://support.google.com/googleplay/android-developer/answer/1153485 ) On the other hand, there is the following page: http://developer.android.com/google/play/billing/billing_admin.html There, it shows that per-country prices can be specified for In-App Products. For different countries, due to VAT (value-added tax), I must be able to specify different prices for my in-app items. How is this possible if the first page says that home currency is allowed only? -- 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] HTC One V getExternalStorageState
Hello, getExternalStorageState() and getExternalFilesDir(null) try to access the external SD card on HTC One V. But external SD card is not always given when you buy a phone. Is this standard? Doesn't google make it mandatory that external storage must be accessible on every Android phone? HTC One V has a quite big internal storage too, I don't get it why manufacturer assigned the (missing) SD card to getExternalStorageState() API. Anyone else having this issue? Or is it only with my HTC One V? -- -- 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: HTC One V getExternalStorageState
Please, even if someone has One V and does NOT encounter this problem (i.e. internal storage is assigned to getExternalFilesDir), let me know. 2013. június 22., szombat 22:43:04 UTC+2 időpontban Tamás Kovács a következőt írta: Hello, getExternalStorageState() and getExternalFilesDir(null) try to access the external SD card on HTC One V. But external SD card is not always given when you buy a phone. Is this standard? Doesn't google make it mandatory that external storage must be accessible on every Android phone? HTC One V has a quite big internal storage too, I don't get it why manufacturer assigned the (missing) SD card to getExternalStorageState() API. Anyone else having this issue? Or is it only with my HTC One V? -- -- 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: HTC One V getExternalStorageState
Thanks for your reply. Unfortunately, my problem is exactly the opposite!! On this device, Android API returns the external SD card instead of the large in-built partition! And since SD card is not mandatory, it will not find it and my app needs it. 2013. június 23., vasárnap 0:07:46 UTC+2 időpontban Kostya Vasilyev a következőt írta: Is this yet another phone that has a large built-in memory partition -- *and* a microSD card? This has been a mess for years. Android APIs will return the large built-in memory partition as the external storage, and you're on your own trying to discover the path to microSD. https://groups.google.com/d/msg/android-developers/R4ymtcFu0O4/zxaVgnypKdwJ ( and many more messages if you search the group's archives ) -- K On Sunday, June 23, 2013 12:43:04 AM UTC+4, Tamás Kovács wrote: Hello, getExternalStorageState() and getExternalFilesDir(null) try to access the external SD card on HTC One V. But external SD card is not always given when you buy a phone. Is this standard? Doesn't google make it mandatory that external storage must be accessible on every Android phone? HTC One V has a quite big internal storage too, I don't get it why manufacturer assigned the (missing) SD card to getExternalStorageState() API. Anyone else having this issue? Or is it only with my HTC One V? -- -- 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: HTC One V getExternalStorageState
Of course I do. My problem is that if the user has no SD card put to the optional slot, my app will not install (it needs APK Expansion from Google Play). This is because getExternalStorageState() and getExternalFilesDir() will not return the internal storage unfortunately, even though my app could install there. They return the optional CD card slot on HTC One V. 2013. június 23., vasárnap 0:32:40 UTC+2 időpontban TreKing a következőt írta: On Sat, Jun 22, 2013 at 5:25 PM, Tamás Kovács falcon.f...@gmail.comjavascript: wrote: And since SD card is not mandatory, it will not find it and my app needs it. So check that the external storage exists first. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- -- 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: HTC One V getExternalStorageState
You misinterpret the issue (read my posts again) Indeed, SD card is not equal to external storage. But it CAN be, if the manufacturer decides to return it when you call getExternalFilesDir or getExternalStorageState. This is exactly my problem: in case of HTC One V, the API considers the SD card as external storage (instead of using the internal for this purpose). Therefore, users who don't have an external SD card inserted into their HTC One V will not be able to install my application. Again, this is because HTC One V assigns the SD card to getExternalFilesDir. 2013. június 23., vasárnap 1:31:57 UTC+2 időpontban RichardC a következőt írta: External Storage != SD Card (read the docs) External Storage is the part of the Android file system mounted externally when you attach the phone to a computer (via USB) and enable file sharing. It does NOT need to be the SD Card. On Saturday, June 22, 2013 11:55:14 PM UTC+1, Tamás Kovács wrote: Of course I do. My problem is that if the user has no SD card put to the optional slot, my app will not install (it needs APK Expansion from Google Play). This is because getExternalStorageState() and getExternalFilesDir() will not return the internal storage unfortunately, even though my app could install there. They return the optional CD card slot on HTC One V. 2013. június 23., vasárnap 0:32:40 UTC+2 időpontban TreKing a következőt írta: On Sat, Jun 22, 2013 at 5:25 PM, Tamás Kovács falcon.f...@gmail.comwrote: And since SD card is not mandatory, it will not find it and my app needs it. So check that the external storage exists first. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- -- 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] Google Play priced status filter ?
Quoting thishttp://developer.android.com/google/play/filters.html#other-filtersofficial Android page: Not all users can see paid apps. To show paid apps, a device must have a SIM card and be running Android 1.1 or later, and it must be in a country (as determined by SIM carrier) in which paid apps are available. Is this outdated? How users of tablets without a SIM card buy paid apps then? -- -- 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] MediaPlayer race condition of pause/PlaybackCompleted?
The official documentation about pause():
pause()
Valid states: {Started, Paused}
Invalid states: {Idle, Initialized, Prepared, Stopped,
PlaybackCompleted, Error}
Calling this method in an invalid state transfers the object to the
Error state.
How can I be safe when doing this:
if (mediaplayer.isPlaying()) {
mediaplayer.pause()
}
The player might enter PlaybackCompleted between calling isPlaying()
and pause(), i.e. pause() is still called. This is a race condition.
(The playbackcomplete listener doesn't help anything on this.)
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Dalvik and the internal width of 'short' fields
Hello, Usually, Java virtual machines are known for using int-sized width for short fields as well. Only the arrays (short[]) are exception. What about Dalvik? E.g. I have a class which contains 50 fields of type short. Sometimes in my application, 1 of these classes exist. This means that the short fields should use 1MB of memory, but if Dalvik uses 4 bytes for shorts internally, then this will be 2MB memory usage. What is the truth? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: AudioTrack: thread safety of operations?
Anyone? (to the last but one question, even) Thanks in advance On Sep 7, 2:55 am, Tamás Kovács falcon.firebre...@gmail.com wrote: And what about e.g. setStereoVolume() ? It sounds a bit strange that the current write() operation must finish before setStereoVolume() can be called, but if you say so. On Sep 7, 2:44 am, Tamás Kovács falcon.firebre...@gmail.com wrote: OK, thanks. So you're basically saying that if I want to call e.g. pause()+flush() on an AudioTrack, I need to guarantee that write() is atomic in terms of my pause() and flush() call, right? To be brief, (per the docs), only a stop() call is allowed to execute while a write() is in progress. Is this correct? On Sep 7, 2:05 am, Lew lewbl...@gmail.com wrote: Tamás Kovács wrote: The documentation says that AudioTrack.write() is thread-safe in terms of stop(). What about the other operations? As far as I can see, e.g. play() and pause() should also be callable from another thread. write() is blocking, so it does not make much sense to call pause() from the same thread as write(). Is it OK to use an own thread for write() and using the other operations (stop, pause, play) from a different thread? Nearly always, absence of a promise of thread safety is equivalent to a promise of thread unsafety. This is more likely given the care to specify that 'write()' is thread safe with respect to stop()../../../reference/android/media/AudioTrack.html#stop() calls specifically. IOW, if it was thread safe for other calls they'd've said so. We go by the docs, too, so we're unlikely to give you a different answer than the Javadocs do. -- 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
[android-developers] AudioTrack: thread safety of operations?
The documentation says that AudioTrack.write() is thread-safe in terms of stop(). What about the other operations? As far as I can see, e.g. play() and pause() should also be callable from another thread. write() is blocking, so it does not make much sense to call pause() from the same thread as write(). Is it OK to use an own thread for write() and using the other operations (stop, pause, play) from a different thread? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: AudioTrack: thread safety of operations?
OK, thanks. So you're basically saying that if I want to call e.g. pause()+flush() on an AudioTrack, I need to guarantee that write() is atomic in terms of my pause() and flush() call, right? To be brief, (per the docs), only a stop() call is allowed to execute while a write() is in progress. Is this correct? On Sep 7, 2:05 am, Lew lewbl...@gmail.com wrote: Tamás Kovács wrote: The documentation says that AudioTrack.write() is thread-safe in terms of stop(). What about the other operations? As far as I can see, e.g. play() and pause() should also be callable from another thread. write() is blocking, so it does not make much sense to call pause() from the same thread as write(). Is it OK to use an own thread for write() and using the other operations (stop, pause, play) from a different thread? Nearly always, absence of a promise of thread safety is equivalent to a promise of thread unsafety. This is more likely given the care to specify that 'write()' is thread safe with respect to stop()../../../reference/android/media/AudioTrack.html#stop() calls specifically. IOW, if it was thread safe for other calls they'd've said so. We go by the docs, too, so we're unlikely to give you a different answer than the Javadocs do. -- 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
[android-developers] Re: AudioTrack: thread safety of operations?
And what about e.g. setStereoVolume() ? It sounds a bit strange that the current write() operation must finish before setStereoVolume() can be called, but if you say so. On Sep 7, 2:44 am, Tamás Kovács falcon.firebre...@gmail.com wrote: OK, thanks. So you're basically saying that if I want to call e.g. pause()+flush() on an AudioTrack, I need to guarantee that write() is atomic in terms of my pause() and flush() call, right? To be brief, (per the docs), only a stop() call is allowed to execute while a write() is in progress. Is this correct? On Sep 7, 2:05 am, Lew lewbl...@gmail.com wrote: Tamás Kovács wrote: The documentation says that AudioTrack.write() is thread-safe in terms of stop(). What about the other operations? As far as I can see, e.g. play() and pause() should also be callable from another thread. write() is blocking, so it does not make much sense to call pause() from the same thread as write(). Is it OK to use an own thread for write() and using the other operations (stop, pause, play) from a different thread? Nearly always, absence of a promise of thread safety is equivalent to a promise of thread unsafety. This is more likely given the care to specify that 'write()' is thread safe with respect to stop()../../../reference/android/media/AudioTrack.html#stop() calls specifically. IOW, if it was thread safe for other calls they'd've said so. We go by the docs, too, so we're unlikely to give you a different answer than the Javadocs do. -- 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
[android-developers] openRawResource: does compressed files in APK get uncompressed completely?
Hello, I have a custom file format in res/raw, which means it will get compressed in APK. Question: Assume my application is installed on the device. When I open a file via openRawResource(), does it completely uncompress the file in the memory? E.g. if it's a 3MB file, will it uncompress it in memory? If I only need 10KB data from a certain offset (and I reach it via BufferedInputStream.skip), will it still consume 3MB when openRawResource() is called? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: openRawResource: does compressed files in APK get uncompressed completely?
Thanks, Dianne. Was the 1MB limitation removed in case of *assets* as well, or only for *resources*? On Aug 22, 12:28 am, Dianne Hackborn hack...@android.com wrote: Prior to I think Gingerbread, it would entirely uncompress in memory with a limit on the amount of memory it would use (I think 1MB) above which the open would fail. On current versions of the platform it uncompression is streamed as you read it with no limit on size. On Tue, Aug 21, 2012 at 1:25 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: Hello, I have a custom file format in res/raw, which means it will get compressed in APK. Question: Assume my application is installed on the device. When I open a file via openRawResource(), does it completely uncompress the file in the memory? E.g. if it's a 3MB file, will it uncompress it in memory? If I only need 10KB data from a certain offset (and I reach it via BufferedInputStream.skip), will it still consume 3MB when openRawResource() is called? -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: SKIA FimgApiStretch:stretch failed
Anyone? It happens on ICS, Samsung Galaxy S3. The ScaleAnimation stutters when I get it. On Thursday, July 26, 2012 2:09:51 AM UTC+2, Tamás Kovács wrote: My app keeps gets this error message often in logcat under the SKIA tag: FimgApiStretch:stretch failed On some screens, it is contionously being logged, all the time. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] SKIA FimgApiStretch:stretch failed
My app keeps gets this error message often in logcat under the SKIA tag: FimgApiStretch:stretch failed On some screens, it is contionously being logged, all the time. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] System.gc() causing slowdown from the second start of Activity
I know that System.gc() is needless and discouraged, and I don't try
to suggest otherwise, but the point is that it shouldn't cause issues
either (i.e. it should be useless at most).
If I add the following code to my Activity.onPause(), then my
application will be slow after the second start of the activity:
if (isFinishing()) {
System.gc();
}
I.e. the framerate in my GLSurfaceView will be reduced by 50%. If I
remove the System.gc() call, everything is totally fine, no matter how
many times I start the activity again (i.e. start it again after it
was finished()).
The relevant source codes here:
http://stackoverflow.com/questions/11601914/system-gc-causing-slowdown-from-the-second-start-of-activity
Please help! GC is discouraged but shouldn't mess up the View/Layout
destroying system of 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
[android-developers] Re: System.gc() causing slowdown from the second start of Activity
Do you mean TraceView?
I tried with Debug.startAllocCounting, Debug.startMethodTracking(...),
made a lot of reports, but the result is the same:
practically same % spent in all methods. Just everything is slower in
absolute time during the GLSurfaceView rendering.
For example, the GL effects I use take more time, but the distribution
of method times is exactly the same. To be brief, everything is
slower, proportionally.
Memory allocation is fine, no leak, no increase in heap...
On Jul 22, 7:17 pm, RichardC richard.crit...@googlemail.com wrote:
Run the profiler.
On Sunday, July 22, 2012 5:41:55 PM UTC+1, Tamás Kovács wrote:
I know that System.gc() is needless and discouraged, and I don't try
to suggest otherwise, but the point is that it shouldn't cause issues
either (i.e. it should be useless at most).
If I add the following code to my Activity.onPause(), then my
application will be slow after the second start of the activity:
if (isFinishing()) {
System.gc();
}
I.e. the framerate in my GLSurfaceView will be reduced by 50%. If I
remove the System.gc() call, everything is totally fine, no matter how
many times I start the activity again (i.e. start it again after it
was finished()).
The relevant source codes here:
http://stackoverflow.com/questions/11601914/system-gc-causing-slowdow...
Please help! GC is discouraged but shouldn't mess up the View/Layout
destroying system of 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
[android-developers] Re: System.gc() causing slowdown from the second start of Activity
In fact, traceview seems to report IDENTICAL times absolutely too,
which is strange, because if I use SystemClock.uptimeMillis() for
measurent, then I get higher values. And REALITY shows too that
methods take more time. But traceview reports contain same absolute
values --- I guess because traceview already reduces FPS, so the
results are not credible as absolute values. And as percents, they are
the same.
On Jul 22, 7:29 pm, Tamás Kovács falcon.firebre...@gmail.com wrote:
Do you mean TraceView?
I tried with Debug.startAllocCounting, Debug.startMethodTracking(...),
made a lot of reports, but the result is the same:
practically same % spent in all methods. Just everything is slower in
absolute time during the GLSurfaceView rendering.
For example, the GL effects I use take more time, but the distribution
of method times is exactly the same. To be brief, everything is
slower, proportionally.
Memory allocation is fine, no leak, no increase in heap...
On Jul 22, 7:17 pm, RichardC richard.crit...@googlemail.com wrote:
Run the profiler.
On Sunday, July 22, 2012 5:41:55 PM UTC+1, Tamás Kovács wrote:
I know that System.gc() is needless and discouraged, and I don't try
to suggest otherwise, but the point is that it shouldn't cause issues
either (i.e. it should be useless at most).
If I add the following code to my Activity.onPause(), then my
application will be slow after the second start of the activity:
if (isFinishing()) {
System.gc();
}
I.e. the framerate in my GLSurfaceView will be reduced by 50%. If I
remove the System.gc() call, everything is totally fine, no matter how
many times I start the activity again (i.e. start it again after it
was finished()).
The relevant source codes here:
http://stackoverflow.com/questions/11601914/system-gc-causing-slowdow...
Please help! GC is discouraged but shouldn't mess up the View/Layout
destroying system of 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
[android-developers] Activity always starting in 2 instances on ZTE Skate
I have two activities: a Preload activity and the main activity. My preload activity basically just spawns the main activity and then exits. My problem appears only on ZTE Skate (all other devices work fine). When I start my application by tapping its icon, the logcat output of my application is duplicated. Each log line appears twice, but at different times. I read some topics on stackoverflow that assume it's only a logcat issue (and adb should be reset to solve it), but later, my main activity dies with a bitmap size exceeds VM_BUDGET error. This is probably because both activities are runnning at the same time, so memory gets low when it loads bitmaps. The VM_BUDGET error does not appear on any other devices, including HTC Desire, Samsung Galaxy Mini etc. As a trial error, I tried the FLAG_ACTIVITY_CLEAR_TOP flag for the Intent, but no success. I haven't tried the singleTask launch mode yet, but actually I don't think the behavior is correct anyway on ZTE Skate. Therefore, I would like to understand why double spawning happens. (The other possibility is that I've two independent errors: double logcat output anomaly, plus VM_BUDGET error. The problem is, I get no VM_BUDGET errors on other devices at all, and e.g. HTC Desire is not a better device than ZTE Skate so I doubt it's a memory leak or similar issue.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Infinite loop bug in GLSurfaceView (up to present version)?
Hello,
Reproducing the bug: instantiate and add a GLSurface, then set the
interrupted status of your UI thread, and then use removeView to
detach the GLSurface.
To be brief, I think I found a bug, because GLSurfaceView.GLThread
uses the following pattern in its requestExitAndWait() method:
while (!mExited) {
try {
sObject.wait();
} catch (InterruptedException ex) {
Thread.currentThread().interrupt();
}
}
requestExitAndWait() is called by the UI thread when you detach your
GLSurface. If your UI thread already has interrupted() status for some
reason (e.g. someone handled an interrupt via
currentThread().interrupt()), then the Android code will cause an
infinite loop, because sObject.wait() will never release the sObject
monitor (due to the exception handler), and thus the GL thread will
never be able to set mExited to true.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Infinite loop bug in GLSurfaceView (up to present version)?
Actually, the situation is worse, because this bug appears when you
start your rendering, too.
Details here as well:
http://stackoverflow.com/questions/11220572/handling-interruptedexception-while-waiting-for-an-exit-signal-bug-in-android
On Jun 28, 1:16 pm, Tamás Kovács falcon.firebre...@gmail.com wrote:
Hello,
Reproducing the bug: instantiate and add a GLSurface, then set the
interrupted status of your UI thread, and then use removeView to
detach the GLSurface.
To be brief, I think I found a bug, because GLSurfaceView.GLThread
uses the following pattern in its requestExitAndWait() method:
while (!mExited) {
try {
sObject.wait();
} catch (InterruptedException ex) {
Thread.currentThread().interrupt();
}
}
requestExitAndWait() is called by the UI thread when you detach your
GLSurface. If your UI thread already has interrupted() status for some
reason (e.g. someone handled an interrupt via
currentThread().interrupt()), then the Android code will cause an
infinite loop, because sObject.wait() will never release the sObject
monitor (due to the exception handler), and thus the GL thread will
never be able to set mExited to true.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Instantiating (but not attaching!) a View from a non-UI thread
I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
It works seamlessly like a charm. It would be nice to know if this is supported/acceptable generally. I hope we'll get an answer from the Android guys/ladies. On Jun 26, 10:53 pm, Justin Anderson magouyaw...@gmail.com wrote: I'm not sure, but I doubt it... Have you tried it? Did it work? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- 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 post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
OK I made additional research and source code exploring: only *ViewGroup* and its descendants check the Thread, the *View* class does not. It does not even STORE the thread which created it. Based on this, it should be safe to create Views (but never Viewgroups) in different threads. It would be nice if Dianne or Romain could confirm this. On Jun 26, 10:53 pm, Justin Anderson magouyaw...@gmail.com wrote: I'm not sure, but I doubt it... Have you tried it? Did it work? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- 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 post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
Thanks, Dianne, and others. This is what I needed to know. I know I can async preload Drawables and Bitmaps (there is an official tutorial, too), but it seems that my custom View is so complex that it takes 1 second to instantiate (even if its drawables are preloaded). And I need to *instantly* appear when the Activity is displayed that uses it. This is the reason I preinstantiate my View to a static (yes, I take care to null it out, so there will be no leak). Assume I have Activity A and B. Is the below solution allowed then (all in UI thread, just at different times): 1. From Activity A: sStaticVar = new MyCustomView(this.getApplicationContext()) 2. From Activity B onCreate(): mRootLayout.addChild(sStaticVar); // instead of addChild(new MyCustomView(this)) or new MyCustomView(getApplicationContext()) In this way, each time Activity B is must be displayed, it will display instantly. My SystemClock measurements seem to confirm this. On Jun 27, 12:23 am, Dianne Hackborn hack...@android.com wrote: No, it is not safe. Don't do this. The documentation is very clear about this:http://developer.android.com/reference/android/view/View.html Note: The entire view tree is single threaded. You must always be on the UI thread when calling any method on any view. This wasn't written to mislead people into thinking that it works a different way than it does: it is because it is true, the view hierarchy is single-threaded, and it is explicitly not designed to be used from multiple threads. If you think that not seeing checks about which thread calls are being made on indicates that something is safe to use from multiple threads, you should probably stop whatever multi-threaded programming you are doing and rethink it. :} Even instantiating a view from one thread and attaching it to a view hierarchy in another is not safe, because many views will internally create Handler objects that are bound to whatever thread they were created on, causing you to have parts of your view hierarchy running on the wrong thread with bad results. On Tue, Jun 26, 2012 at 2:00 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: It works seamlessly like a charm. It would be nice to know if this is supported/acceptable generally. I hope we'll get an answer from the Android guys/ladies. On Jun 26, 10:53 pm, Justin Anderson magouyaw...@gmail.com wrote: I'm not sure, but I doubt it... Have you tried it? Did it work? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- 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 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
Thanks, Boston, that's a good idea. I'll try to split my custom View to smaller pieces, isolating the View-independent parts. @Romain: thanks, we'll keep that in mind. On Jun 27, 12:26 am, Streets Of Boston flyingdutc...@gmail.com wrote: I would still advise against it, because you don't have control of the code after you call the constructor of the View. Creating a View should never be that expensive (i.e. time consuming) that it could not be done on the UI thread. If the creation of the View needs other pieces of data that are expensive to compute, just compute those pieces of data in the background thread and create the View in the UI thread after that, giving it the earlier computed data. On Tuesday, June 26, 2012 6:04:44 PM UTC-4, Tamás Kovács wrote: OK I made additional research and source code exploring: only *ViewGroup* and its descendants check the Thread, the *View* class does not. It does not even STORE the thread which created it. Based on this, it should be safe to create Views (but never Viewgroups) in different threads. It would be nice if Dianne or Romain could confirm this. On Jun 26, 10:53 pm, Justin Anderson magouyaw...@gmail.com wrote: I'm not sure, but I doubt it... Have you tried it? Did it work? Thanks, Justin Anderson MagouyaWare Developerhttp://sites.google.com/site/magouyaware On Tue, Jun 26, 2012 at 2:27 PM, Tamás Kovács falcon.firebre...@gmail.comwrote: I know that the UI elements (View hierarchy) may only be manipulated from the UI thread. For a background operation, the AsyncTask can be used, which offers event handers to reach the UI thread. To be brief, is it allowed to instantiate a View (tied to getApplicationContext()) in a non-UI thread? This custom View descendant -- once instantiated -- is added to the view hierarchy from the UI thread. So only the constructor call is done inside an Asynctask.doInBackground; its attaching (addView(...))to the Activity's root layout hierarchy is still done in the UI thread. (I pre-instantiate the View in an asynctask because when it's needed in an Activity, it must be instantly displayed.) -- 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 post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Instantiating (but not attaching!) a View from a non-UI thread
On a side note: Note: The entire view tree is single threaded. You must always be on the UI thread when calling any method on any view. This wasn't written to mislead people [..]: it is because it is true True, any method means the constructor too, since the constructor is practically method too. The thing that confused me that the doc implies that the rule applies methods on EXISTING views (on any way), and does not state anything about their CONSTRUCTION (instantiation). Moreover, for the beginner eye, at the first glance, the concept of AsyncDrawable may also be confusing: the AsyncDrawable is not instantiated async (it's created on the UI thread), it's called async because its contents (Bitmap) is loaded asynchronously. http://developer.android.com/training/displaying-bitmaps/process-bitmap.html -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] MediaPlayer.pause() in PlaybackCompleted state?
The official documentation about pause():
pause()
Valid states: {Started, Paused}
Invalid states: {Idle, Initialized, Prepared, Stopped,
PlaybackCompleted, Error}
Calling this method in an invalid state transfers the object to the
Error state.
In the practice, pause() works in the PlaybackCompleted state. I know
that the SDK documentation should be followed in questionable cases,
but in this case, I think it's a problematic issue because you have no
way to know synchronously whether the PlaybackCompleted state is
reached. Therefore, pause() cannot be safely called without making
sure it's not in PlaybackCompleted yet.
I know source code is not public API (that can be relied on for
decisions), so just as an interesting note, the MediaPlayer::pause()
implementation in Android is this:
if (mCurrentState (MEDIA_PLAYER_PAUSED|
MEDIA_PLAYER_PLAYBACK_COMPLETE))
return NO_ERROR;
I.e. it also follows the logical decision that a pause() shouldn't
hurt in playbackComplete. So what is with documentation?!
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: soundpool looping problem
Sorry I don't have time to read your code. But in the past, I also had
issues, when I needed to loop soundpool sounds that were stopped()
before they needed to play again (in looped mode).
If you can't find a solution, I can think of two alternatives:
1. Implement manual looping: not too elegant and accurate, but 'guess'
when you playback has ended, and then start the same sound again
2. Use MediaPlayer, it is stable in looping
On Jun 11, 5:51 am, krishna kumar send2mess...@gmail.com wrote:
package my.app.exp5;
import java.util.HashMap;
import android.content.Context;
import android.media.AudioManager;
import android.media.SoundPool;
import android.util.Log;
public class SoundEffects {
public boolean released=false;
protected Context context;
private SoundPool soundPool;
private int volume;
private HashMapInteger, Integer soundPoolMap;
protected SoundEffects(Context context) {
this.context=context;
soundPool=new SoundPool(20, AudioManager.STREAM_MUSIC, 40);
soundPoolMap = new HashMapInteger, Integer();
AudioManager mgr=(AudioManager)context.getSystemService
(Context.AUDIO_SERVICE);
volume=mgr.getStreamVolume(AudioManager.STREAM_MUSIC);
}
/*
public boolean isLoaded() {
soundPool.
}
*/
public void addSound(int resid) {
int soundId=soundPool.load(context, resid, 1);
soundPoolMap.put(resid, soundId);
soundPool.setLoop(soundId, 1);
}
public void addLoopSound(int resid) {
int soundId=soundPool.load(context, resid, 1);
soundPoolMap.put(resid, soundId);
soundPool.setLoop(soundId, -1);
}
public void play(int resid) {
Log.i(SoundEffects, Playing: +resid);
int soundId=soundPoolMap.get(resid);
soundPool.setLoop(soundId, 1);
soundPool.play(soundId, volume, volume, 1, 0, 1f);
}
public void playLoop(int resid) {
int soundId=soundPoolMap.get(resid);
soundPool.setLoop(soundId, -1);
soundPool.play(soundId, volume, volume, 1, -1, 1f); // here
loop -1 is not working
}
public void stop(int resid) {
soundPool.stop(resid);
int soundId=soundPoolMap.get(resid);
soundPool.setLoop(soundId, 0);
soundPool.setVolume(soundId, 0f, 0f);
}
public void release() {
released=true;
soundPool.release();
}
public void autoPause(int resid)
{
soundPool.autoPause();
}
}
Looping function not working please anybody help .it's urgent
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] XML vs. setImageDrawable after setContentView()
Hello, If I set the src attribute of an ImageView in the layout XML, it will know the image *before* setContentView(R.layout.main) is called. If I omit the src attribute, because the image is preloaded programmatically, then I can only call mImageViewDrawable.setImageDrawable or setImageBitmap *after* setContentView() is called. Is the result the same? Or since the image is set *after* setContentView(), are some Android scaling/etc. skipped because of this (which are normally performed when the resource is specified in XML) ? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] RandomAccessFile and file system buffer
I know that RandomAccessFile does not use buffering (and unlike in case of FileInputStream, it obviously cannot be combined with BufferedInputStream). I need to read many small chunks of data from random file positions (which can't be sorted, as they arrive continously), so RandomAccessFile sounds ideal. My question: the filesystem still does some buffering, doesn't it? So, while I shouldn't strictly rely on it, I can still expect that reads that are close to each won't reach the hardware, will they? (assuming that reading is block-based, so the filesystem can buffer the blocks that were read) My application can be installed both on the SD card and on the phone memory of Android devices. Android is based on linux, but I don't know how filesystem buffering works and whether it depends on if the read was from phone memory or the SD card. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Pre- and post-HONEYCOMB: bitmap heap?
I'm developing a graphics-intensive application for Android 2.2 and above. I know that starting with Honeycomb, bitmaps are stored on VM_HEAP instead of their native bitmap heap. Does this influence the effective memory usage of my application? I mean, e.g., if my app for pre-Honeycomb devices uses X MB of the VM heap, and has Y MB bitmaps (stored on native heap), then I hope it won't start using X+Y MB from the VM heap if it's installed on a Honeycomb or newer device. This does not sound logical. Instead, I guess that bitmap size is counted against the VM limits even prior to Honeycomb, otherwise why would bitmap size exceeds VM budget errors appear? So they're stored on their native heap but still counted against VM_HEAP size maximum). -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Pre- and post-HONEYCOMB: bitmap heap?
Just for the information of readers here, the question was answered by Romain Guy on the other mailing list. The answer is that the app will use the same amount of memory both on pre-Honeycomb and on Honeycomb and above. On máj. 20, 20:10, Tamás Kovács falcon.firebre...@gmail.com wrote: I'm developing a graphics-intensive application for Android 2.2 and above. I know that starting with Honeycomb, bitmaps are stored on VM_HEAP instead of their native bitmap heap. Does this influence the effective memory usage of my application? I mean, e.g., if my app for pre-Honeycomb devices uses X MB of the VM heap, and has Y MB bitmaps (stored on native heap), then I hope it won't start using X+Y MB from the VM heap if it's installed on a Honeycomb or newer device. This does not sound logical. Instead, I guess that bitmap size is counted against the VM limits even prior to Honeycomb, otherwise why would bitmap size exceeds VM budget errors appear? So they're stored on their native heap but still counted against VM_HEAP size maximum). -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: surface (identity=xxxxx) is invalid, err=-19 (no such device)
It happens exclusively when I suddenly turn off the display when my app is started again, i.e. the sequence is something like: Activity.onStart() - Activity.onResume() - GLSurfaceView.onResume() - Activity.onPause() - GLSurfaceView.onPause() - Surface is invalid (no such device) in log An assumption: GlSurfaceView cannot be repainted because it's still paused. In other words, it is tried to be repainted by the system when the GLSurfaceView is already paused. I guess this is the phenomena mentioned by Fredrik Lanker (Sony Ericsson) in July 2011: http://markmail.org/message/l7ffpanbpozs6nu7 The only difference is that my GLSurfaceView is paused for a different reason (which is irrelevant). Can I ignore it? On máj. 19, 06:32, Yan yinor...@gmail.com wrote: At what exact points in your code does this happen? On May 17, 9:55 pm, Tamás Kovács falcon.firebre...@gmail.com wrote: This is a logcat ERROR entry which I get in 3 (three) instance at the same time, but the game I develop works fine. I'm just worried because this is an error, not a warning. I get the 3 identical entries when my game screen (GLSurface) is resumed due to Activity.onResume(). The screen behavior is absolutely fine in the same practice. Details: my game is subject to GLSurfaceView.onResume() as well as orientation change (i.e. it's set to landscape in the manifest and in configchanges, but obviously Android needs to change orientation to landscape when I return from my home screen to the game). So I get the error shortly after the GL thread is resumed (during texture reloading). Should I worry? It's an Error, after all. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] surface (identity=xxxxx) is invalid, err=-19 (no such device)
This is a logcat ERROR entry which I get in 3 (three) instance at the same time, but the game I develop works fine. I'm just worried because this is an error, not a warning. I get the 3 identical entries when my game screen (GLSurface) is resumed due to Activity.onResume(). The screen behavior is absolutely fine in the same practice. Details: my game is subject to GLSurfaceView.onResume() as well as orientation change (i.e. it's set to landscape in the manifest and in configchanges, but obviously Android needs to change orientation to landscape when I return from my home screen to the game). So I get the error shortly after the GL thread is resumed (during texture reloading). Should I worry? It's an Error, after all. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Clipping mask with a shape of a circular sector
I need to create a clipping mask with a shape of a circular sector. I am able to draw one using the following: paint.setColor(0x88FF); paint.setStyle(Style.FILL); canvas.drawArc(oval, 0, 30, true, paint); I want to use it as a clipping path, so I've tried: Path path = new Path(); path.addArc(oval, 0, 30); canvas.clipPath(path, Op.REPLACE); However addArc doesn't have the useCenter parameter so what I get is not a sector but a segment. Any ideas? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Circular sector shaped clipping mask with Path.addArc?
I need to create a clipping mask with a shape of a circular sector. I am able to draw one using the following: paint.setColor(0x88FF); paint.setStyle(Style.FILL); canvas.drawArc(oval, 0, 30, true, paint); I want to use it as a clipping path, so I've tried: Path path = new Path(); path.addArc(oval, 0, 30); canvas.clipPath(path, Op.REPLACE); However addArc doesn't have the useCenter parameter so what I get is not a sector but a segment. -- 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
