Fixed
Status Update
Comments
yb...@google.com <yb...@google.com>
fa...@gmail.com <fa...@gmail.com> #2
[Comment deleted]
yb...@google.com <yb...@google.com>
yb...@google.com <yb...@google.com>
yb...@google.com <yb...@google.com> #3
[Comment deleted]
yb...@google.com <yb...@google.com>
sh...@google.com <sh...@google.com>
sh...@google.com <sh...@google.com> #4
Also of note is the adb error when trying to install bad APK: INSTALL_FAILED_DEXOPT
sh...@google.com <sh...@google.com>
yb...@google.com <yb...@google.com> #5
load dex files over 5Gb. -> load dex files over 5Mb.
yb...@google.com <yb...@google.com>
va...@gmail.com <va...@gmail.com> #6
Same here! Looking forward to a solution :)
Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11
Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11
ms...@gmail.com <ms...@gmail.com> #7
There is already an option in dx allowing to force generation of smaller dex files:
--set-max-idx-number=<value>
Unfortunately changing the default is not a solution since the linearAlloc limit can be reached at very different levels depending on the classes hierarchy and other criteria.
In addition for most applications, moving to multidex will only help to workaround the linearalloc limit for the installation. But the application will still crash against the same limit at execution. The only working use case where I know multidex can help with linearalloc is when the apk does not contains one application but distinct pieces running in separate process.
--set-max-idx-number=<value>
Unfortunately changing the default is not a solution since the linearAlloc limit can be reached at very different levels depending on the classes hierarchy and other criteria.
In addition for most applications, moving to multidex will only help to workaround the linearalloc limit for the installation. But the application will still crash against the same limit at execution. The only working use case where I know multidex can help with linearalloc is when the apk does not contains one application but distinct pieces running in separate process.
Description
Version used: 1.0.0-alpha9
Devices/Android versions reproduced on: Android 5 (it works on Android 8)
I have a strange problem connected to a MutableLiveData that doesn't trigger the observer when updated in onActivityResult. The cause seems to be a wrong state in LifecycleRegistry, in the following example the println in onResume prints "resume CREATED". Between startActivityForResult and onResume the state is set to CREATED even if the Activity remains always started (because the other activity is not full screen).
You can reproduce this issue using this Activity:
class LiveDataTestActivity : AppCompatActivity(), LifecycleRegistryOwner {
private val lifecycle = LifecycleRegistry(this)
override fun getLifecycle() = lifecycle
private val myLiveData = MutableLiveData<Int>().apply { value = 0 }
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val textView = TextView(this).apply {
text = "AAAA"
setOnClickListener {
val sendIntent = Intent().apply {
action = Intent.ACTION_SEND
putExtra(Intent.EXTRA_TEXT, "This is my text to send.")
type = "text/plain"
}
startActivityForResult(sendIntent, 123)
}
}
setContentView(textView)
myLiveData.observe(this, Observer<Int> {
textView.text = it.toString()
})
}
override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
super.onActivityResult(requestCode, resultCode, data)
myLiveData.value = (myLiveData.value ?: 0) + 1
println("Value ${myLiveData.value}")
}
override fun onResume() {
super.onResume()
println("resume ${lifecycle.currentState}")
}
}