Develop Reference

public class PeripheralManager - returning all stubs

I have imported
implementation 'com.google.android.things:androidthings:1.0'
And when I execute code, it throws a runtime error because inside of the PeripheralManager class the methods are all stubs:
public List<String> getUartDeviceList() {
throw new RuntimeException("Stub!");
}
This was working several months ago, I've tried changing implementation to compile

There are several conditions you should verify in your project:
Your device must be either the i.MX7D or Raspberry Pi 3B with the Android Things OS on it, as noted in the hardware guide.
Your app/build.gradle must use compileOnly 'com.google.android.things:androidthings:1.0'
Your app/src/main/AndroidManifest.xml must include the following as a child of the application element:
<uses-library android:name="com.google.android.things"/>
You may also want to check properties like the targetSdkVersion being 27. If you continue to run into trouble, check out Android Things sample projects.

Which device are you running it into? This API is only available on Android Things boards, not on phones.

Android GoogleApiClient connects to MARSHMALLOW but not to JELLY_BEAN

My Android app dumps files into Gdrive. It's using Oauth2.0 authentication and I've done the needful at console.developers.google.com. The problem I'm facing is that the app works fine on my Marshmallow phone but cannot get past the Google login on my JellyBean or lower. On these, the app gets stuck at the "Choose account for" window.
Studio's Android monitor returns the following:
GoogleApiClient connection failed: ConnectionResult{statusCode=SIGN_IN_REQUIRED, resolution=PendingIntent{419cbb80 ...
Keeping in mind that the app does work on the Marshmallow phone, my suspicion is that the issue is related to one of the "versions" in the app's build.grade file, an excerpt of which is below.
compileSdkVersion 23
buildToolsVersion "26.0.0"
defaultConfig {
applicationId "rudy.android.stgpro"
minSdkVersion 9
targetSdkVersion 18
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.rudykeystore
}
debug {
signingConfig signingConfigs.rudykeystore
}
}
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:appcompat-v7:23.0.1'
compile 'com.google.android.gms:play-services-drive:8.4.0'
}
Or, maybe, Oauth2.0 does not work with earlier Android versions.
I also notice that the size of the app loaded into Marshmallow is about 40% the size of that loaded into the other two phones.
Google's Drive app works fine on all phones.
I've googled around for hours now and am, pretty much, stuck. Any suggestions?

After much "blood, sweat and tears", I've discovered that the problem lay in a single line in the AndroidManifest.xml file ...
android:launchMode="singleInstance"
I have no clue why this line affects phones running JellyBean and lower but not Marshmallow (not sure about Kitkat & Lollipop). And, just to be clear, the line literally toggles the problem with its presence/absence (with zero other changes).
I zeroed in on the problem using Drives's Quickstart as a base (its connection worked with all my test phones), then gradually modifying its code by adding/removing from my app's code (took me a couple of days).
Anyway, thank goodness for these working samples.

How to debug android SDK classes?

I want to check why sometimes my invalidate() not call onDraw.
1 step: I set a breakpoint on invalidate().
2 step: I click "Step Into" button (also tried "Force Step Into"). But debugger goes not inside invalidate(). It goes inside getElevation() instead. Why?
picture 1
Also, I tried to set a breakpoint inside invalidate() method of View class on line invalidate(true);. But it also remains unreachable. It says that "No executable code ...".
picture 2

I solved it partially.
Device version must be the same as SDK sources version, compileSdkVersion, buildToolsVersion, targetSdkVersion.
In my case SDK sources API 24.
build.gradle:
compileSdkVersion 24
buildToolsVersion "24.0.1"
defaultConfig {
targetSdkVersion 24
...
}
Tracing now works (with these parameters only on API 24 device) but breakpoints still don't work (same No executable code error).

You can try to download the Sources for Android SDK for your targetSdkVersion inside build.gradle and see if you can debug inside the methods then.
But note that the newest Android API 25 does not have the sources available yet.

Can I enable multidex in Android debug build only?

Dears,
I read in many blog posts that multidex apps startup is slower than normal apps.
My app uses a lot of libraries that exceed 64k methods so I use multidex. But when I use proguard in release build, the final apk becomes less than 64k methods
So My question is: Can I enable multidex in Android debug build only so I don't have runtime error? and disable multi dex in release build as I don't need it?
If yes, how ?
If No, Is Android smart enough to speedup startup as it should recognize that app didn't exceed 64k even if it is multi dex app ?

Yes, you can. When you declare your buildTypes include multidex only for debug:
buildTypes {
release {
multiDexEnabled false
    }
debug {
multiDexEnabled true
}
}

Instead of enabling multidex only for debug, you can change your min sdk version to 21 only for debug so gradle can speed up dexing with ART:
android {
productFlavors {
// Define separate dev and prod product flavors.
dev {
// dev utilizes minSDKVersion = 21 to allow the Android gradle plugin
// to pre-dex each module and produce an APK that can be tested on
// Android Lollipop without time consuming dex merging processes.
minSdkVersion 21
}
prod {
// The actual minSdkVersion for the application.
minSdkVersion 14
}
}
...
buildTypes {
release {
runProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'),
'proguard-rules.pro'
}
}
}
dependencies {
compile 'com.android.support:multidex:1.0.0'
}
http://developer.android.com/tools/building/multidex.html

suggested methods are not needed anymore as android studio became "smart enough".
In fact, it will now give you a warning when you use minSdkVersion 21 (the old way) to speed up build time with dex:
You no longer need a dev mode to enable multi-dexing during
development, and this can break API version checks less...
In the past, our documentation recommended creating a dev product
flavor with has a minSdkVersion of 21, in order to enable multidexing
to speed up builds significantly during development. That workaround
is no longer necessary, and it has some serious downsides, such as
breaking API access checking (since the true minSdkVersion is no
longer known.) In recent versions of the IDE and the Gradle plugin,
the IDE automatically passes the API level of the connected device
used for deployment, and if that device is at least API 21, then
multidexing is automatically turned on, meaning that you get the same
speed benefits as the dev product flavor but without the downsides.

Yes, it even works with the multidex support library for Android versions prior to Lollipop with a little trick.
First specify multiDexEnabled for the debug build in build.gradle:
buildTypes {
...
debug {
...
multiDexEnabled true
}
}
Then create an AndroidManifest.xml file under src/debug.
src/debug/AndroidManifest.xml:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<application
android:name="android.support.multidex.MultiDexApplication"
tools:replace="android:name"/>
</manifest>
That should do the trick. If your app uses a custom application class then you have to create a subclass of your application class and specify the name of that subclass in the manifest.
The application subclass should look like this:
public class MyDebugApplication extends MyApplication {
#Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
}

gradle - Android Studio build too slow multidex application

When I add to my project the multidex:true, and make an Application class that extends from the MultiDexApplication, my project build time passed from 20 sec to around 90 sec.How to do some faster?

If you are like me who already tried Vic Vu's solution but still can't avoid enabling multiDex then you can try this (as long as your are using a device that has Android 5.0 and above).
Note This will only speed up your development build. Your production build will still be slow.
Basically you need to introduce 2 product flavors one for dev and one for prod.
Add multiDexEnabled true
android {
productFlavors {
// Define separate dev and prod product flavors.
dev {
// dev utilizes minSDKVersion = 21 to allow the Android gradle plugin
// to pre-dex each module and produce an APK that can be tested on
// Android Lollipop without time consuming dex merging processes.
minSdkVersion 21
}
prod {
// The actual minSdkVersion for the application.
minSdkVersion 14
}
}
...
buildTypes {
release {
runProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'),
'proguard-rules.pro'
}
defaultConfig {
applicationId "com.something.something"
targetSdkVersion 23
versionCode 1
versionName "1.0.0"
multiDexEnabled true
}
}
dependencies {
compile 'com.android.support:multidex:1.0.1'
}
And I have a class which extends Application so I had to override attachBaseContext()
#Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
If you are not extending Application simply use MultiDexApplication in your AndroidManifest.xml application tag.
Ensure that in your Android Studio Build Variants you are pointing to devDebug.
Read the complete instructions here https://developer.android.com/studio/build/multidex.html#dev-build

Supplying as an answer because this is better fit with the formatting.
To simply answer your question: No, there is no way. Multidex is a process meant to help lift the burden of the 65k method limit. This process is complicated and will simply make your build times longer.
The best you can can do is lower your method count.
In your build.gradle (supplied here) you're using:
`compile 'com.google.android.gms:play-services:8.3.0'`
But if you look at the most recent play services api you can pick and choose what services you actually need.
Look at Table 1 on this page.
Only use the ones you need. Google play services as a whole is somewhere around 30k methods.
That should help.

Multidexing uses more memory. As you get closer to your max heap size in Java you'll find Java spends more time doing GC than it does doing any real work, this can slow things down a lot.
I'd strongly recommend increasing the max heap size when using multidex. Add the following to the android closure in your build.gradle file to make the max heap size 4GB (Make it larger/smaller if you wish):
dexOptions {
javaMaxHeapSize "4g"
}

It depends.
You haven't specified it in your question, but if you just want to speed-up your development builds - then you can avoid the extra work. Official documentation includes a whole section about that.