Fixed
Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
since these are in public API (:/) we need to do this in 1.2
la...@gmail.com <la...@gmail.com> #3
since it is already marked as deprecated, we can probably do it by now.
ja...@gmail.com <ja...@gmail.com> #4
Opening diff shortly
il...@google.com <il...@google.com>
il...@google.com <il...@google.com> #5
Project: platform/frameworks/support
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/61 .
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
https://android-review.googlesource.com/1396827
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request from
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
ap...@google.com <ap...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 781d0178da33d84f615b409b17975c8ba290401c
Author: Ian Lake <ilake@google.com>
Date: Mon Feb 25 15:38:23 2019
Fix navigateUp() logic when on another app's task
When using deep linking on another app's task,
only the final destination is created, ensuring that
hitting the system back button goes back to the
other app. The Up button, via navigateUp(), should
take users to your own task on the parent destination.
Recent changes made it so that we always add the
parent NavGraphs to the back stack, meaning the simple
check of back stack size == 1 does not properly handle
this change in behavior so instead we need to check for
the number of non-NavGraph destinations on the back
stack.
Test: new NavControllerActivityTest
BUG: 126082008
Change-Id: I7bf18d38e1cdd3818e7414ba44d84df0abd81b88
M navigation/runtime/src/androidTest/AndroidManifest.xml
A navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerActivityTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/912258
https://goto.google.com/android-sha1/781d0178da33d84f615b409b17975c8ba290401c
Branch: androidx-master-dev
commit 781d0178da33d84f615b409b17975c8ba290401c
Author: Ian Lake <ilake@google.com>
Date: Mon Feb 25 15:38:23 2019
Fix navigateUp() logic when on another app's task
When using deep linking on another app's task,
only the final destination is created, ensuring that
hitting the system back button goes back to the
other app. The Up button, via navigateUp(), should
take users to your own task on the parent destination.
Recent changes made it so that we always add the
parent NavGraphs to the back stack, meaning the simple
check of back stack size == 1 does not properly handle
this change in behavior so instead we need to check for
the number of non-NavGraph destinations on the back
stack.
Test: new NavControllerActivityTest
BUG: 126082008
Change-Id: I7bf18d38e1cdd3818e7414ba44d84df0abd81b88
M navigation/runtime/src/androidTest/AndroidManifest.xml
A navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerActivityTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
il...@google.com <il...@google.com> #7
A fix will be available in Navigation 1.0.0-rc02. Thanks for reporting it and the great sample app!
ja...@gmail.com <ja...@gmail.com> #8
Thanks, Ian.
Description
Version used: 1.0.0-rc01
Devices/Android versions reproduced on: 7.0, 9.0 (Emulators)
According to
if a destination is opened with IMPLICIT deeplink and WITHOUT Intent.FLAG_ACTIVITY_NEW_TASK flag, then the destination is opened in the same task. After that if user clicks UP, then the actual parent should be recreated in a separate task, but it doesn't work. The UP button in this case does nothing, as well as manual navigateUp() method call.
I tried to modify the code to check both Toolbar and ActionBar approaches and also tried to create the NavHostFragment via xml and code. In all this cases, the behavior of UP button remained the same.
I attached a simple project that shows this situation. It contains 2 modules:
- app - an app with 2 fragments (root and child). The child fragment's destination supports a deeplink.
- deeplinkstarter - one button app, that starts an implicit deeplink to the child fragment of the 'app'.
I consider this as major defect because the library doesn't behave as it is explicitly said in the documentation.
Please, improve.