Internet permission won't let application start

by The Savage Killer » Sun, 15 Mar 2009 13:13:23 GMT


Sponsored Links
 asically when i add internet permissions to my manifest file my
application refuses to even start.

03-13 18:05:59.262: DEBUG/AndroidRuntime(662): >>>>>>>>>>>>>>
AndroidRuntime START <<<<<<<<<<<<<<
03-13 18:05:59.262: DEBUG/AndroidRuntime(662): CheckJNI is ON
03-13 18:05:59.493: DEBUG/AndroidRuntime(662): --- registering native
functions ---
03-13 18:05:59.503: INFO/jdwp(662): received file descriptor 19 from
ADB
03-13 18:06:00.712: DEBUG/PackageParser(52): Scanning package: /data/
app/vmdl24071.tmp
03-13 18:06:00.862: WARN/PackageManager(52): Attempt to re-install
dev.funnyrss without first uninstalling.
03-13 18:06:00.862: INFO/installd(27): unlink /data/dalvik-cache/
d...@app@vmdl24071....@classes.dex
03-13 18:06:00.902: DEBUG/AndroidRuntime(662): Shutting down VM
03-13 18:06:00.902: DEBUG/dalvikvm(662): DestroyJavaVM waiting for non-
daemon threads to exit
03-13 18:06:00.913: INFO/dalvikvm(662): DestroyJavaVM shutting VM down
03-13 18:06:00.922: DEBUG/dalvikvm(662): HeapWorker thread shutting
down
03-13 18:06:00.922: DEBUG/dalvikvm(662): HeapWorker thread has shut
down
03-13 18:06:00.922: DEBUG/jdwp(662): JDWP shutting down net...
03-13 18:06:00.932: DEBUG/jdwp(662): +++ peer disconnected
03-13 18:06:00.932: INFO/dalvikvm(662): Debugger has detached; object
registry had 1 entries
03-13 18:06:00.952: DEBUG/dalvikvm(662): VM cleaning up
03-13 18:06:00.972: DEBUG/dalvikvm(662): LinearAlloc 0x0 used 529708
of 4194304 (12%)
03-13 18:06:01.252: DEBUG/dalvikvm(52): GC freed 5687 objects / 344760
bytes in 363ms
03-13 18:06:01.423: DEBUG/AndroidRuntime(670): >>>>>>>>>>>>>>
AndroidRuntime START <<<<<<<<<<<<<<
03-13 18:06:01.423: DEBUG/AndroidRuntime(670): CheckJNI is ON
03-13 18:06:01.653: DEBUG/AndroidRuntime(670): --- registering native
functions ---
03-13 18:06:01.672: INFO/jdwp(670): received file descriptor 19 from
ADB
03-13 18:06:02.842: DEBUG/PackageParser(52): Scanning package: /data/
app/vmdl24072.tmp
03-13 18:06:02.992: DEBUG/PackageManager(52): Removing package
dev.funnyrss
03-13 18:06:02.992: DEBUG/PackageManager(52): Activities:
dev.funnyrss.FRSS dev.funnyrss.FRSS2
03-13 18:06:03.002: DEBUG/PackageManager(52): Scanning package
dev.funnyrss
03-13 18:06:03.012: INFO/PackageManager(52): /data/app/vmdl24072.tmp
changed; unpacking
03-13 18:06:03.022: DEBUG/installd(27): DexInv: --- BEGIN '/data/app/
vmdl24072.tmp' ---
03-13 18:06:03.252: DEBUG/dalvikvm(676): DexOpt: load 41ms, verify
39ms, opt 1ms
03-13 18:06:03.262: DEBUG/installd(27): DexInv: --- END '/data/app/
vmdl24072.tmp' (success) ---
03-13 18:06:03.272: DEBUG/PackageManager(52): Activities:
dev.funnyrss.FRSS dev.funnyrss.FRSS2
03-13 18:06:03.442: INFO/installd(27): move /data/dalvik-cache/
d...@app@vmdl24072....@classes.dex -> /data/dalvik-cache/
d...@app@dev.funnyrss....@classes.dex
03-13 18:06:03.453: DEBUG/PackageManager(52): New package installed
in /data/app/dev.funnyrss.apk
03-13 18:06:03.672: DEBUG/AndroidRuntime(670): Shutting down VM
03-13 18:06:03.672: DEBUG/dalvikvm(670): DestroyJavaVM waiting for non-
daemon threads to exit
03-13 18:06:03.683: DEBUG/ActivityManager(52): Uninstalling process
dev.funnyrss
03-13 18:06:03.692: INFO/dalvikvm(670): DestroyJavaVM shutting VM down
03-13 18:06:03.692: DEBUG/dalvikvm(670): HeapWorker



Other Threads

1. What to do about all those buttons?

This is partly a rant, partly a set of suggestions, and partly an
attempt to start a discussion on how to improve a basic part of the
Android UI.  But to skip straight to the punch line: Android phones
have too many physical buttons on them, and those button don't work
very well.  Now let me back up and explain why.

When Apple designed the iPhone, they decided to completely do away
with physical buttons.  Instead, they would have a touch screen that
allowed infinitely configurable UIs.  Each application could have
whatever buttons were appropriate for it.  This was a very good idea
that worked very well in practice, but they did end up making one
exception: the Home button.  They decided that, no matter what options
an application offered at a particular time, you always needed a way
to get out of it, and the only way to guarantee that was with a
physical button.

When Google developed Android, they decided that one button might be
enough for Apple, but it wasn't enough for them.  Why?  Who knows?
Maybe they just thought more was better.  It reminds me a bit of the
mid 80s.  When Apple introduced the personal computer mouse, they made
a big point of the fact that it only had one button.  "All you need to
do is point and click."  But Microsoft decided that Windows mice would
have two buttons, and thus would be more powerful than Macintosh
mice.  And then Unix system vendors of course had to make their
computers even more powerful, so Unix mice all had three buttons!  Of
course, this didn't actually make them more powerful.  It just made
them a lot more confusing to use.

So let's look at the four buttons found on every Android device: Home,
Menu, Back, and Search.  Do they really belong there?  Do they do more
to help or hurt the user interface?

First is the Home button, the one button Apple felt was required.  I
agree with their judgement, and have nothing to say against it.  So
let's move on.

Next is the Menu button.  I can understand the logic behind it: lots
of applications need to display menus, so it makes sense to provide a
standard mechanism for bringing them up.  That sounds reasonable.  So
what's wrong with it.

Well, first there's just the fact that it's unnecessary.  If an
application wants to offer a menu, an on-screen button would work just
as well.  But much more importantly, it turns every menu into a hidden
feature.  There is absolutely no way to tell when a menu is
available.  The user needs to just happen to wonder, "Does this screen
have a menu?", then try pressing the Menu button to find out.  That is
simply a bad user interface.

What can we do about this?  It's probably too late to get rid of the
Menu button, but there are several ways to improve the situation.  One
is for developers not to rely on it.  If you want to make a menu
available, provide an on-screen button as an alternative to the Menu
button.  Another option is to establish a standard indication to tell
the user when a menu is available.  Perhaps this could be a standard
icon somewhere on the screen, or maybe the Menu button could light
up.  But users really need to be told when a menu is available.  They
shouldn't be required to guess.

Next comes the Back button.  At first glance, this seems reasonable.
The idea of a Back button is familiar to anyone who has used a web
browser, and it works very well there.  So why not here?

The problem is that the Back button doesn't actually do what people
expect it to.  Users assume the Back button means, "Take me back to
where I was before."  But it doesn't.  It actually means, "Pop the
topmost activity off the stack of the current application."  As long
as you stay within one application those are equivalent, but as soon
as you start switching between applications the behavior becomes
frustrating and unintuitive.  For example, suppose you are working
with an application.  Press the Home button to bring up the home
screen, then press Back.  You expect it to take you back to the
application you were just in, but it doesn't.  The behavior of the
Back button really needs to be reconsidered and made more rational
from a user's perspective.

Finally there's the Search button which simply has no business being
there.  I suppose this betrays Google's biases.  They're a search
company, so of course they assume that searching is one of the most
fundamental things anyone would ever want to do.  It isn't.  I would
bet that 90% of Android device owners use the search function less
often than other features of their devices, such as making phone
calls, sending text messages, or taking photos.  So why does search
need its own physical button, while a standard application is fine for
all the others?  Answer: it doesn't.  The Search button should be
eliminated.

Ok, those are my very opinionated opinions on the subject.  I'm
raising this subject because I sincerely want to help improve the
Android UI, and I believe it can be improved, and the most prominent
aspects of the UI are the place to start.

Peter

-- 

2. Stylus and Finger support for Android

After just seeing the iPad released, I noticed that there was no
stylus that comes with the device, how would you take notes?  What I
would like to see from a functional standpoint for a larger screen
platform is a set of default functions for different pointing devices
that are used.

For example if I am handwriting notes with a stylus then android is
reading it as an ink pen, but at anytime I use my finger it reads as a
pointing device and I can select, scroll, zoom etc.  No need to have
to select pen or pointer.

A quick stab at a function list.
Stylus
-default pen
-double tap - menu with pen functions

single finger
-default pointer
-tap and hold - right mouse menu features
-tap and hold and drag - select

two finger
-everything that has been brought up about multi-touch

larger than a finger - i.e. base of hand resting on the screen while
writing with a stylus
-ignored

-- 

3. Requesting the attributes from the web view in the application

4. $98 android netbook

5. Framework for backup/restore application's private data?

6. cyrket is alive again!

7. Android Tcp client-server connection.