Rasmus, yes.
I was very put off by Ubuntu Touch suspending (eg: commands running in the
Terminal app) every time the device locked.
For 8 years now with their Maemo sdk Nokia provided to developers an easy
pathway to battery-friendly media/dsp services, alarms/rtc, cell/gps location
services, e
I agree with the original poster that the current lifecycle model is too
strict (if I have even understood it correctly by the various descriptions
in this mailing list).
I do understand the need to control running applications in devices running
on battery. But still, the current approach seems t
>I do disagree with requiring the user to interact with the system to
>ensure longer battery life. We should try as hard as possible to make
>this automagically work.
>For a tech-savvyy audience: Yes. For everyday users I do disagree. In
>the end, users do blame the platform for bad battery life (
On Tue, 2013-10-22 at 16:50 +0200, Martin Fasani wrote:
> Possible to use any application to open an OSM Open streets map ?
>
If there's ready when you go, the OSM webapp in the store seems to cache
the map tiles, so I was able to use it to a limited extent without
internet access.
signature.asc
On Tuesday 22 October 2013 16:50:14 Martin Fasani wrote:
> All looks quite good guys. Impressed!
>
> Question:
> I would love to have an offline map when I get lost in Berlin:
> http://downloads.cloudmade.com/europe/western_europe/germany/berlin#download
> s_breadcrumbs
>
> *Possible to use any a
All looks quite good guys. Impressed!
Question:
I would love to have an offline map when I get lost in Berlin:
http://downloads.cloudmade.com/europe/western_europe/germany/berlin#downloads_breadcrumbs
*Possible to use any application to open an OSM Open streets map ?*
I use Quantum GIS in Deskto
On Mon, 2013-10-21 at 18:28 -0500, Israel wrote:
> I may have been too brief in my initial e-mail.
No, I misread it. :-) Glad Luke was able to help though!
Ted
signature.asc
Description: This is a digitally signed message part
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to
Pulling in Zoltan, Daniel and David for comment
On 10/22/2013 05:40 AM, Thomas Voß wrote:
> On Tue, Oct 22, 2013 at 12:33 PM, John Lea wrote:
>> From a design point of view, the guidance we are currently following is:
>>
>> - Only the app in the foreground when the phone is unlocked is guaranteed
Modern OS requires silent background processes, of course. Listening music,
checking email, tracking position and so on - all of it requires services
(daemons). And why do you afraid to write qt based C++ class for service? I
think that we must be pragmatic - QML is only gui declarative language
On Tue, Oct 22, 2013 at 8:06 AM, Alberto Mardegan <
alberto.marde...@canonical.com> wrote:
> The case of an application using the GPS is interesting. The nice
> thing here is that the system can know that the GPS is on and that the
> application is listening to it, so it could let the application
On Tue, Oct 22, 2013 at 1:17 PM, Michael Zanetti
wrote:
> Hi,
>
> my point of view is still that forcing every little small app to bring its own
> daemon will:
>
> a) scare off people for writing apps for our platform as the communication
> overhead between a service and the UI is a huge effort an
On Monday 21 October 2013 17:46:06 Jamie Strandboge wrote:
> Recently someone asked me about adding an apparmor policy group for qtpowerd
> so that apps could stop application lifecycle from suspending the app. I
> said to file a bug and I'd look at it because I was thinking this seemed
> reasonabl
Hi,
my point of view is still that forcing every little small app to bring its own
daemon will:
a) scare off people for writing apps for our platform as the communication
overhead between a service and the UI is a huge effort and easy to mess up.
b) be suicide in terms of battery usage. This w
On Tue, Oct 22, 2013 at 11:45 AM, Rasmus Eneman wrote:
> Some thoughts:
> There definitely are legitimate reasons to let apps run in the background.
> A game on Android I like very much is Turf, it uses the GPS to track you
> when you goes around and take "zones". While playing, I usually listens
On Tue, Oct 22, 2013 at 12:33 PM, John Lea wrote:
> From a design point of view, the guidance we are currently following is:
>
> - Only the app in the foreground when the phone is unlocked is guaranteed to
> be running.
>
> - In all cases where an app requires functionality that needs to run in th
From a design point of view, the guidance we are currently following is:
- Only the app in the foreground when the phone is unlocked is
guaranteed to be running.
- In all cases where an app requires functionality that needs to run in
the background and/or while the phone is locked, this funct
Some thoughts:
There definitely are legitimate reasons to let apps run in the background.
A game on Android I like very much is Turf, it uses the GPS to track you
when you goes around and take "zones". While playing, I usually listens
to music. And bam, a common use case where we want two apps in t
Ok, thank you, I confirm that I always do in other order...
Regards,
François
2013/10/22 Oliver Grawert
> hi,
> Am Montag, den 21.10.2013, 20:09 +0200 schrieb François Leblanc:
>
> > I've copied android-ramdisk to /boot and now step is passed. I've a
> > black screen but it is in progress sin
Hi,
due to popular request here the bandaid landing process for the next
couple days (until we meet in oakland):
1. Debian Imports:
- autoflowing under tight supervision of foundations and release team
- we will hold the line once we encounter regressions
2. core-dev:
- upload o
On 10/22/2013 09:59 AM, Thomas Voß wrote:
> Along the same lines of the metronom app: If the gps app is in
> foreground, the location service should signal to powerd that it
> should not suspend at least the gps, probably the network, CPU (and
> thus, memory access).
Why does it matter if the app
Hi Martin,
can you please fetch the syslog after reproducing the issue and create a bug
report for NetWorkmanager on launchpad.net?
adb pull /var/log/syslog
If possible, please also try it with another WiFi access point and see if the
same issues happens. This sounds like it could be related t
hi,
Am Montag, den 21.10.2013, 20:09 +0200 schrieb François Leblanc:
> I've copied android-ramdisk to /boot and now step is passed. I've a
> black screen but it is in progress since I don't fall back to adb...
>
>
> I've not read that android-ramdisk should be put on /boot, perhaps I
> missed so
This is the system info:
$ cat /system/build.prop
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=JDQ39E
ro.build.display.id=cm_mako-userdebug 4.2.2 JDQ39E 20131006-1510-0ubuntu6
test-keys
ro.build.version.incremental=20131006-1510-0ubuntu6
Device is Nexus 4.
All this worked
On Mon, Oct 21, 2013 at 11:53 PM, Thomas Voß wrote:
> Trying to distill the use-case/issue we want to solve here:
> Applications running in the foreground, that is, of immediate interest
> to the user should be able to prevent the system from going into
> sleep/deep sleep.
Yes, including when the
On Tue, Oct 22, 2013 at 8:06 AM, Alberto Mardegan
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/22/2013 01:46 AM, Jamie Strandboge wrote:
>> I think we may be too strict on this. Consider the following apps:
>> * a metronome app for musicians to practice to (2 are in the app
>
25 matches
Mail list logo
