Obsolete
Status Update
No update yet.
Comments
am...@google.com
am...@google.com
This would indeed be very useful feature I think. Currently, my only alternative is to reorganize all my subfolders and their contents to be in the top-most directory of which I know the name of. First of all, this results in this directory having thousands of files, each with a VERY long name to properly identify it based on its original path. Secondly, it requires additional effort on the reorganizing side of things; I need some script to do something I feel should've been part of the NDK...I mean there's already a function for iterating over files, why not folders as well?
Just my two cents :)
Just my two cents :)
am...@google.com
I agree that it would be a useful feature, the alternatives that I have seen require either the user to avoid folders altogether, a Java backend (which is one of the things the NDK tries to avoid) or finding the apk as zip and searching for directories (slow & unnecessary).
am...@google.com
That's frustrating...But for those who are looking for a pure C++ solution, I would recommend using Qt Framework on Android. You can iterate over folders with the following code snippet:
foreach (const QString& dirName, QDir("assets:/").entryList(QDir::AllDirs | QDir::NoDotAndDotDot)
Qt probably uses a Java backend for this, but it works at the end. You can use many Qt classes across multiple operating systems without thinking about all that garbage. They handle all the wrappers etc for you. Just a little suggestion 👍🏻
foreach (const QString& dirName, QDir("assets:/").entryList(QDir::AllDirs | QDir::NoDotAndDotDot)
Qt probably uses a Java backend for this, but it works at the end. You can use many Qt classes across multiple operating systems without thinking about all that garbage. They handle all the wrappers etc for you. Just a little suggestion 👍🏻
as...@gmail.com
I would love to see this feature implemented as well. I'd love to be able to organize assets by directory in the NDK without using some weird hack or importing a massive framework like Qt -- my binary size right now is minuscule, and I'd likely quadruple it by bringing in Qt. That's not even to mention the fact that apps that don't rely on Qt would be swatting flies with sledgehammers by solving this issue by linking to Qt.
am...@google.com
as...@gmail.com
Yes Qt is a massive framework. It's not an optional solution for such a small problem, I didn't want to mean that; I was meaning the shifting of entire development platform from Android to fully cross-platform Qt C++ Framework (for a few reasons):
* Qt is a C++ platform; whereas Android is not exactly (Java, Kotlin and all that garbage is the primary focus of Android)
* Qt is better maintained in terms of C++
* Apps written with Qt can work on Android, iOS, macOS, Windows, *nix, Linux, Embedded... with a single code base
* Qt has built-in cross-platform key features like event driven programming, media encoding/playing, animations, networking, databasing, image encoding/rendering, purchasing, scripting, data visualization, 2d/3d rendering etc. (you would normally find a 3rd party library for every one of those features on Android or write your own solution)
Anyway, that's just a suggestion.
* Qt is a C++ platform; whereas Android is not exactly (Java, Kotlin and all that garbage is the primary focus of Android)
* Qt is better maintained in terms of C++
* Apps written with Qt can work on Android, iOS, macOS, Windows, *nix, Linux, Embedded... with a single code base
* Qt has built-in cross-platform key features like event driven programming, media encoding/playing, animations, networking, databasing, image encoding/rendering, purchasing, scripting, data visualization, 2d/3d rendering etc. (you would normally find a 3rd party library for every one of those features on Android or write your own solution)
Anyway, that's just a suggestion.
l....@gmail.com
Please add a AAssetDir_getNextFileOrDirectoryName or similar. This is essential and basic functionality that shouldn't be missing.
as...@gmail.com
+1
st...@gmail.com
Keep up the good work.
as...@gmail.com
#googleadswords.com
am...@google.com
Can we make an internal mirror bug for this feature request? Thanks!
sa...@google.com
sk...@gmail.com
Internal bug assigned. Closing the external bug. Issue is being worked on.
Description
Build: OPP2.170420.019
Issue: Battery graph/statistics does not show enough information.
*In Android N, the battery graph showed bars below the graph axis to indicate data such as when the screen was on, when the device was awake, when the camera/flashlight/GPS were on, etc. These provide very useful information to the user, but have been removed from the Android O dev preview. Please consider re-adding these back to the battery graph to allow the user to see desired information about battery use in the native settings app - the awake time and screen on bars are particularly critical.
*Also, when viewing the battery graph, none of the items in the list below the graph can be clicked on to provide additional information about them as you could in N - expected behavior would include being able to see Google play services, android os/system, etc. in the usage statistics as well as all the apps.
*Furthermore, installed apps' usage and the system's usage of the battery are separated into different lists/categories, making it difficult to discern what is using my battery. Please consider having battery usage shown in one cohesive list that displays items in order of usage, regardless of whether they are part of the "android system", an installed user app, or something else, in addition to the new list that shows what apps were used. Thank you.