i like tacos posted:

So I'm following the steps on developer.android.com and I can't get past this. It says my Android support library is out of date so I click Install/Upgrade and it doesn't work. It says it fails to create that path. Also when I try to download the extras in the Android SDK it just says access denied. Am I doing something wrong? Is there anything I can do to fix it?

Sereri posted:

You should reinstall the sdk, it installs to AppData nowadays.

Mogomra posted:

I've been trying to do just that on a fresh install of Windows 7 on and off for the past couple days. The installer refuses to recognize that I have JDK installed.

My PATH variable has "C:/Program Files/Java/jdk1.7.0_07/bin" in it, just for good measure, I've created a JAVA_HOME variable with the same thing. When I'm in any windows command line and I type "java -version" it outputs

code:

java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)

So what gives? All my searching only gives me results where people say "Add java to your PATH variable" and "create a JAVA_HOME variable."

Is there some issue with JDK 1.7.0_07 and the newest version of ADK? I've never had any trouble installing it before...

Mogomra posted:

I've been trying to do just that on a fresh install of Windows 7 on and off for the past couple days. The installer refuses to recognize that I have JDK installed.

My PATH variable has "C:/Program Files/Java/jdk1.7.0_07/bin" in it, just for good measure, I've created a JAVA_HOME variable with the same thing. When I'm in any windows command line and I type "java -version" it outputs

code:

java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)

So what gives? All my searching only gives me results where people say "Add java to your PATH variable" and "create a JAVA_HOME variable."

Is there some issue with JDK 1.7.0_07 and the newest version of ADK? I've never had any trouble installing it before...

Spraynard Kruger posted:

If this bug is still in the installer with 64-bit Windows, hit Back at the screen where it says it can't find a JDK, then Next and it'll magically find one!

Sereri posted:

Drop the /bin from the path and it should work

Mr. Crow posted:

This thread doesn't see much activity... is Android that bad to work on or what?

I posted:

Mr. Crow posted:

Somewhat related, going to start trying my hand at Android development, is Eclipse + the Plugin the prefered way or is there an IntelliJ equivilent? I use Resharper at work and absolutely love it so I feel comfortable just jumping in and buying it, JetBrains does good work. Not really a point though if it's going to be a huge hassle to work on Android stuff in IntelliJ though.

Mr. Crow posted:

This thread doesn't see much activity... is Android that bad to work on or what?

Somewhat related, going to start trying my hand at Android development, is Eclipse + the Plugin the prefered way or is there an IntelliJ equivilent? I use Resharper at work and absolutely love it so I feel comfortable just jumping in and buying it, JetBrains does good work. Not really a point though if it's going to be a huge hassle to work on Android stuff in IntelliJ though.

Thermopyle posted:

Android development isn't wonderful by any means,

Thermopyle posted:

but I don't think it has anything to do with the activity level in this thread. I mean, it's apparent that Android development is wide-spread, I think its just that there's better resources for getting help a lot of the time.

Glimm posted:

I should probably update the OP more often as it seems like useful Android libraries are popping up every week.

Glimm posted:

Doctor w-rw-rw- your post of horrors gives me a sad. Supporting older OS versions is probably the most frustrating part of Android development.

Doctor w-rw-rw- posted:

But yeah. This is Android for you. Years of bullshit you'll never escape, fixes that stare you in the face and tantalize you with their presence only on high version numbers, and compatibility libraries that bridge some of the gap.

Thermopyle posted:

That would be something I'd like to see more posts about. I always miss out on new libraries until they've been out for 2 years or something.

Glimm posted:

OAK - "OAK is a powerful kit of tools and components to use in your Android project (Compatible with API Level 8+)" (image caching, pinned header list view, section adapter, auto-resizing textview,, encrypted shared prefs, some other stuff).

Glimm posted:

awesome

Doctor w-rw-rw- posted:

stuff

Thermopyle posted:

Awesome and accurate-ish. I don't do Android for a living, but I think I've touched all of those problems at least once.

I mostly solve the Android headaches by not caring about anyone not running a new Nexus device!

Doctor w-rw-rw- posted:

Android-unused-resources is great. However, and without trying to paint the strokes too broadly, I'm going to go out on a limb and say most of us don't use most of these extra libraries if we do Android for a living. Have you tried building an app with lots of libraries? Here's what can happen:

quote:

* Android tools update. You decide to update. Guess what? they changed the directory libraries go in without telling you. It's now libs/ instead of lib/.

Geekner posted:

Definitely going to give this one a try, been looking for a decent image caching solution.

Glimm posted:

I haven't personally used OAK yet so I'm not sure how it handles, but I've used AQuery in the past and it's fantastic. I'd probably try that first unless you're interested in other features OAK provides as well.

Geekner posted:

I recently did a fresh install of the SDK on a new system, and I gotta say the hardware-accelerated Intel emulator is really loving sweet. I'm able to run Awful with gifs playing at full speed. No extra effort unless you run native code (then you have to add the intel build target).

Just make sure to actually run the HAX installer in the extras folder.

I don't think the actual atom-based devices will catch on very well, but at least Intel put some serious effort into their emulator module.

Xav posted:

I'm happy to announce that the first milestone of our new Android SDK build system is now available to try.

Warning/Disclaimer: this is a (very) early access and is not meant to replace the existing one to ship applications.

We are looking for feedback on the build system and its features.

Current limitations of milestone1 (version 0.1):

• No support for Renderscript
  
• No support of NDK
  
• No support for Proguard
  
• No Lint integration
  
• No emma support
  
• JUnit output is only in the console
  
• Location of source folders isn't corrently customizable.
  
• Binary packaging of library is still going through changes. Do not upload libraries to maven central (or other similar repos) just yet.
  

Glimm posted:

Yeah it's pretty awesome. Before an official x86 emulator was around I'd sometimes use the Google TV emulator just to mess with something where the speed wasn't abominable.

In Android news for the day Android's new build system has been officially announced and is at version 0.1, yay!

https://plus.google.com/109385828142935151413/posts/XnW7t9XJCMJ
http://tools.android.com/tech-docs/new-build-system

quote:

When it comes to learning Android, it’s amazing how easy it is to find tutorials, code samples, and documentation to immerse yourself into the world of Android. Interestingly, I’ve found the inverse to be true for the, dare I say, way cooler world of hacking Android. Reverse engineering Android applications can be really fun, and give you a decent knowledge for the inner workings of the Dalvik Virtual Machine. This post will be an all-out, start-to-finish, beginners* tutorial on the tools and practices of reverse engineering Android, through the disassembly and code injection of the Android Hello World application.

CapnAndy posted:

I decided to get into Android development and I'm already pretty good at c# and visual studio, so I got MonoDroid. At first glance, it's super neat. But I want that frigging title bar to go away! I did this:

code:

[Activity(Label = "AndroidFirst", MainLauncher = true, Icon = "@drawable/icon")]
public class Activity1 : Activity
{
	int count = 1;

	protected override void OnCreate(Bundle bundle)
	{
		base.OnCreate(bundle);

		// Set our view from the "main" layout resource
		SetContentView(Resource.Layout.Main);

		// Get our button from the layout resource,
		// and attach an event to it
		Button button = FindViewById<Button>(Resource.Id.HelloButton);

		button.Click += delegate { button.Text = string.Format("{0} clicks!", count++); };

		this.Window.AddFlags(WindowManagerFlags.Fullscreen);
		this.RequestWindowFeature(WindowFeatures.NoTitle);
	}
}

But it fails, and the only error I get is the extremely unhelpful "Android.Util.AndroidRuntimeException:". The Fullscreen flag was working, it just started being a pain in the rear end when I tried requesting no title. What stupidly basic newbie mistake am I making?

Geekner posted:

You have to add window flags and request window features before you call setContentView, since it takes those flags into consideration when it creates the layout.

PiotrLegnica posted:

You can use @android:style/Theme.NoTitleBar theme (that Activity attribute seems to have Theme property).

Glimm posted:

Interesting post Ferg linked to on Google+:

Reverse Engineering Android: Disassembling Hello World

TheReverend posted:

Has anyone here used the In-app Billing with much success? I admit I'm still pretty new to android and that stuff I've done hasn't been too complicated but this In-app stuff seems like a design disaster. I'd have thought it would have been a whole lot easier!

Is it really this complicated, or do I just suck?

Geekner posted:

I keep running into convenience functions that were added in API 8/9/11. I hate spending time re-implementing poo poo that should have existed in API 1.

String.isEmpty() - added in API 9

gently caress.

There should not be twice as many phones with 2.1 than 4.1.

Flobbster posted:

In fairness, you can go straight to the source and blame Java for that one, since they didn't decide that isEmpty() might be useful for strings until 1.6

The current state of fragmentation on Android is ridiculous though. I use Android in my data structures course and I hate that I still have to use 2.2 as my baseline for all the projects because that's what most of my students still have. And it really pisses me off that we bought a batch of Samsung 7" Galaxy Tabs last year for classroom use and we can't even upgrade those (officially) past 2.3.

The only reason I can tolerate programming in Java anymore is because of Android, and I'm excited about when they finally get around to adding lambdas (maybe in Java 8?). But what are the chances I'd be able to use those on Android if I can't upgrade it? Not much, unless their implementation is all compile-time transformations and doesn't require JVM changes.

Doctor w-rw-rw- posted:

The chances are virtually zero regardless. Android implements against a subset of 6 since that's the last freely available release of Java. Building against a newer version of Java seems at this point to be impossible without a huge reconciliation and subsequent licensing deal with Oracle.

Far more likely is some sort of switch to LLVM and something on top of that, IMO, though I find it hard to believe that Dalvik won't continue to be supported indefinitely.

Munkeymon posted:

It's obviously not impossible to compile other languages to Dalvik, so why couldn't they transition to a different official language? Granted, I'm not sure what that would be* and I didn't realize newer Java versions had to be licensed now. Wonder what that does to OS Java (or JVM-dependant) projects.

*it would be hilarious to watch the corporate tears flow if Google bought xamarin and stated giving that toolchain away. E; Not that they ever would, but still