Status Update
No update yet.
Comments
sw...@gmail.com
To provide some context , R8
It is a
In the context of navigation + kotlinx serialization, we will have to look into whether navigation can viably prevent this shrinkage/obfuscation.
In the mean time, we will be adding a lint rule to remind users to use @Keep.
yb...@google.com
Branch: androidx-main
commit 4940c45ab1632128129bfb64b4fd42320b081c92
Author: Clara Fok <clarafok@google.com>
Date: Mon Sep 16 13:04:40 2024
Add navigation-common lint for Keep annotation
We need to make sure that Enums that are used as nav arguments in type-safe routes are annotated with @Keep. The e
ntry point to locating said Enums are rotue declarations that contains Enum arguments.
Since the entry point is essentially the same lint location for linting @Serializable annotation, this lint uses the same detector but expands upon it.
Test: ./gradlew navigation:navigation-common-lint:test
Bug:358687142
Change-Id: I2b46fbc3b5be6251d89e902e315f50f20c46ce19
M navigation/navigation-common-lint/src/main/java/androidx/navigation/common/lint/NavigationCommonIssueRegistry.kt
M navigation/navigation-common-lint/src/main/java/androidx/navigation/common/lint/TypeSafeDestinationMissingAnnotationDetector.kt
A navigation/navigation-common-lint/src/test/java/androidx/navigation/common/lint/MissingKeepAnnotationDetectorTest.kt
sw...@gmail.com
Branch: androidx-main
commit 33f3eee080a07079f9ce7b34d58ee210869fe180
Author: Clara Fok <clarafok@google.com>
Date: Wed Sep 18 23:32:56 2024
Add navigation-compose lint for type safe annotations
The lint checks if routes that are used to create NavDestinations are annotated with kotlinx @Serializable, and checks that enum arg types are annotated with @Keep.
Test: ./gradlew navigation:navigation-compose-lint:test
Bug: 362725816
Bug: 358687142
Change-Id: I954023cd0cb4a5ee7d08647cf9a8139b0c8ae9d9
M navigation/navigation-compose-lint/src/main/java/androidx/navigation/compose/lint/NavigationComposeIssueRegistry.kt
A navigation/navigation-compose-lint/src/main/java/androidx/navigation/compose/lint/TypeSafeDestinationMissingAnnotationDetector.kt
A navigation/navigation-compose-lint/src/test/java/androidx/navigation/compose/lint/MissingKeepAnnotationDetectorTest.kt
A navigation/navigation-compose-lint/src/test/java/androidx/navigation/compose/lint/MissingSerializableAnnotationDetectorTest.kt
M navigation/navigation-compose-lint/src/test/java/androidx/navigation/compose/lint/Stubs.kt
yb...@google.com
Branch: androidx-main
commit 50b1c751929ecb0bfafa59afc1a6101b39668e9b
Author: Clara Fok <clarafok@google.com>
Date: Wed Sep 18 20:55:45 2024
Add navigation-runtime lint for type safe annotations
The lint checks if routes that are used to create NavDestinations are annotated with kotlinx @Serializable, and checks that enum arg types are annotated with @Keep.
Test: ./gradlew navigation:navigation-runtime-lint:test
Bug: 362725816
Bug: 358687142
Change-Id: Ie601a15449b1561154bd3ae5d990e006a371c7c6
M navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/NavigationRuntimeIssueRegistry.kt
A navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/TypeSafeDestinationMissingAnnotationDetector.kt
A navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/MissingKeepAnnotationDetectorTest.kt
A navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/MissingSerializableAnnotationDetectorTest.kt
A navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/Stubs.kt
da...@gmail.com
Branch: androidx-main
commit 8b4f5f4e8219232187ac103252715c7213215625
Author: Clara Fok <clarafok@google.com>
Date: Tue Sep 24 04:42:33 2024
Add annotation lint for NavDeepLink builders
Lint for @Serializable and @Keep with for navDeepLink builders
Test: ./gradlew navigation:navigation-common-lint:test
Bug: 362725816
Bug: 358687142
Change-Id: I4a259b5544e4e4655c4bdee812d64f3b2a1947bd
M navigation/navigation-common-lint/src/main/java/androidx/navigation/common/lint/TypeSafeDestinationMissingAnnotationDetector.kt
M navigation/navigation-common-lint/src/test/java/androidx/navigation/common/lint/MissingKeepAnnotationDetectorTest.kt
M navigation/navigation-common-lint/src/test/java/androidx/navigation/common/lint/MissingSerializableAnnotationDetectorTest.kt
M navigation/navigation-lint-common/src/main/java/androidx/navigation/lint/common/BaseTypeSafeDestinationMissingAnnotationDetector.kt
M navigation/navigation-lint-common/src/main/java/androidx/navigation/lint/common/TestStub.kt
sw...@gmail.com
This has been fixed internally and will be available in the Navigation 2.8.3 release.
yb...@google.com
Do you have direct boot enabled?
If you, you won't have access to the files directory until the user unlock the phone. You might either consider using the device encrpted section (if it makes sense for your use case), or wait until device is unlocked before accessing the datastore instance.
da...@gmail.com
Hello,
No, I don't use DirectBoot.
That was just a hypothesis I proposed. Sorry if it was misleading.
sw...@gmail.com
In my case Direct Boot seems to be a problem. My application was working with DataStore in a receiver called on the LOCKED_BOOT_COMPLETED action. The DataStore instance was not using Context.createDeviceProtectedStorageContext().
Later I made a change that would always instantiate DataStore with Context.createDeviceProtectedStorageContext() and gave the app a fresh install. This didn't fix the problem so I've decided to opt-out of receiving LOCKED_BOOT_COMPLETED action and working off of it.
It is also possible that I'm misusing Context.createDeviceProtectedStorageContext() since I didn't have too much time to study this topic too deep.
If you have any tips on good practices in using DataStore during Direct Boot let me know.
yb...@google.com
I'm not very experienced in direct boot so I don't have any tips besides the docs.
That being said, DataStore 1.1 gives you a lot more control on how you want to manage the file.
e.g. you can use the Factory API, which lets you pass a Storage
You can either use OkioStorage or FileStorage (which is what we use even when you use the context based API).
Both of these implementations receive a block that will be invoked when it needs a file and there you can handle your custom logic, check if you can access the file, add more logging etc.
sw...@gmail.com
I can confirm that after:
- removing
LOCKED_BOOT_COMPLETEDaction from the Intent filter of myBootReceiverand - updating
androidx.core:core-ktxfrom1.11.0-alpha01to1.12.0
the issue with IOException on createParentDirectories has stopped being reported on my Google Play Console.
Description
DataStore Version used: 1.0.0
Devices/Android versions reproduced on: Android 10 (SDK 29)
Sometimes on App initialization (starting code on Application class) the datastore crashes when it was tried to be accessed for the first time:
Caused by java.io.IOException:
at androidx.datastore.core.SingleProcessDataStore.createParentDirectories (SingleProcessDataStore.kt:454)
at androidx.datastore.core.SingleProcessDataStore.writeData$datastore_core (SingleProcessDataStore.kt:421)
at androidx.datastore.core.SingleProcessDataStore$readAndInit$api$1.updateData (SingleProcessDataStore.kt:339)
at androidx.datastore.core.DataMigrationInitializer$Companion.runMigrations (DataMigrationInitializer.kt:42)
at androidx.datastore.core.DataMigrationInitializer$Companion.access$runMigrations (DataMigrationInitializer.kt:23)
at androidx.datastore.core.DataMigrationInitializer$Companion$getInitializer$1.invokeSuspend (DataMigrationInitializer.kt:33)
at androidx.datastore.core.DataMigrationInitializer$Companion$getInitializer$1.invoke
at androidx.datastore.core.DataMigrationInitializer$Companion$getInitializer$1.invoke
at androidx.datastore.core.SingleProcessDataStore.readAndInit (SingleProcessDataStore.kt:348)
at androidx.datastore.core.SingleProcessDataStore.readAndInitOrPropagateFailure (SingleProcessDataStore.kt:311)
at androidx.datastore.core.SingleProcessDataStore.handleRead (SingleProcessDataStore.kt:261)
at androidx.datastore.core.SingleProcessDataStore.access$handleRead (SingleProcessDataStore.kt:76)
at androidx.datastore.core.SingleProcessDataStore$actor$3.invokeSuspend (SingleProcessDataStore.kt:239)
at androidx.datastore.core.SingleProcessDataStore$actor$3.invoke
at androidx.datastore.core.SingleProcessDataStore$actor$3.invoke
at androidx.datastore.core.SimpleActor$offer$2.invokeSuspend (SimpleActor.kt:122)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run (DispatchedTask.kt:106)
at kotlinx.coroutines.internal.LimitedDispatcher.run (LimitedDispatcher.kt:42)
at kotlinx.coroutines.scheduling.TaskImpl.run (Tasks.kt:95)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely (CoroutineScheduler.kt:570)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask (CoroutineScheduler.kt:750)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker (CoroutineScheduler.kt:677)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run (CoroutineScheduler.kt:664)